คุณพูดว่าอะไรในการตรวจสอบโค้ดเมื่อบุคคลอื่นสร้างโซลูชันที่ซับซ้อนเกินควร [ปิด]

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

ในสถานการณ์นี้ฉันถามว่า "ทำไมมันถึงทำแบบนี้?"

คำตอบคือคนอื่นรู้สึกเหมือนทำอย่างนั้น

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

คำตอบคือไม่

ดังนั้นฉันขอแนะนำให้เขาลบความซับซ้อนที่ไม่จำเป็นทั้งหมด คำตอบที่ฉันมักจะได้รับคือ "ทำได้ดีอยู่แล้ว"

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

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

การตอบสนองที่เหมาะสมกับทัศนคตินี้คืออะไร?

ความคิด / ทัศนคติ

• นำโดยตัวอย่าง
• ตักเตือนเป็นส่วนตัว (หนึ่งต่อหนึ่งนอกการตรวจสอบรหัส)
• ส่งเสริมความคิดแบบ Keep-it-simple ในหมู่สมาชิกในทีม

การจัดการทีม

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

ระดับทักษะ

• จัดสรรเวลาสำหรับเซสชันการเขียนโปรแกรมคู่หรือเซสชันการฝึกอบรมแบบตัวต่อตัวสำหรับการใช้เครื่องมือของนักพัฒนาซอฟต์แวร์ให้ดีที่สุด (การรีแฟคเตอร์ตรวจสอบโค้ด)

การจัดการโครงการ (ความเสี่ยง)

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

คุณพูดว่าอะไรในการตรวจสอบโค้ดเมื่อบุคคลอื่นสร้างโซลูชันที่ซับซ้อนเกินควร

คุณพูดว่า: "คุณสร้างโซลูชันที่ซับซ้อนมากเกินไป"

ดังนั้นฉันขอแนะนำให้เขาลบความซับซ้อนที่ไม่จำเป็นทั้งหมด คำตอบที่ฉันมักจะได้รับคือ "ก็เรียบร้อยแล้ว"

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

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

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

ดังนั้นฉันขอแนะนำให้เขาลบความซับซ้อนที่ไม่จำเป็นทั้งหมด คำตอบที่ฉันมักจะได้รับคือ "ทำได้ดีอยู่แล้ว"

นั่นไม่ใช่คำตอบที่ยอมรับได้:

• ถ้ามันเป็นความจริงที่สายเกินไปที่จะเปลี่ยนแปลงแล้วตรวจสอบรหัส WSS ส่วนใหญ่เสียเวลาและการจัดการความรู้นี้

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

และ ...

... วิธีแก้ปัญหาไม่สามารถใช้งานได้อย่างสมบูรณ์ ...

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

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

การตอบสนองที่เหมาะสมกับทัศนคตินี้คืออะไร?

ท้ายที่สุดนำมันมาสู่ความสนใจของฝ่ายบริหาร ... เว้นแต่คุณจะมีอำนาจในการแก้ไขด้วยตัวเอง (แน่นอนสิ่งนี้จะไม่ทำให้คุณโด่งดัง)

คุณพูดถูกพวกเขาผิด:

• หลักการของYAGNI ที่หัก
• หลักการจูบขาด
• รหัสทดสอบอย่างเต็มที่? ถ้าไม่เช่นนั้นก็ไม่ได้ทำ

การตอบสนองที่เหมาะสมกับทัศนคตินี้คืออะไร?

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

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

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

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

คุณควรมุ่งเน้นที่สาเหตุของปัญหา:

