คืนดีกฎลูกเสือและการปรับโครงสร้างใหม่โดยมีการตรวจทานโค้ด

ฉันเป็นผู้ศรัทธาที่ยิ่งใหญ่ในกฎลูกเสือ :

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

ฉันยังเป็นผู้เชื่อที่ยอดเยี่ยมในแนวคิดที่เกี่ยวข้องกับการปรับโครงสร้างแบบฉวยโอกาส :

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

ข้อความที่ตัดตอนมาต่อไปนี้โดยเฉพาะอย่างยิ่งจากบทความ refactoring:

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

ที่ที่ฉันทำงานมีการพัฒนาวิธีปฏิบัติหนึ่งที่ทำให้เกิดการเสียดทานอย่างหนัก - Code Review (CR) เมื่อใดก็ตามที่ฉันเปลี่ยนแปลงสิ่งใดก็ตามที่ไม่อยู่ในขอบเขตของ "การมอบหมาย" ของฉันฉันกำลังถูกตำหนิโดยผู้ตรวจสอบของฉันว่าฉันกำลังทำการเปลี่ยนแปลงให้ยากขึ้น นี่เป็นเรื่องจริงโดยเฉพาะอย่างยิ่งเมื่อมีการ refactoring เนื่องจากทำให้การเปรียบเทียบแบบ "ต่อบรรทัด" เป็นเรื่องยาก วิธีการนี้เป็นมาตรฐานที่นี่ซึ่งหมายถึงการปรับโครงสร้างแบบฉวยโอกาสเกิดขึ้นได้ยากและต้องมีการปรับโครงสร้างใหม่ "ตามแผน" (ซึ่งมักจะน้อยเกินไปสายเกินไป) หากเกิดขึ้นจริง

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

(1) ส่วนใหญ่คุณจะตระหนักถึงสิ่งที่และวิธีที่คุณต้องการ refactor เมื่อคุณอยู่ในระหว่างการมอบหมายของคุณ อย่างที่ Martin Fowler กล่าวไว้

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

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

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

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

มีความคิดเกี่ยวกับวิธีที่ฉันจะแก้ไขสถานการณ์นี้ได้อย่างไร

ตกลงดังนั้นตอนนี้มีสิ่งต่าง ๆ ที่นี่มากกว่าเหมาะสำหรับความคิดเห็น

TL; DR

สัญชาตญาณของคุณเกี่ยวกับสิ่งที่คุณควรทำ (refactoring ตามที่คุณไป) ถูกต้อง

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

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

ปัญหาเวิร์กโฟลว์ / สำนักงานการเมือง

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

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

ปัญหา VCS

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

1. หากคุณใช้คอมไพล์คุณมีเครื่องมือที่ยอดเยี่ยมสำหรับเรื่องนี้

   • คุณสามารถใช้git add -iสำหรับการจัดเตรียมแบบโต้ตอบจากบรรทัดคำสั่ง
   • คุณสามารถใช้git guiและเลือกแต่ละ hunks และบรรทัดไปยังสเตจ (นี่เป็นหนึ่งในเครื่องมือ GUI ที่เกี่ยวข้องกับ VCS ไม่กี่อันที่จริง ๆ แล้วฉันชอบที่จะใช้บรรทัดคำสั่ง
   • คุณสามารถทำคอมมิทเล็ก ๆ ได้หลายอย่าง (การเปลี่ยนแปลงเดี่ยว ๆ หรือแก้ไขบั๊กประเภทเดียวกันในหลาย ๆ ที่) จากนั้นเรียงลำดับใหม่รวมเข้าด้วยกันหรือแยกพวกมันด้วย rebase -i

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

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

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

   1. ทำการเปลี่ยนแปลงทดสอบและอื่น ๆ ทั้งหมดของคุณ
   2. ใช้diffเพื่อสร้างไฟล์แพทช์ (บริบทหรือรวม) กับการเปลี่ยนแปลงทั้งหมดตั้งแต่การส่งครั้งล่าสุด
   3. พาร์ทิชันที่เป็นสองไฟล์: คุณจะจบลงด้วยไฟล์ patch หนึ่งไฟล์ที่มี refactorings และอีกหนึ่งไฟล์ที่มีการเปลี่ยนแปลงการทำงาน
      • สิ่งนี้ไม่สำคัญเลยทีเดียว - เครื่องมือเช่นโหมด emacs diff อาจช่วยได้
   4. สำรองทุกอย่างขึ้น
   5. ย้อนกลับไปสู่การคอมมิชชันล่าสุดใช้patchเพื่อเล่นไฟล์แพตช์ไฟล์หนึ่งไฟล์คอมมิตการเปลี่ยนแปลงเหล่านั้น
      • NB หากแพทช์ไม่ได้ใช้อย่างหมดจดคุณอาจต้องแก้ไข hunks ที่ล้มเหลวด้วยตนเอง
   6. ทำซ้ำ 5 สำหรับไฟล์แพตช์ที่สอง

ตอนนี้คุณมีข้อผูกพันสองข้อโดยมีการเปลี่ยนแปลงการแบ่งพาร์ติชั่นอย่างเหมาะสม

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

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

มีความคิดเห็นเกี่ยวกับวิธีการแก้ไขสถานการณ์นี้อย่างไร

ทำสิ่งที่คุณทำต่อไปหรือไม่

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

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

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

ฉันมีความเห็นอกเห็นใจต่อสถานการณ์ของคุณมากมาย แต่มีข้อเสนอแนะที่เป็นรูปธรรมน้อย หากไม่มีอะไรอื่นฉันอาจจะโน้มน้าวให้คุณรู้ว่าสถานการณ์เลวร้ายมันอาจเลวร้ายลง มันอาจจะแย่กว่านั้น :-)

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

