วิธีเอาชนะการเขียนโปรแกรมโดยบังเอิญ? [ปิด]

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

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

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

ในฐานะนักพัฒนาเรายังทำงานในทุ่นระเบิด มีกับดักนับร้อยรอให้เรามาจับในแต่ละวัน การระลึกถึงเรื่องราวของทหารเราควรระวังในการเขียนข้อสรุปที่ผิดพลาด เราควรหลีกเลี่ยงการเขียนโปรแกรมโดยบังเอิญ - อาศัยโชคและความสำเร็จโดยไม่ตั้งใจ - เพื่อสนับสนุนการเขียนโปรแกรมโดยเจตนา ...

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

แก้ไข:

สรุปจากโพสต์ของคุณ:

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

BTW มันยากที่จะยอมรับคำตอบมันยากจริงๆ คำตอบทั้งหมดนั้นยอดเยี่ยมจริงๆ :)

คุณไม่ต้องคิดล่วงหน้าเพียง แต่ชัดเจนในสิ่งที่ทำและชัดเจนในสิ่งที่คุณทำอยู่ตอนนี้

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

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

เขียนการทดสอบหน่วย การทดสอบหน่วยเหมาะอย่างยิ่งสำหรับการจับภาพพฤติกรรมที่แท้จริงของโค้ดที่คุณเพิ่งเขียนแทนที่จะเป็นพฤติกรรมในอุดมคติที่คุณต้องการค้นหา

ย่อรอบการแก้ไข / รวบรวม / ทดสอบของคุณให้สั้นลง เมื่อคุณเพิ่มโค้ดจำนวนมากและทดสอบได้ไม่ดีอัตราต่อรองก็คือมันจะทำงานแตกต่างจากที่คุณคิด จากนั้นคุณ "แก้ไข" ด้วยการเปลี่ยนแปลงแบบสุ่มและคุณได้คำตอบที่ถูกต้องในขณะนั้น แต่ไม่รู้ว่ามันเกิดขึ้นจริงได้อย่างไร ตอนนี้คุณกำลังเขียนโปรแกรมโดยบังเอิญ แต่เมื่อคุณเพิ่ม 5 บรรทัดแล้วทดสอบโอกาสที่คุณได้คำตอบที่ถูกต้องเพราะมันใช้งานได้ตามที่คุณคิดว่ามันใช้งานได้ดีกว่ามาก ฉันสามารถพูดได้จากประสบการณ์ที่ 5 ชิ้น 10 สายแต่ละการทดสอบแต่ละเป็นสัตว์ที่แตกต่างกันมากกว่า 50 บรรทัดของรหัสทดสอบทั้งหมดในครั้งเดียว

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

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

มันสวยมากเดือดลงไปไม่ต้องเดา โปรแกรมเมอร์ใหม่ส่วนใหญ่ทำ แต่ฉันเห็นทหารผ่านศึกทำเช่นกันเพราะพวกเขาคิดว่ามันช่วยประหยัดเวลาในการวิจัย สิ่งที่ไม่ทำงานเพื่อให้คุณเพิ่ม+1หรือ-1, เปลี่ยนtrueไปfalseหรือในทางกลับกันการสั่งซื้องบบางส่วนเพิ่มหรือความล่าช้าในการเปลี่ยนแปลงลำดับความสำคัญของการเปลี่ยนแปลงด้ายและการแปลงขนาดเล็กอื่น ๆ โดยทั่วไปการทดสอบพีชคณิตแบบสุ่มจนกว่าจะทำงาน

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

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

ความคิดเห็นที่น่ากลัวที่สุดที่ฉันเคยพบในโปรแกรมคือ

อย่าแตะต้องสิ่งนี้ มันได้ผล. เราไม่รู้วิธีหรือเหตุผล แต่มันใช้งานได้ ¹

และมันก็เป็นเพียงแค่น่ากลัวเพราะมันยอมรับว่าชิ้นส่วนของรหัสเป็นผลมาจากการเขียนโปรแกรมโดยบังเอิญ

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

¹สำหรับบริบทความคิดเห็นนี้ปรากฏขึ้นในรหัสที่จัดการสวิตช์บริบทในระบบปฏิบัติการดั้งเดิม รหัสนี้ใช้งานมาหลายปีแล้วเมื่อฉันพบมัน

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

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

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

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

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

(แน่นอนว่าใช้กับโปรแกรมเมอร์ปรุงรสด้วยเช่นกัน แต่ประสบการณ์ของฉันที่นี่ส่วนใหญ่เป็นผู้เริ่มต้นใหม่ที่สมบูรณ์)

มันง่ายเกินไปที่จะเขียนโค้ดทดสอบและแก้ไข "ในสายการแข่งรถ" คุณมีฟังก์ชั่นบางอย่างที่ให้ X & Y, สร้าง Z. แต่ถ้า X เสียหายและ Y ไม่พร้อมใช้งาน? ถ้าคุณไม่สามารถส่งออก Z จงจำไว้เสมอว่าอะไรที่ผิดพลาดและจดบันทึกสำหรับรอบการทดสอบ

รักษากิจวัตรประจำวันของคุณให้สั้นและสื่อความหมาย - รหัสที่ดีที่สุดต้องการข้อคิดเห็นเล็กน้อย (ถ้ามี)

วิธีการที่มีความหมายชื่อคลาสและตัวแปรจะช่วยให้สามารถอ่านได้ง่ายขึ้น

หากคุณเจอกลิ่นรหัสแล้วหยุด กลิ่นนั้นไม่น่าจะหายไปและความพยายามเล็ก ๆ น้อย ๆ ในตอนนี้สามารถช่วยให้คุณเศร้าโศกมากมายในภายหลัง

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

ต่อต้านความอยากที่จะเพิ่มฟีเจอร์เด็ด ๆ (เว้นแต่จะเป็นโครงการสัตว์เลี้ยงของคุณเอง) รหัสพิเศษใด ๆ จะต้องได้รับการออกแบบเขียนทดสอบและดูแลรักษา หากลูกค้า / ธุรกิจไม่จำเป็นต้องใช้ - คุณเสี่ยงที่จะกลายเป็นทรัพยากรจำนวนมาก