วิธีการจัดการสิ่งที่ต้องทำในคำขอดึง?

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

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

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

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

• เขียนมันลงในของกระทรวงที่TODO, FIXMEหรือแท็กที่คล้ายกันควรจะหลีกเลี่ยง
• ใช้เครื่องมือวิเคราะห์รหัสแบบคงที่เช่นSonarQubeเพื่อทำเครื่องหมายการสร้างที่ไม่เสถียรโดยอัตโนมัติ
• อนุญาตชั่วคราวหากมีเฉพาะตั๋วที่เกี่ยวข้องในตัวติดตามปัญหาของคุณ จากนั้นรหัสอาจมีลักษณะเช่นTODO [ID-123] Description ...

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

ส่วนตัวผมคิดว่าTODOs มีบางครั้งที่เหมาะสม แต่ไม่ควรใช้พวกเขามากเกินไป นำมาจาก"รหัสสะอาด"ของโรเบิร์ตซี. มาร์ติน: คู่มืองานฝีมือซอฟต์แวร์เปรียว " (หน้า 59):

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

สิ่งที่ต้องทำของพวกเขานั้นไม่ใช่สิ่งชั่วร้าย ฉันเป็นแฟนตัวยงที่จะไม่เพิ่มอีกหนึ่งเลเยอร์และแก้ไข 1 เรื่องต่อตั๋วติดตามเสมอ

ฉันมักจะใช้ TODO หรือ FIXME เป็นวิธีในการเตือนตัวเองว่าฉันต้องการหรือต้องการกลับมาแก้ไขปัญหา

ตัวอย่างเช่นฉันอาจเรียกเพิ่ม (a, b) และเพิ่มสิ่งที่ต้องทำเพื่อ refactor วิธีการเพิ่ม ฉันไม่ต้องการทำงานในวิธีการเพิ่มตอนนี้ แต่ฉันต้องการกลับมา

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

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

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

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

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

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

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

หากโครงการของคุณติดตามรายการที่ค้างอยู่ในซอร์สโค้ดพร้อมTODOความคิดเห็นคุณต้องอนุญาต

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

กฎของเฮ้าส์ # 1 - ทุกคำสัญญาที่มีต่อมาสเตอร์ควรพร้อมสำหรับการทดสอบเนื่องจากต้นแบบถูกสร้างขึ้นทุกวันหลังจากเช็คอินใด ๆ ความมุ่งมั่นเหล่านั้นควรรวมถึงการทดสอบเพิ่มเติมใด ๆ ที่จำเป็น

หากTODOความคิดเห็นนั้นเกิดขึ้นเนื่องจากรหัสไม่เสร็จสิ้นหรือการทดสอบยังไม่เสร็จสิ้นหรือรหัสนั้นยังไม่พร้อมในการทดสอบแสดงว่ารหัสนั้นอยู่ในการคอมมิตไม่ใช่การดึง โทรหาฉันเมื่อพร้อม

House Rule # 2 - ข้อมูลทั้งหมดที่เกี่ยวกับปัญหาที่เปิดอยู่จะถูกเก็บไว้ในตัวติดตามปัญหา ทั้งหมดของมัน. หมายเหตุขีดเขียนลางสังหรณ์อะไรก็ตาม

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

House Rule # 3 - ข้อมูลทั้งหมดเกี่ยวกับงานโครงการที่ค้างอยู่อยู่ในลำดับความสำคัญ (หรือชื่อระบบของคุณสำหรับสิ่งนั้น)

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

หากมีTODOความคิดเห็นที่จะบอกว่ารหัสใหม่จะส่งผลกระทบต่องานที่ค้างอยู่หรือชี้ให้เห็นอย่างอื่นใน codebase ที่ต้องการดูซึ่งถูกค้นพบเมื่อใช้รหัสใหม่ข้อมูลนั้นจะอยู่ในคิวลำดับความสำคัญ งานที่มีอยู่หรือเป็นงานใหม่

กฎของบ้าน # 4 - ข้อเสนอแนะอยู่ในกล่องแนวคิด (หรืออะไรก็ตาม)

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

House Rule # 5 - TODOไม่อนุญาตให้แสดงความคิดเห็นในซอร์สโค้ด ระยะเวลา

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