รีวิวรหัส

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

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

ฝ่ายบริหารเห็นพ้องว่าเราต้อง "ทำอะไรบางอย่าง" ก่อนที่คุณภาพจะต่ำจนเกินไป :-) คำตอบของพวกเขาคือการวิจารณ์รหัส บทวิจารณ์โค้ดกลายเป็นรายการ "เจ้าจะ" อย่างเป็นทางการเพื่อนำหน้าทุกการเช็คอิน เครื่องมือที่เราใช้คือ Review Board

มันทำงานอย่างไรในวัฒนธรรมที่ฉันอธิบาย ดีกว่าไม่มีอะไร แต่มันเจ็บปวดและใช้เวลานานกว่าหนึ่งปีกว่าจะถึงระดับต่ำสุดของการปฏิบัติตาม บางสิ่งที่เราสังเกตเห็น:

1. เครื่องมือที่คุณใช้มีแนวโน้มที่จะมุ่งเน้นรีวิวรหัสในบางวิธี นี่อาจเป็นปัญหา คณะกรรมการตรวจสอบช่วยให้คุณมีความแตกต่างทีละบรรทัดสีสันสดใสและช่วยให้คุณสามารถแนบความคิดเห็นกับบรรทัด สิ่งนี้ทำให้นักพัฒนาซอฟต์แวร์ส่วนใหญ่ไม่สนใจบรรทัดทั้งหมดที่ไม่เปลี่ยนแปลง ไม่เป็นไรสำหรับการเปลี่ยนแปลงเล็ก ๆ น้อย ๆ มันไม่ดีนักสำหรับการเปลี่ยนแปลงครั้งใหญ่โค้ดใหม่ขนาดใหญ่หรือรหัสที่มีฟังก์ชั่นการเปลี่ยนชื่อ 500 รายการรวมกับฟังก์ชั่นใหม่ 10 บรรทัด
2. แม้ว่าเราจะอยู่ในฐานรหัสเก่าที่ป่วยซึ่งส่วนใหญ่ไม่เคยได้รับการตรวจสอบมาก่อนมันกลายเป็น "ไม่สุภาพ" สำหรับผู้ตรวจสอบที่จะแสดงความคิดเห็นในสิ่งที่ไม่ใช่สายการเปลี่ยนแปลงแม้จะชี้ให้เห็นข้อผิดพลาดที่ชัดเจน "อย่ารบกวนฉันนี่เป็นสิ่งสำคัญในการเช็คอินและฉันไม่มีเวลาแก้ไขข้อบกพร่อง"
3. เลือกซื้อคำวิจารณ์ที่ "ง่าย" บางคนจะดูบทวิจารณ์ 10 ไฟล์โดยมีบรรทัดที่เปลี่ยนไป 2000 บรรทัดเป็นเวลา 3 นาทีแล้วคลิก "จัดส่ง!" ทุกคนเรียนรู้ได้อย่างรวดเร็วว่าคนเหล่านั้นคือใคร หากคุณไม่ต้องการให้โค้ดของคุณถูกตรวจสอบตั้งแต่แรกให้ส่งไปยังผู้ตรวจสอบที่ "ง่าย" คุณเช็คอินจะไม่ช้าลง คุณสามารถคืนความโปรดปรานโดยกลายเป็นผู้ตรวจทาน "ง่าย" สำหรับรหัสของเขา
4. หากคุณไม่ชอบบทวิจารณ์โค้ดเพียงเพิกเฉยต่ออีเมลที่คุณได้รับจาก Review Board ละเว้นการติดตามจากสมาชิกในทีมของคุณ เป็นเวลาหลายสัปดาห์ จนกว่าคุณจะมีบทวิจารณ์ที่เปิดอยู่ 3 โหลในคิวของคุณและชื่อของคุณจะปรากฏในการประชุมกลุ่มสองสามครั้ง จากนั้นเป็นผู้ตรวจสอบที่ "ง่าย" และล้างคำวิจารณ์ทั้งหมดของคุณก่อนอาหารกลางวัน
5. หลีกเลี่ยงการส่งรหัสของคุณไปยังผู้ตรวจทาน "ยาก" (ประเภทนักพัฒนาที่จะถามหรือตอบคำถามเช่นนี้) ทุกคนจะเรียนรู้ได้อย่างรวดเร็วว่าใครเป็นคนวิจารณ์ "ยาก" เช่นเดียวกับที่พวกเขาเรียนรู้สิ่งที่ง่าย หากบทวิจารณ์โค้ดเป็นของเสียเวลา (™) จากนั้นอ่านคำติชมโดยละเอียดเกี่ยวกับรหัสที่คุณเป็นเจ้าของเป็นทั้งของเสียเวลา (™) และดูถูก
6. เมื่อความคิดเห็นเกี่ยวกับโค้ดนั้นเจ็บปวดผู้คนจะนำออกมาและเขียนรหัสต่อไป คุณจะได้รับความคิดเห็นเกี่ยวกับรหัสน้อยลง แต่ทุกคนมีขนาดใหญ่ คุณต้องการบทวิจารณ์โค้ดที่น้อยลงซึ่งหมายความว่าทีมต้องการทราบวิธีทำให้พวกเขาเจ็บปวดที่สุด

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

