การป้องกันโปรแกรม: มันคือ Paranoia หรือ Smart Coding?

เหตุใดการเขียนโปรแกรมเชิงป้องกันจึงเป็นวิธีที่ดีที่สุดสำหรับการเข้ารหัสที่แข็งแกร่ง

การป้องกันการเขียนโปรแกรมเป็นโปรแกรมจริงเท่านั้น

เครดิตรูปภาพ: Pixabay

การตั้งโปรแกรมป้องกันคือเมื่อโปรแกรมเมอร์คาดการณ์ถึงปัญหาและเขียนรหัสเพื่อจัดการกับปัญหาเหล่านั้น

มันเหมือนการเห็นรถชนในอนาคต… .. และยังคงสงบเพราะคุณทำประกัน

ดังที่กล่าวไว้จุดรวมของการตั้งโปรแกรมการป้องกันคือการป้องกันข้อผิดพลาดที่คุณไม่คาดคิด โปรแกรมเมอร์ป้องกันอยู่บนนาฬิกาเพื่อหลีกเลี่ยงปัญหาก่อนที่มันจะทำให้เกิดปัญหาจริง ความคิดที่จะไม่เขียนโค้ดที่ไม่เคยล้มเหลว นั่นคือความฝันที่อุดมคติ แนวคิดในการทำให้โค้ดล้มเหลวอย่างสวยงามในกรณีที่มีปัญหาที่ไม่คาดคิด การล้มเหลวอย่างสวยงามอาจหมายถึงสิ่งใดสิ่งหนึ่งต่อไปนี้

·ล้มเหลวในช่วงต้น: รหัสของคุณควรตรวจสอบให้แน่ใจว่าการดำเนินการที่สำคัญทั้งหมดถูกยกเลิกล่วงหน้าโดยเฉพาะอย่างยิ่งหากสิ่งเหล่านั้นมีค่าใช้จ่ายในการคำนวณสูงหรืออาจส่งผลกระทบต่อข้อมูลอย่างถาวร

·ล้มเหลวอย่างปลอดภัย: ในกรณีที่มีความล้มเหลวรหัสของคุณควรตรวจสอบให้แน่ใจว่ามันปลดล็อคทั้งหมดและไม่ได้รับใหม่ใด ๆ ไม่เขียนไฟล์และอื่น ๆ

·ล้มเหลวอย่างชัดเจน: เมื่อมีบางสิ่งเสียหายมันควรส่งคืนข้อความแสดงข้อผิดพลาดและคำอธิบายที่ชัดเจนซึ่งสามารถเปิดใช้งานทีมสนับสนุนเพื่อแก้ไขข้อผิดพลาด

ตกลง. คุณอาจโต้แย้งที่นี่

ไม่มีปัญหาในปัจจุบัน รหัสของฉันทำงานได้อย่างสวยงาม เหตุใดฉันจึงควรลงทุนเวลาและความพยายามในปัญหา“ ที่คาดการณ์ไว้ในอนาคต” ท้ายที่สุดเราได้รับการสอนให้ใช้“ คุณไม่ต้องการมัน” (YAGNI) และคุณเป็นโปรแกรมเมอร์มืออาชีพไม่ใช่นักอดิเรกที่สามารถเพิ่มรหัสได้ตามต้องการ

กุญแจสำคัญที่นี่คือลัทธิปฏิบัตินิยม

Andrew Hunt ในหนังสือของเขาที่ชื่อว่า Pragmatic Programmer อธิบายการเขียนโปรแกรมเชิงป้องกันในฐานะ“ Pragmatic Paranoia”

ปกป้องรหัสของคุณจากความผิดพลาดของผู้อื่นและความผิดพลาดของคุณเอง หากมีข้อสงสัยให้ตรวจสอบ ตรวจสอบความสอดคล้องของข้อมูลและความถูกต้อง คุณไม่สามารถทดสอบทุกข้อผิดพลาดได้ดังนั้นให้ใช้การยืนยันและเครื่องมือจัดการข้อยกเว้นสำหรับสิ่งที่“ ไม่สามารถเกิดขึ้นได้”

