คุณรับมือกับโค้ดที่น่าเกลียดที่คุณเขียนได้อย่างไร [ปิด]

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

คุณทำอะไร? หยุดการเป็นโรค OCD และเพียงยอมรับว่ารหัสของคุณกำลังยุ่งเหยิงไม่ว่าคุณจะทำอะไร บันทึกการทำความสะอาดสำหรับรุ่น 2 หรือไม่

หางานใหม่และให้คนอื่นจัดการกับมัน Muahahahhahahaa

.....

แค่ล้อเล่น. :)

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

เคล็ดลับอื่น (ที่เกี่ยวข้อง): ประเมินขนาดเล็กที่ดูเหมือนจะไม่มีงานง่าย ๆ ให้กับบล็อกขนาดที่เหมาะสม ตัวอย่างเช่น - รายการที่คุณเกือบแน่ใจว่าจะเป็นเพียงการเปลี่ยนแปลงหนึ่งบรรทัด 30 วินาทีอย่างง่าย - ให้เวลา 1 ชั่วโมง (หรืออาจเป็นบล็อกเวลาต่ำสุดที่อยู่ในแผ่นเวลาหรือระบบ CR ของคุณเช่น 15 นาที / 0.25 ชั่วโมง) . และมอบบล็อคครึ่งวันหรือ 1 วันสำหรับรายการที่ใหญ่กว่าเล็กน้อย แต่ยังค่อนข้างไม่สำคัญ

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

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

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

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

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

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

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

ด้วยความคิดเห็นทั้งหมดเกี่ยวกับการประเมินที่มากเกินไปฉันคิดว่ามีจุดจำนวนเล็กน้อย (โอกาสที่ดี) ที่พลาดไป

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

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

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

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

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

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

1) การควบคุมการเปลี่ยนแปลงที่เหมาะสมคือเพื่อนของคุณ

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

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

2) การปรับโครงสร้างใหม่ควรทำเช่นนั้นซึ่งจะให้ประโยชน์ระยะยาวแก่ลูกค้าอย่างแท้จริง

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

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

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

ฉันมีความคิดเห็นต่อไปนี้ในฐานรหัสที่ฉันกำลังทำงานอยู่:

/*
 * Every time I see this function, I want to take a shower.
 */

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

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

การตั้งค่าของฉันคือการหลีกเลี่ยงสถานการณ์นี้ในสถานที่แรก

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

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

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

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

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

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

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

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

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

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

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

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

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

พึ่งพาพลังที่สูงกว่า

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

ในการไหลของโครงการปกติข้อกำหนดทั่วไปควรจะถูกแช่แข็งก่อนที่จะเกิดการพัฒนาที่จริงจัง

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

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

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

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

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

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

กล่าวโดยย่อ: แทนที่จะติดตั้งป้อมปืนเข้ากับ Ferrari สีแดงให้พิจารณาข้อกำหนดและสร้างรถถังใหม่

ฆ่ามันด้วยไฟ.

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

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

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

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

การใช้ประสบการณ์ของคุณเพื่อกำหนดเวลา / ค่าใช้จ่ายของแต่ละฟีเจอร์จากนั้นบอกพวกเขาหากพวกเขาต้องการสิ่งนี้มันจะใช้เวลาและจำนวนเงิน x

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

บอกพวกเขาเมื่อคุณมีรายการสุดท้ายว่าคุณจะทำการปรับเปลี่ยนในอนาคตตามที่พวกเขาต้องการ แต่ต้องมุ่งเน้นไปที่ 15/20 อันดับแรกที่พวกเขาต้องมีในตอนนี้

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

เมื่อมีการตัดสินใจขั้นสุดท้ายเกี่ยวกับสิ่งที่ต้องทำสำหรับรุ่นปัจจุบันการอภิปราย / ความคิด / ข้อเสนอแนะทั้งหมดจะต้องหยุด 100%

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

หากพวกเขายังคงเสียเวลาของคุณให้เปลี่ยนใจ จากนั้นฉันก็จะหยุดทำงานในโครงการและทำงานในโครงการอื่น ๆ จนกว่าพวกเขาจะสรุปการตัดสินใจของพวกเขา ..

เป็นการยากที่จะทำ แต่การคืบของขอบเขตคุณลักษณะเป็นการทำลายเวลาพลังงานแรงจูงใจและการคิดที่ชัดเจน

จากมุมมองที่สมบูรณ์ของโครงการ:

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

จากมุมมองในการพัฒนา:

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

จากมุมมองการวางแผน:

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