refactoring

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

แต่รหัสยังคงอยู่ในความต้องการการปรับโครงสร้างอีกครั้ง จะดำเนินการอย่างไร

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

ทำไมคุณไม่ทำทั้งสองอย่าง แต่แยกกันทำ?

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

แต่ถ้าคุณเห็นปัญหาที่เห็นได้ชัดจำนวนหนึ่งมีสองตัวเลือกที่คุณสามารถติดตามได้

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

2. หากการตรวจสอบโค้ดมีปัญหาที่ต้องแก้ไขให้ขอให้ผู้พัฒนาทำการปรับโครงสร้างใหม่ตามคำแนะนำของ Resharper

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

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

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

นอกจากนี้สมมติว่าคุณกำลังทำ TDD หรือ refactor สีเขียวสีเขียวบางรูปแบบวิธีหนึ่งที่จะทำให้แน่ใจว่าคุณได้รับการมีส่วนร่วมจากเพื่อนของคุณคือการใช้เทคนิคการจับคู่ปิงปอง เพียงอธิบายว่าไดรเวอร์ถูกหมุนสำหรับแต่ละขั้นตอนของวงจร RGR คือคู่ที่ 1 เขียนการทดสอบที่ล้มเหลวคู่ที่ 2 แก้ไขมันคู่ refactors 1 คู่ที่ 2 เขียนการทดสอบที่ล้มเหลว .... และอื่น ๆ

อาจเป็นปัญหานี้สะท้อนให้เห็นถึงปัญหาที่ใหญ่กว่ากับวัฒนธรรมองค์กร ดูเหมือนว่าผู้คนให้ความสนใจในการทำ "งานของเขา" มากกว่าที่จะทำให้ผลิตภัณฑ์ดีขึ้นอาจเป็นเพราะ บริษัท นี้มีวัฒนธรรม "โทษ" แทนที่จะเป็นวัฒนธรรมร่วมสมัยและผู้คนดูเหมือนจะสนใจในตัวเองมากกว่ามองภาพผลิตภัณฑ์ / บริษัท ทั้งหมด .

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

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

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

1. อย่า refactor เมื่อคุณไม่สามารถทดสอบการเปลี่ยนแปลงที่ทำกับการทดสอบอัตโนมัติ

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

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

อย่าปรับแต่งส่วนของรหัสที่ต้องมีความรู้เฉพาะโดเมนที่คุณไม่มี

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

แทนที่จะเปลี่ยนชื่อตัวแปรเชิงสำนวนเพียงแค่ใส่ความคิดเห็นเพื่ออธิบายสิ่งที่พวกเขาเป็น หากพวกเขาไม่ใช่สำนวนโปรดเปลี่ยนชื่อพวกเขา อย่าปล่อยให้i, j, k, x, yฯลฯ ลอยรอบเมื่อชื่อที่ดีกว่าจะทำงาน