Healthy Paranoid Programming เป็นโปรแกรมที่เหมาะสม แต่ความหวาดระแวงสามารถนำไปไกลเกินไป กุญแจสำคัญที่จะสมดุลที่เหมาะสม

และนี่คือวิธีในการทำโปรแกรมป้องกัน

ถามตัวเองว่า: ถ้าสิ่งนี้ล้มเหลว

ทุกบรรทัดของรหัสทำสิ่งที่จุดแรกของการป้องกันคือถามตัวเองว่ารหัสนั้นล้มเหลวหรือไม่

ตัวอย่างเช่นพิจารณารหัสที่ไม่เข้ากันดังต่อไปนี้

กรณี SY-INDEX // ไม่ปฏิบัติตาม; หายไปเมื่อประโยคอื่น ๆ
เมื่อไหร่
เขียน 'หนึ่ง'
เมื่อ 2
เขียน 'สอง'
ENDCASE

ที่นี่เราสามารถถามคำถามต่อไปนี้

จะเกิดอะไรขึ้นถ้าดัชนี sy ไม่ใช่ 1

จะเกิดอะไรขึ้นหากดัชนี sy ไม่ใช่ 2

เพื่อแก้ปัญหานี้เราเพิ่มคำสั่ง OTHERS

กรณี SY-INDEX
เมื่อไหร่
เขียน 'หนึ่ง'
เมื่อ 2
เขียน 'สอง'
เมื่อคนอื่น ๆ // เป็นไปตามมาตรฐาน
เขียน 'ผลลัพธ์ที่ไม่คาดคิด'
ENDCASE

ง่าย ไม่ใช่เหรอ

นี่คือสิ่งที่“ ถ้าเกิด” คิดว่าแยกโปรแกรมเมอร์ที่ดีออกจากคนที่เขียนโค้ดและหวังว่ามันจะไม่ล้มเหลว “ ไม่เคย” มาเร็วกว่าที่คาดเสมอและจากนั้นรหัสจะถูกฝังในส่วนที่ถูกลืมไปนานของโปรแกรมพร้อมข้อความแสดงข้อผิดพลาดที่ไม่บ่งชี้ว่าปัญหาอยู่ที่ไหนและจะแก้ไขได้อย่างไร

ความสวยงามของเทคนิคการเขียนโปรแกรมป้องกันนี้คือค่าใช้จ่ายเกือบจะไม่มีเวลาที่จะเพิ่มการตรวจสอบประเภทหมดจดในรหัสของคุณ คุณไม่ได้“ เขียนโปรแกรมเกินรหัส” คุณเพียงแค่ "รักษาความปลอดภัย" รหัสของคุณ

ตรวจสอบเงื่อนไขของขอบเขตอย่างระมัดระวัง

การตรวจสอบครั้งแรกคือการตรวจสอบให้แน่ใจว่าคุณต้องการเงื่อนไขขอบเขตเพราะห่วงมีราคาแพง

เงื่อนไขของขอบเขต (หรือขอบ) เป็นสิ่งที่การกระทำทุกอย่างเกิดขึ้น วนซ้ำตั้งแต่ 0 ถึง 100 และค่าลูป 1 ถึง 98 นั้นเหมือนกันมาก (ยกเว้นเงื่อนไขในรหัสของหลักสูตร) แต่ loop 0 เป็นรหัสที่เข้าสู่ loop และเงื่อนไขการเริ่มต้นถูกตั้งค่า (และอาจตั้งค่าผิด) เช่นเดียวกันลูปสุดท้ายคือสิ่งที่ปล่อยทิ้งไว้และลูปใดก็ตามที่ทำกับค่าหยุด

การวนซ้ำที่มีการวนซ้ำอย่างน้อยหนึ่งครั้งจะเท่ากับการใช้คำสั่ง IF เพื่อเรียกใช้โค้ดหนึ่งชิ้นแบบมีเงื่อนไข นักพัฒนาไม่ควรคาดหวังว่าจะพบการใช้งานของคำสั่งวนรอบ หากความตั้งใจเริ่มต้นของผู้แต่งคือการใช้รหัสหนึ่งชิ้นแบบมีเงื่อนไขจริงๆควรใช้คำสั่ง IF แทน

