เวิร์กโฟลว์แก้ไขสิ่งที่ไม่ได้อยู่ในงานปัจจุบันของคุณ


12

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

ที่นี่ฉันเห็นสามตัวเลือก:

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

นี่อาจเป็นพื้นฐานค่อนข้าง แต่มีวิธีใดบ้างที่จะหลีกเลี่ยงสิ่งนี้โดยใช้ svn / git / other?



ฉันมักจะไปกับตัวเลือกที่ 2 แต่ถ้าฉันทำการรีเฟรชมากฉันก็แยกกันทำสองอย่าง 1 สำหรับงานที่เฉพาะเจาะจงของฉันและอีกเพียงแค่ระบุว่าเป็น "Refactoring" ซึ่งผมแทนrebase merge
Alternatex

คำตอบ:


7

โดยส่วนตัวฉันคิดว่ามันขึ้นอยู่กับ :-)

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

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


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

@Nattfrosten: ใช่มันเป็นเรื่องธรรมดาและไม่เลวเลย - โดยปกติแล้วการโฟกัสควรอยู่ที่การเข้ารหัส การจัดการรหัส ist เพียงเพื่อให้การเขียนโปรแกรมง่ายขึ้น
sleske

5

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

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

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

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


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

ข้อสรุปที่เหมือนกัน แต่มักจะเป็นผู้บังคับบัญชาที่ตัดสินใจเลือกคุณสมบัติใหม่และไม่ทำการปรับโครงสร้างใหม่: - |
Mark Hurd
โดยการใช้ไซต์ของเรา หมายความว่าคุณได้อ่านและทำความเข้าใจนโยบายคุกกี้และนโยบายความเป็นส่วนตัวของเราแล้ว
Licensed under cc by-sa 3.0 with attribution required.