Rule of thumb สำหรับตัวย่อ: ถ้าเมื่อผู้คนกำลังพูดถึงพวกเขาใช้ตัวย่อมันก็โอเคที่จะใช้ตัวย่อนั้นในรหัส ตัวอย่างจากรหัสฐานที่ทำงาน:

เรามีแนวคิดต่อไปนี้ซึ่งเรามักจะย่อเมื่อพูดถึงพวกเขา: "พื้นที่ของความกังวล" กลายเป็น "AOC", "การระเบิดของเมฆไอ" กลายเป็น VCE สิ่งเช่นนั้น ในฐานรหัสของเรามีคน refactored อินสแตนซ์ทั้งหมดที่เรียกว่า aoc to AreaOfConcern, VCE to vaporCloudExplosion, nPlanes ไปยัง confiningPlanesCount ... ซึ่งทำให้รหัสอ่านได้ยากสำหรับผู้ที่มีความรู้เฉพาะโดเมน ฉันมีความผิดในการทำสิ่งนี้เช่นกัน

สิ่งนี้อาจใช้ไม่ได้กับสถานการณ์ของคุณ แต่มีความคิดของฉันเกี่ยวกับปัญหา

คำถามนี้มีปัญหาที่แตกต่างกันสองประการ - ง่ายต่อการตรวจสอบการเปลี่ยนแปลงในการตรวจทานโค้ดและเวลาที่ใช้ในการปรับโครงสร้างใหม่

ที่ที่ฉันทำงานมีการพัฒนาวิธีปฏิบัติหนึ่งที่ทำให้เกิดการเสียดทานอย่างหนัก - Code Review (CR) เมื่อใดก็ตามที่ฉันเปลี่ยนแปลงสิ่งใดก็ตามที่ไม่อยู่ในขอบเขตของ "การมอบหมาย" ของฉันฉันกำลังถูกตำหนิโดยผู้ตรวจสอบของฉันว่าฉันกำลังทำการเปลี่ยนแปลงให้ยากขึ้น

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

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

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

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

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

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

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

หากคุณสามารถแยกการเปลี่ยนแปลงที่ร้องขอและ refactor ที่ไม่ได้รับการร้องขอเป็นคอมมิชชันแยกต่างหาก (จำนวนมาก) ดังที่บันทึกไว้โดย @Useless, @Telastyn และอื่น ๆ นั่นคือสิ่งที่ดีที่สุดที่คุณสามารถทำได้ คุณจะยังคงทำงานกับ CR เดียวโดยไม่มีค่าใช้จ่ายด้านการดูแลระบบในการสร้าง "refactoring" เพียงแค่ให้ความมุ่งมั่นของคุณเล็กและมุ่งเน้น

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

หัวข้อที่ครอบคลุมรวมถึง:

• ทำความเข้าใจกลไกของการเปลี่ยนแปลงซอฟต์แวร์: การเพิ่มคุณสมบัติการแก้ไขข้อบกพร่องการปรับปรุงการออกแบบการเพิ่มประสิทธิภาพ
• รับรหัสดั้งเดิมในชุดทดสอบ
• การเขียนแบบทดสอบที่ป้องกันคุณจากการแนะนำปัญหาใหม่
• เทคนิคที่สามารถใช้กับภาษาหรือแพลตฟอร์มใด ๆ - ตัวอย่างใน Java, C ++, C และ C #
• ระบุอย่างแม่นยำว่าต้องทำการเปลี่ยนแปลงรหัสที่ใด
• การรับมือกับระบบดั้งเดิมที่ไม่ได้มุ่งเน้นวัตถุ
• การจัดการแอปพลิเคชันที่ดูเหมือนจะไม่มีโครงสร้างใด ๆ

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

ฉันก็เป็นผู้เชื่อที่ยอดเยี่ยมในกฎ Boyscout และ Refactoring ปัญหามักเกิดจากการซื้อการจัดการการปรับโครงสร้างนั้นมาพร้อมกับความเสี่ยงและค่าใช้จ่าย สิ่งที่ผู้บริหารมักมองข้ามคือหนี้ทางเทคนิคก็เช่นกัน

มันเป็นธรรมชาติของมนุษย์ เราคุ้นเคยกับการจัดการกับปัญหาจริงไม่ใช่พยายามป้องกันพวกเขา เรามีปฏิกิริยาไม่ใช่เชิงรุก

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

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

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

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

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

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

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