พิจารณารหัสที่ไม่เข้ากันและเข้ากันได้ดังต่อไปนี้ เราไม่จำเป็นต้องวนซ้ำเลยในกรณีนี้ IF ง่ายๆจะทำ

            ตัวอย่างรหัสที่ไม่สอดคล้อง
ส่วนที่เหลือของข้อมูล TYPE i
ทำ 20 ครั้ง
เศษเหลือ = sy-index MOD 2
cl_demo_output => write_text ()
EXIT “ noncompliant วนรอบดำเนินการเพียงครั้งเดียว เราสามารถใช้ IF
ENDDO
          ตัวอย่างรหัสที่ได้มาตรฐาน
ส่วนที่เหลือของข้อมูล TYPE i
ทำ 20 ครั้ง
เศษเหลือ = sy-index MOD 2
cl_demo_output => write_text ()
ENDDO

จดจำการดีบักลูปเสมอเกี่ยวข้องกับความพยายามส่วนใหญ่ในตอนเริ่มต้นและสิ้นสุดตรวจสอบให้แน่ใจว่าสิ่งใดที่เข้ามาและสิ่งที่ออกมานั้นถูกต้อง ดังนั้นเมื่อคุณมีความชัดเจนกับเงื่อนไขขอบเขตไม่มีอะไรจะผิดพลาดกับรหัสของคุณ

ใช้ TDD (ทดสอบการพัฒนาแบบขับเคลื่อน)

แนวคิดพื้นฐานของ TDD คือ“ การทดสอบหน่วยการเขียนครั้งแรกจากนั้นเขียนรหัสจากนั้นทำการรีแฟคเตอร์จากนั้นทำซ้ำ”

การทดสอบหน่วยเป็นการทดสอบอัตโนมัติที่ตรวจสอบว่าฟังก์ชั่นทำงานได้ตามที่คาดหวังหรือไม่ การทดสอบหน่วยแรกของคุณควรล้มเหลวเนื่องจากถูกเขียนขึ้นก่อนที่คุณจะมี codebase ใด ๆ

คุณเพิ่มบิตลงในรหัสกรณีทดสอบ คุณเพิ่มบิตลงในรหัสการผลิต สตรีมโค้ดทั้งสองนั้นเติบโตขึ้นพร้อมกันเป็นองค์ประกอบเสริม การทดสอบที่เหมาะกับรหัสการผลิตเช่นแอนติบอดีเหมาะกับแอนติเจน

ปัญหาของรหัสทดสอบคือคุณต้องแยกรหัสนั้นออก มักจะเป็นการยากที่จะทดสอบฟังก์ชันถ้าฟังก์ชันนั้นเรียกใช้ฟังก์ชันอื่น ในการเขียนการทดสอบนั้นคุณต้องหาวิธีที่จะแยกการทำงานออกจากการทดสอบอื่น ๆ ทั้งหมด ความจำเป็นที่จะต้องทดสอบก่อนบังคับให้คุณคิดเกี่ยวกับการออกแบบที่ดี

สิ่งนี้จะสร้างการออกแบบที่ดีขึ้นและแยกจากกันซึ่งคุณสามารถควบคุมสิ่งต่าง ๆ ได้ดีขึ้นเมื่อรหัสพัฒนาขึ้น

ในขณะที่การเขียนกรณีทดสอบล่วงหน้าอาจใช้เวลานาน แต่สิ่งนี้ให้ประโยชน์มากมาย นักพัฒนายอมรับว่าก่อนหน้านี้พวกเขาเคยเขียนบรรทัดของรหัสตระหนักดีว่าโซลูชันของพวกเขาไม่เกี่ยวข้องแล้วเริ่มเข้ารหัสอีกครั้งตั้งแต่เริ่มต้น

