ทำให้เป็นเรื่องง่ายในตอนนี้หรือตั้งโปรแกรมโดยคำนึงถึงอนาคต

ฉันกำลังเขียนรหัสแอปพลิเคชันใหม่สำหรับ บริษัท ของฉันที่ค่อนข้างเกี่ยวข้อง เพื่อให้ตรงตามกำหนดเวลาฟังก์ชันการทำงานได้รับการปรับลดลงเล็กน้อยเพื่อให้เราสามารถมีบางสิ่งบางอย่างพร้อมสำหรับการเปิดตัว

ฉันได้รับมอบหมายให้ทำงานเวอร์ชั่น 1 และทำงานภายในสิ้นเดือนนี้ ฉันผ่านการพัฒนาไปครึ่งทางแล้วและฉันก็มาถึงจุดนี้แล้ว

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

ฉันไม่รู้ว่าฉันจะทำ v2 หรือไม่ อาจเป็นฉันหรืออาจเป็นเพื่อนร่วมงานหรือแม้แต่เป็นผู้ฝึกงาน

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

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

หากมีความยืดหยุ่นเพียงพอในกำหนดเวลา (1 วันด้วยเสียงของมันดังนั้นเป้าหมายสำหรับการขยาย 2.5 วัน) จากนั้นแน่นอนไปข้างหน้าและรหัสสำหรับอนาคตที่รู้จักกัน!

หลีกเลี่ยงการตกเป็นเหยื่อ (ต้น) เพื่อผลสองระบบ นี่คือเทคนิคการสมัครที่ดี:

1. หลีกเลี่ยงการแยกรุ่นแน่นอน 1 เนื่องจากสิ่งที่คุณเห็นในเวอร์ชัน 2 การวางแผนล่วงหน้านั้นใช้ได้ แต่ผู้สร้างข้อมูลจำเพาะ v2 ควรรับผิดชอบความล้มเหลวของ v2 ไม่ใช่ v1
2. (ถ้าเป็นไปได้) ดูว่าคุณสามารถให้ผู้สร้างทำงานซ้ำข้อกำหนดสำหรับเวอร์ชัน 2 ที่ไม่ต้องการการเปลี่ยนแปลงที่ใหญ่กว่าตอนนี้หรือไม่จากนั้นวางแผนสำหรับพวกเขาในภายหลังหรืออาจเป็น v3
3. จำไว้ว่าYAGNIแต่ลองใช้รหัสเพื่อเพิ่มความสามารถ - หลีกเลี่ยงตัวเลขเวทย์มนตร์ค่าฮาร์ดโค้ดเขียนการทดสอบหน่วยที่ดีหรือสัญญารหัส ฯลฯ การใช้เทคนิคที่ดีก่อนกำหนดจะทำให้การเปลี่ยนโครงสร้างใหม่และการเปลี่ยนรหัสเจ็บปวดน้อยลง

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

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

• Carl Sagan, Cosmos : http://www.eridanus.info/genesis.html

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

ปล่อยให้มันเป็นอย่างที่มันเป็น

นักพัฒนาจริงชื่นชมโครงการดั้งเดิมที่ทำในสิ่งที่ควรทำและไม่มาก

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

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

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

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

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

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