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

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

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

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

วิธีที่ดีที่สุดในการหลีกเลี่ยงปัญหานี้คืออะไร (ถ้าคุณมี)

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

ข้อเสนอแนะอื่น ๆ ?

นี่ไม่ใช่ปัญหา การก้าวออกจากปัญหาที่น่างงเป็นการชั่วคราวเป็นหนึ่งในวิธีที่ดีที่สุดในการพัฒนาปัญหาดังกล่าว (ไม่ว่าในภายหลังเมื่อคุณกำลังคิดเกี่ยวกับมันหรือในครั้งต่อไปที่คุณนั่งลงด้วยมุมมองที่สดใหม่ / จิตใจ)

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

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

smp7d กล่าวถึงการควบคุมแหล่งที่มาและการแยกเป็นวิธีที่ดีในการแยกรหัสคุณลักษณะใหม่ของคุณออกและดูว่ามันแตกต่างจากฐานรหัสหลักอย่างไร

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

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

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

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

เป็นประสบการณ์ของฉันที่ "กระโดดไปรอบ ๆ " หรือชัดเจนกว่า "กระโดดไปรอบ ๆ แบบสุ่ม" เป็นอาการของปัญหาเร่งด่วนมากขึ้นซึ่งเป็นหนึ่งในเป้าหมายที่ระบุไว้ไม่ดี

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

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

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

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

หากคุณมีงานที่ดี (เช่นสำหรับโครงการส่วนตัว) การ "กระโดดไปรอบ ๆ " นั้นดีและปลอดภัยและมีประโยชน์โดยสิ้นเชิง

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

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

บางครั้งอาจมีประโยชน์ในการ จำกัด จำนวนของคุณลักษณะที่มีการใช้งานแบบขนาน ปฏิเสธที่จะเริ่มใช้คุณลักษณะพิเศษหากเกินขีด จำกัด นั้นจนกว่าจะมีคุณลักษณะอื่นเสร็จสิ้น วิธีการนี้เรียกว่าKanban