ซึ่งแตกต่างจากวิธีการเข้ารหัสที่ล้าสมัย TDD ช่วยให้นักพัฒนาสามารถกลับไปที่กระดานวาดภาพและมีสมาธิในการออกแบบสถาปัตยกรรมที่มีน้ำหนักเบาและยืดหยุ่นได้ล่วงหน้า

และความเป็นจริงของการเขียนกรณีทดสอบล่วงหน้าป้องกันข้อผิดพลาดใด ๆ ที่อาจปรากฏขึ้นในภายหลังจึงประหยัดเวลาความพยายามและอิจฉาริษยา

เขียนรหัสเพิ่มประสิทธิภาพเสมอ

บางโปรแกรม (และโปรแกรมเมอร์) ชอบแหล่งข้อมูลมากมาย แต่เมื่อใดก็ตามที่คุณสามารถใช้ขั้นต่ำ และเพื่อใช้รหัสขั้นต่ำควรปรับให้เหมาะสมที่สุด

โดยปกติแล้ววิธีการถ่ายภาพเพื่อเพิ่มประสิทธิภาพที่แน่นอนที่สุดคือการเปิดใช้งานการปรับปรุงใด ๆ ที่คอมไพเลอร์ให้

การปรับให้เหมาะสมของคอมไพเลอร์มักจะปรับปรุงการทำงานของรันไทม์จากไม่กี่เปอร์เซ็นต์ไปเป็นปัจจัยที่ 2 บางครั้งมันก็อาจทำให้ผลิตภัณฑ์ช้าลงดังนั้นเพียงแค่ทำการวัดอย่างรอบคอบก่อนทำการโทรครั้งสุดท้าย อย่างไรก็ตามคอมไพเลอร์สมัยใหม่นั้นทำได้ดีพอสมควรในเรื่องนี้เนื่องจากพวกเขาไม่ต้องการการเปลี่ยนแปลงขนาดเล็กมากโดยโปรแกรมเมอร์

นอกจากการปรับแต่งคอมไพเลอร์มาตรฐานแล้วยังมีเทคนิคการปรับแต่งอื่น ๆ อีกมากมายที่สามารถใช้ได้

รวบรวมคำสั่งย่อยทั่วไป

หากการคำนวณที่มีราคาแพงเกิดขึ้นในหลาย ๆ ที่จะเป็นการดีกว่าที่จะคำนวณในที่เดียวและจดจำผลลัพธ์ อย่าวางการคำนวณดังกล่าวไว้ในการวนซ้ำเว้นแต่จะจำเป็น

แทนที่การดำเนินการที่มีราคาแพงด้วยวัตถุราคาถูก

การจัดการสตริงอาจเป็นหนึ่งในการดำเนินการที่พบบ่อยที่สุดในโปรแกรมใด ๆ อย่างไรก็ตามอาจเป็นการดำเนินการที่มีราคาแพงหากทำอย่างไม่ถูกต้อง ในบางกรณีคุณสามารถปรับปรุงประสิทธิภาพโดยการแทนที่การคูณด้วยชุดปฏิบัติการกะ แม้สิ่งนี้จะมีประสิทธิภาพ (และมันก็ไม่เสมอไป) มันสร้างรหัสที่สับสนมาก ดังนั้นให้ตัดสินใจด้วยการพิจารณาความสามารถในการอ่านรหัสด้วย

กำจัดลูป

ลูปส่วนใหญ่เป็นค่าโสหุ้ย พยายามหลีกเลี่ยงการวนซ้ำถ้าเป็นไปได้ถ้าการวนซ้ำไม่มาก

ค่าแคชที่ใช้บ่อย

การแคชใช้ประโยชน์จากพื้นที่แนวโน้มของโปรแกรมและผู้คนในการนำข้อมูลที่ใช้ไปใช้ใหม่มาใช้ซ้ำ การแคชเฉพาะอักขระหรือข้อมูลที่ใช้มากที่สุดจะช่วยปรับปรุงประสิทธิภาพของโปรแกรมอย่างมาก

เขียนซ้ำในภาษาระดับต่ำกว่า

