บทนำเชิงปฏิบัติเกี่ยวกับ Guard clauses
เมื่อฉันเริ่มเขียนโปรแกรมครั้งแรก ฉันหวังว่าจะมีคนบอกฉันเกี่ยวกับแนวคิดที่แตกต่างกันเล็กน้อยที่ควรคำนึงถึงเมื่อเขียนเว็บไซต์แรกของฉัน
หนึ่งในข้อผิดพลาดที่ฉันพบเมื่อเริ่มต้นคือการใช้คีย์เวิร์ด else มากเกินไปเมื่อเขียนเงื่อนไข นี่เป็นสิ่งที่ฉันพบว่ามีคนอื่นๆ มากมายที่ทำโค้ดของตนเองเช่นกัน ดังนั้นฉันคิดว่าฉันควรจะให้ความกระจ่างในหัวข้อนี้บ้าง
ข้อจำกัดความรับผิดชอบ; มุมมองของฉันในหัวข้อนี้เป็นเพียงอัตนัยเท่านั้น
ในบางสถานการณ์ คุณอาจไม่สามารถใช้แนวทางประเภทนี้กับโค้ดของคุณได้ บางครั้ง วิธีแก้ไขคือใช้คีย์เวิร์ด else โพสต์นี้มีไว้เพื่อแจ้งให้ผู้คนทราบถึงแนวทางอื่นในการจัดโครงสร้างตรรกะ
มาตรายาม
ตาม “วิกิพีเดีย” มาตราการป้องกันคือการตรวจสอบเงื่อนไขเบื้องต้นด้านความสมบูรณ์ที่ใช้เพื่อหลีกเลี่ยงข้อผิดพลาดระหว่างการดำเนินการ
ลองแบ่งคำจำกัดความนั้นออกเป็นเงื่อนไขของคนธรรมดา เราทำการตรวจสอบเงื่อนไขเบื้องต้นด้านความสมบูรณ์ (ที่จุดเริ่มต้นของโค้ดของเรา) เพื่อหลีกเลี่ยงข้อบกพร่องใดๆ ในระหว่างโฟลว์หลักของตรรกะของเรา
ในขั้นตอนที่สมบูรณ์แบบ (เมื่อการตรวจสอบความถูกต้องถูกต้อง) เราต้องการให้ตรรกะหลักของโปรแกรมของเราเป็นไปตามการตรวจสอบความถูกต้องทั้งหมด
ลองจินตนาการว่าเราเปิดเว็บไซต์ที่เรามีพื้นที่ซื้อของพรีเมียมซึ่งจำกัดเฉพาะลูกค้าที่ชำระเงินเท่านั้น และจะเปิดหลัง 12.00 น. เท่านั้น
ในแอปพลิเคชันจริง เราอาจส่งคืนข้อยกเว้นบางรูปแบบ
แม้ว่านี่จะเป็นแนวทางในการดำเนินตามเงื่อนไข แต่คำหลัก else ก็กลายเป็นเรื่องยากที่จะปฏิบัติตาม แม้ว่าเราจะมีจำนวนคำหลักเพียงเล็กน้อยก็ตาม
นี่เป็นตัวอย่างเล็กๆ น้อยๆ ของตรรกะเชิงเงื่อนไข แต่ลองนึกภาพการพยายามนำทางคลาสที่มีตรรกะที่ซับซ้อนกว่ามาก ในความคิดของฉัน การเขียนโค้ดผ่านมาตรฐานนี้ไม่ยั่งยืน และเราควรจะปรับปรุงให้ดีขึ้น
ด้วย guard clauses เราจะต้องปฏิบัติตามกรอบการทำงานนี้:
เมื่อใช้กรอบงานดังกล่าว เราสามารถปรับโครงสร้างโค้ดก่อนหน้านี้ได้ดังนี้:
ใน guard clauses เรามักจะกลับนิพจน์บูลีนไปเป็นสิ่งที่เราต้องการยืนยัน หากเราต้องการให้ผู้ใช้ลงชื่อเข้าใช้เพื่อดูหน้านี้ เราต้องการตรวจสอบว่าพวกเขา ไม่ได้ ลงชื่อเข้าใช้อยู่หรือไม่
วิธีการนี้รวบรวมโฟลว์ลอจิกที่เหมือนกันทุกประการ แต่ในความคิดของฉันและวิธีอื่นๆ เช่นกัน นี่เป็นวิธีที่สะอาดกว่ามากเมื่อจัดการกับตรรกะแบบมีเงื่อนไข
บทสรุป
เมื่อเขียนโค้ด เราควรคำนึงถึงคำถามเสมอว่า “การดูแลเวลา 6 เดือนข้างหน้าจะง่ายแค่ไหน?”
การสร้างแนวทางแก้ไขปัญหาในเวลาปัจจุบันเป็นสิ่งที่ดีมาก แต่แล้วในอนาคตล่ะ? การไม่สร้างซอฟต์แวร์โดยคำนึงถึงอนาคตถือเป็นเรื่องโง่
มันทำให้ฉันต้องเขียนคุณสมบัติทั้งหมดใหม่ทั้งหมดตั้งแต่เริ่มต้น เนื่องจากว่าฉันสะสมหนี้ทางเทคนิคมากเพียงใดเมื่อเวลาผ่านไปจากการแก้ไข band-aid มากมาย
การใช้คำสั่งป้องกันจะเตรียมตนเอง/ทีมในอนาคตของคุณให้พร้อมสำหรับความสำเร็จเมื่อมีการเพิ่มข้อกำหนดใหม่ลงในโปรแกรมของคุณ