1. การศึกษาของโปรแกรมเมอร์มุ่งเน้นไปที่การเพิ่มความซับซ้อนให้กับโปรแกรมเมอร์ ความสามารถในการทำสิ่งนี้ถูกทดสอบโดยโรงเรียน โปรแกรมเมอร์จำนวนมากจะคิดว่าถ้าพวกเขาใช้วิธีแก้ปัญหาอย่างง่ายพวกเขาไม่ทำงานอย่างถูกต้อง
2. หากโปรแกรมเมอร์ทำตามรูปแบบเดียวกันเขาได้ทำหลายร้อยครั้งในขณะที่อยู่ในมหาวิทยาลัยมันเป็นความคิดของโปรแกรมเมอร์ - ความซับซ้อนมากขึ้นนั้นท้าทายมากขึ้นและดีขึ้นกว่าเดิม
3. ดังนั้นในการแก้ไขปัญหานี้คุณจะต้องแยกความต้องการของ บริษัท ของคุณอย่างเข้มงวดเมื่อเทียบกับความซับซ้อนเมื่อเทียบกับสิ่งที่จำเป็นในการศึกษาของโปรแกรมเมอร์ แผนการที่ดีคือกฎเช่น "ระดับความซับซ้อนสูงสุดควรสงวนไว้เฉพาะสำหรับงานที่ออกแบบมาเพื่อพัฒนาทักษะของคุณ - และไม่ควรใช้ในรหัสการผลิต"
4. มันจะกลายเป็นแปลกใจที่โปรแกรมเมอร์จำนวนมากที่พวกเขาไม่ได้รับอนุญาตให้ทำการออกแบบที่บ้าคลั่งที่สุดในสภาพแวดล้อมของรหัสการผลิตที่สำคัญ เพียงแค่สำรองเวลาสำหรับโปรแกรมเมอร์ที่จะทำการออกแบบการทดลองและจากนั้นรักษาความซับซ้อนทั้งหมดในด้านของรั้ว

(ในการตรวจสอบรหัสมันสายเกินไปที่จะเปลี่ยนแปลง)

ฉันไม่รู้อะไรเลยว่าใช้ได้หลังจากเขียนโค้ดแล้ว

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

มีวิธีการอื่นที่ใช้งานได้กับผู้รับเหมา - สัญญาที่มีราคาคงที่ วิธีแก้ปัญหาที่ง่ายกว่าคือยิ่งโปรแกรมเมอร์มีค่ามากขึ้น

คุณไม่สามารถแก้ไขโลก

คุณไม่สามารถแก้ไขรหัสทั้งหมดในโครงการของคุณได้ คุณอาจไม่สามารถแก้ไขแนวทางการพัฒนาในโครงการของคุณอย่างน้อยก็ไม่ใช่เดือนนี้

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

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

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

ควรมีนโยบายมาตรฐานในโครงการที่ควบคุมกระบวนการตรวจสอบคุณภาพและเครื่องมือที่ใช้

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

หากคุณยังไม่ได้ทำสิ่งนี้ให้จัดการความคิดของคุณและทำมัน

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

ร้านค้าของคุณต้องบังคับใช้วิธีการออกแบบบางอย่าง

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

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

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

การพูดว่า "นี่ซับซ้อนเกินไป" ทำให้คุณไม่มีที่ไหนเลย

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

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

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

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

หากคุณพบปัญหา (ซับซ้อนเกินไป) ให้พูดอะไรที่เป็นรูปธรรมมากขึ้นเช่น:

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

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

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

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

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

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

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

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

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

หนึ่งคำ: เปรียว

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

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

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

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

คุณไปที่ coder หลังจากลบ / ย้อนกลับรหัสของพวกเขา: "อ๊ะรหัสของคุณได้หายไปโปรดเขียนใหม่ตามที่คุณได้เขียนไว้เมื่อคุณต้องใช้เวลาน้อยกว่ายี่สิบนาทีในการให้รหัสเฉพาะตามข้อกำหนดเท่านั้น

"ความเห็นครั้งต่อไปของฉันคือภายใน 20 นาที

"ขอให้เป็นวันที่ดี."

อย่ายอมรับข้อโต้แย้งใด ๆ !

เสร็จแล้ว IMHO

คริส