นี่ควรเป็นทางเลือกสุดท้าย ภาษาระดับต่ำกว่ามีแนวโน้มที่จะมีประสิทธิภาพมากขึ้นแม้ว่าจะใช้เวลามากขึ้นในมุมมองของโปรแกรมเมอร์ บางครั้งเราได้รับการปรับปรุงที่สำคัญโดยการเขียนโค้ดที่สำคัญในภาษาระดับต่ำกว่า แต่สิ่งนี้มาพร้อมกับค่าใช้จ่ายในการพกพาลดลงและการบำรุงรักษากลายเป็นเรื่องยากมาก ดังนั้นการตัดสินใจอย่างรอบคอบ

โปรดจำไว้ว่าในการปรับให้เหมาะสมการเลือกอาจเป็น 90% ของเกม คุณควรสละเวลาในการตัดสินใจว่าคุณกำลังทำอะไรและทำถูกต้อง แน่นอน: นั่นก็คือที่ซึ่งมนต์ดำอยู่ด้วย!

และสุดท้ายไม่เชื่อใครเลย

“ มีคนรู้จัก มีหลายสิ่งที่เรารู้ว่าเรารู้” โดนัลด์รัทมเฟลด์รัฐมนตรีว่าการกระทรวงกลาโหมระหว่างการปกครองของบุชครั้งที่สองเคยกล่าวในงานแถลงข่าว “ เรารู้ด้วยว่ามีคนรู้จักนิรนาม กล่าวคือเรารู้ว่ามีบางสิ่งที่เราไม่รู้ แต่ยังมีสิ่งแปลกปลอมที่ไม่ทราบ - สิ่งที่เราไม่รู้จักเราไม่รู้”

รัทมสพูดถึงสงครามในอิรัก แต่ก็มีข้อมูลเช่นเดียวกัน โดยย่อหมายถึงการตรวจสอบข้อมูลทั้งหมดที่คุณไม่สามารถควบคุมได้อย่างสมบูรณ์

เห็นได้ชัดว่าข้อมูลผู้ใช้เป็นที่น่าสงสัยเสมอ ผู้ใช้สามารถเข้าใจผิดในสิ่งที่คุณคิดว่าชัดเจน ลองและคาดการณ์ปัญหาและยืนยันหรือจัดระเบียบทุกอย่างที่เข้ามา

ข้อมูลการตั้งค่าโปรแกรมยังมีแนวโน้มที่จะเกิดข้อผิดพลาด ไฟล์ INI เคยเป็นวิธีการบันทึกการตั้งค่าโปรแกรมทั่วไป เนื่องจากพวกเขาเป็นไฟล์ข้อความหลายคนมีนิสัยชอบแก้ไขด้วยตนเองด้วยเครื่องมือแก้ไขข้อความและอาจเป็นไปได้ที่จะทำให้ค่าเหล่านั้นแย่ลง ข้อมูลรีจิสตรี, ไฟล์ฐานข้อมูล - ใครบางคนสามารถและจะปรับแต่งมันสักวันหนึ่งดังนั้นมันจึงจ่ายเงินเพื่อตรวจสอบแม้กระทั่งสิ่งเหล่านั้น

กล่าวโดยย่อข้อมูลที่เข้ามาจะต้องสะอาดหากคุณมีความหวังว่าโค้ดของคุณจะทำสิ่งที่ตั้งใจจะทำ หากคุณเคยได้ยินวลี“ ขยะมูลฝอยขยะออก” นี่คือที่มาของมัน

อย่างที่ Edward Demming พูดถูกต้องแล้ว

“ ในพระเจ้าเราวางใจ คนอื่น ๆ ทั้งหมดต้องนำข้อมูลมาให้”
เกี่ยวกับผู้แต่ง:
Ravi Rajan เป็นผู้จัดการโปรแกรมด้านไอทีระดับโลกซึ่งตั้งอยู่ที่เมืองมุมไบประเทศอินเดีย เขายังเป็นบล็อกเกอร์ตัวยงนักเขียนบทกวีไฮกุผู้ที่ชื่นชอบโบราณคดีและนักคลั่งไคล้ประวัติศาสตร์ เชื่อมต่อกับ Ravi บน LinkedIn, Medium และ Twitter