ลัทธิพอใจ แต่สิ่งดีเลิศอาจดีและไม่ดีเมื่อเขียนโปรแกรม
โปรดแสดงความคิดเห็นหากคำถามไม่ชัดเจน
คำตอบ:
สร้างโซลูชันสำหรับสิ่งที่คุณรู้ว่าคุณต้องการในไม่ช้า อย่าสร้างมันสำหรับสิ่งที่อาจจำเป็นในสองปีเพราะส่วนใหญ่คุณจะต้องการสิ่งที่แตกต่างกันมากและจะต้องสร้างมันใหม่
ช่วงเวลาที่คุณเริ่มพูดถึง "ด้วยการออกแบบนี้ในบางจุดในอนาคตที่เราสามารถทำ X หรือแม้แต่ Y" แทน "การออกแบบนี้ช่วยให้เราสามารถทำตามความต้องการของลูกค้า Z ในรุ่นถัดไป" นั่นคือเมื่อคุณได้รับ สถาปัตยกรรมดาราศาสตร์
เพื่อตอบสนองต่อความคิดเห็น:
YAGNIจนกระทั่งวันนี้
ใช้วิธีการวนซ้ำและปัญหานี้ส่วนใหญ่หายไป คุณควรใช้รหัสในวันแรกและเกือบทุกวันหลังจากนั้น ตอบสนองความต้องการขั้นต่ำก่อนและเพิ่มมากขึ้นเมื่อคุณมีเวลา อย่าพลัดหลงจากการเปลี่ยนแปลงครั้งใหญ่ที่คุณไม่สามารถเรียกใช้รหัสของคุณเป็นเวลานาน
การแก้ปัญหานั้นเกินความจริงเมื่อเวลาพิเศษที่จะทำให้เสร็จสมบูรณ์นั้นมีค่ามากกว่าผลกระทบด้านลบที่อาจเกิดขึ้นจากเมื่อการแก้ปัญหาที่ง่ายขึ้นสิ้นสุดลงเมื่อจะทำการอัพเกรด / แก้ไขโดยธรรมชาติในครั้งต่อไป
โดยพื้นฐานแล้วคุณกำลังซื้อขายในเวลานี้พร้อมกับเวลาในภายหลัง หากคุณใช้เวลามากขึ้นในตอนนี้คุณจะประหยัดได้ในภายหลังคุณกำลังทำผิด หากคุณอยู่เหนือวิศวกรรมคุณกำลังใช้เวลาในขณะนี้ซึ่งไม่ส่งผลกระทบต่อจำนวนเวลา (หรือทำให้มากขึ้น) ที่คุณใช้ในภายหลัง
คุณจะได้รับประสบการณ์การทำงานที่ดียิ่งขึ้น วิธีที่ดีที่สุดในการทำสิ่งต่าง ๆ (จากประสบการณ์ของฉัน) คือการทำสิ่งที่คุณต้องการในตอนนี้ แต่ในลักษณะที่สามารถเติมได้ง่ายที่สุดในภายหลังควรมีความต้องการ หาวิธีการทำเช่นนั้นเป็นบิตที่ยุ่งยาก
ฉันเคยเป็นพวกชอบความสมบูรณ์แบบมาก (ใช้เวลาในการสร้างกรอบไม่ใช่วิธีแก้ปัญหา)
แต่สิ่งที่ช่วยฉันเร่งการผลิตของฉันคือการเรียนรู้และทำตามหลักการ BDD / TDD รวมถึงหลักการภายนอก (ซึ่งฉันพบว่ายากที่จะเรียนรู้ที่จะโอบกอด)
สิ่งนี้สอนฉันไม่ให้เขียนโค้ดบรรทัดเดียวก่อนที่จะมีการทดสอบ แต่การทดสอบหน่วยไม่มีอยู่ก่อนที่จะมีการทดสอบการยอมรับ และการทดสอบการยอมรับนั้นมาจากความต้องการของผู้ใช้จริง
ดังนั้นทุกบรรทัดของรหัสมาจากความต้องการของผู้ใช้จริง
หากคุณไม่คุ้นเคยกับหลักการภายนอกมันบอกให้คุณเริ่มเขียนการทดสอบสำหรับเลเยอร์ชั้นนอกสุดในแอปพลิเคชันของคุณ (เช่น GUI ในแทบทุกกรณี) โดยใช้การทดสอบทวีคูณเพื่อจำลองพฤติกรรมของเลเยอร์ที่ต่ำกว่า จากนั้นคุณก็ใช้งานได้เพียงพอสำหรับการทดสอบที่จะผ่าน การนำเลเยอร์ด้านบนนี้ไปใช้สั่งการทดสอบที่คุณต้องเขียนสำหรับเลเยอร์ถัดไปเป็นต้นจนกว่าคุณจะตีเลเยอร์ด้านล่างของแอปพลิเคชันของคุณ
ฉันสังเกตเห็นว่าฉันดีขึ้นจากประสบการณ์นี้
เมื่อฉันยังเด็กฉันมักจะไปหาทางออกที่สมบูรณ์แบบที่สุดเสมอไม่มีการประนีประนอม ตอนนี้ฉันควรเก็บเรื่องต่าง ๆ เช่นงบประมาณและเวลาไว้ในใจ
เวลาที่ จำกัด วาดเส้นนี้ค่อนข้างชัดเจน
เจ้านายของฉันทำจริง ๆ :)
ฉันต้องยอมรับว่าฉันเริ่มดีขึ้นแล้ว แต่ฉันก็ยังไม่มากนักสำหรับการประนีประนอม โชคดีที่ฉันมีหัวหน้าของฉันที่จะพาฉันไป;)
ฉันต้องการที่จะเพิ่มปัญหาอีกกว่าการ overengineering เนื่องจากการ overengineering นั้นง่ายต่อการตรวจจับ
ปัญหาหลักของฉันคือการปรับโครงสร้างใหม่ ปัญหาคือเกือบทุกครั้งแม้ว่าฉันพยายามเขียนโค้ดให้ดีที่สุดเท่าที่จะทำได้ฉันก็ไม่รู้ตอนนี้สิ่งที่ฉันรู้ตอนนี้ (เห็นรหัสเพิ่มเติมรูปแบบมากขึ้นสำนวนใหม่ปัญหาใหม่ใหม่ การแก้ปัญหา) ถึงแม้ว่ามันจะได้ผลฉันก็รู้วิธีที่ดีกว่าในการทำ:
อย่างไรก็ตามมันใช้งานได้ตามปกติดังนั้นจึงไม่จำเป็นต้องให้ความสำคัญเป็นพิเศษและความจริงก็คือมันดุด่าฉัน ฉันเข้าใจเหตุผลทางเศรษฐกิจและเข้าใจความคาดหวังของลูกค้า (พวกเขาไม่เห็นรหัสและชอบคุณสมบัติใหม่และการแก้ไขข้อบกพร่อง) แต่ฉันหวังว่าฉันจะมีเวลาทำงานต่อไป
สำหรับตอนนี้ฉันเพิ่งทำตามคำสั่งของเจ้านาย แต่ฉันต้องยอมรับว่าฉันรู้สึกไม่สบายใจที่รู้ว่ารหัสที่ส่งมอบในการผลิตนั้นไม่ใช่สิ่งที่ดีที่สุดที่ฉันสามารถทำได้ตอนนี้ ความสมบูรณ์แบบฉันเดา
ทั้งมืออาชีพและส่วนตัวมาตรฐานที่ฉันพยายามนำไปใช้กับตัวเองคือ:
จงพอใจกับการชนะ
หากรหัสของฉันแก้ปัญหาได้หมายถึงการแก้ปัญหาและไม่ได้สร้างปัญหาใหม่ ๆ * นั่นเป็นโอกาสที่จะดำเนินการต่อไป เมื่อคุณเรียนรู้ที่จะตั้งค่าบาร์ให้สูงที่สุดเท่าที่จำเป็นจะต้องตั้งค่า "ดีพอ" จะกลายเป็นดีพอ
ความสมบูรณ์แบบเปรียบได้กับความเร็วของแสง: คุณจะไม่มีวันไปถึงที่นั่น แต่ไม่ จำกัด พลังงานที่คุณสามารถลองได้
(* - โปรดทราบว่า "Buggy" และ "ยากที่จะรักษา" ทั้งคู่ตกอยู่ภายใต้หัวข้อ "ปัญหาใหม่" อย่างแน่นหนาดังนั้นฉันจึงไม่เรียกมันว่าสมบูรณ์จนกว่ารหัสจะถูกทดสอบ เอกสารความคิดเห็น / API เป็นข้อมูลล่าสุด)
ด้วยประสบการณ์ที่ฉันได้ตระหนักว่าลัทธิพอใจ แต่สิ่งดีเลิศนั้นเป็นไปไม่ได้จนกระทั่งฉันได้รับอย่างน้อยสองสามปีในบริบทใด ๆ (ภาษา, กรอบ, แพลตฟอร์ม, มาตรฐาน) ในฐานะที่เป็นมือใหม่จะมีไอเดียแปลก ๆ ทุกประเภทที่คุณจะไม่ได้รับรู้ (การหลบหนี, มาก่อน, คำสงวน, น้ำตาลทรายประโยค, หมดเวลา, การโทรแบบอะซิงโครนัส, คุณสมบัติที่ไม่มีเอกสารและข้อบกพร่อง) ในขณะที่เรียนรู้ให้มากที่สุด ที่สำคัญฉันมักจะพยายามที่จะทำให้มันง่ายที่จะ refactor ผล - สถาปัตยกรรม Modular, ความเห็นของที่จำเป็นและไม่มีเทคนิคฉลาด
ฉันก็เหมือนกับโปรแกรมเมอร์คนอื่น ๆ หลายคนที่มีรหัสดั้งเดิมมากมายเพื่อรักษาไว้ การล่อใจที่จะทำซ้ำทั้งหมดจะอยู่ที่นั่นเสมอ แต่ฉันได้ต้มมันลงในหลักการเดียว:
ฉัน (หรือคนอื่น) จะต้องคิดเรื่องนี้อีกครั้งหรือไม่?
ซึ่งมักจะดูแลสปาเก็ตตี้โค้ดจำนวนมากให้เป็นสปาเก็ตตี้ - อ้วน สรุปชิ้นส่วนบางส่วนทิ้งการทดสอบของคุณและตอนนี้มันดูไม่ต้องการความสมบูรณ์แบบมากนัก