ฉันจะสร้างการจัดลำดับความสำคัญใหม่ให้กับทีมของฉันได้อย่างไร

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

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

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

"มันจะดีกว่าถ้าขอการอภัยมากกว่าการอนุญาต" เป็นความจริง

ทำไมต้องเป็นห่วง? เพียงปรับสภาพชิ้นส่วนที่น่ากลัวที่สุด

คุณรู้อยู่แล้วว่าข้อผิดพลาดที่แพงที่สุดใช่ไหม?

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

ระบุจำนวนของตั๋วปัญหาชั่วโมงการแก้จุดบกพร่องและเฉพาะเจาะจงมากวัดมาก ๆค่าใช้จ่าย

จากนั้นแก้ไขบางอย่างในรายการปัญหาค่าใช้จ่ายสูง

เมื่อคุณต้องขออภัยโทษคุณสามารถชี้ไปที่การลดต้นทุน

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

นั่นหมายถึงเลือกสิ่งหนึ่ง เขียนการทดสอบหน่วย แก้ไขสิ่งนั้น คุณได้ทำการปรับปรุงสองครั้ง (1) เขียนการทดสอบและ (2) แก้ไขรหัส

ย้ำ.

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

ฉันจะใช้มุมมองที่เหยียดหยามเกินไป

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

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

ลองพิจารณาการเข้าร่วม บริษัท อื่นที่พวกเขาปฏิบัติงานด้านวิศวกรรมอย่างจริงจังมากขึ้น

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

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

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

1. เพิ่มรหัสเพื่อสุขภาพเท่านั้น
2. แก้ไขรหัสที่ไม่ดีต่อสุขภาพทันทีที่คุณเห็น
3. หากด้วยเหตุผลกำหนดเวลาที่คุณไม่สามารถทำ 1 หรือ 2 ให้มีรายการ "แก้ไขทันทีหลังจากกำหนดเวลา" และไม่ยอมรับข้อแก้ตัวใด ๆ ที่ไม่สามารถทำงานผ่านรายการนั้นได้หลังจากกำหนดเวลา

คำพูดต่อไปจากผู้พัฒนาคือ "แต่เราจะทำเวลาให้ทำได้อย่างไร - เราไม่มีเวลาแล้ว?" คำตอบเดียวที่ถูกต้อง (IMHO อีกครั้ง) คือ "คุณไม่มีเวลาที่จะทำเช่นนี้" หากคุณไม่รักษา codebase ให้แข็งแรงคุณจะพบว่าเวลาที่ใช้ในการฟื้นฟูยาวนานขึ้นเรื่อย ๆ กำหนดเวลาให้คาดเดาไม่ได้มากขึ้นข้อผิดพลาดเริ่มแย่ลงและความคุ้มค่าลดลง

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

ในที่สุดเรื่องราวของการเตือน ถ้ากดฉันจะปฏิเสธเรื่องนี้ไม่เคยเกิดขึ้น ที่ บริษัท ที่ฉันทำงานให้มีแอปพลิเคชั่นที่มีมานานและมีฐาน code ขนาดใหญ่ที่สืบทอดมานานกว่า 10 ปี นักพัฒนาจำนวนมากรวมถึงฉันเชื่อว่า codebase รุ่นเก่านี้ไม่ดีหรือล้าสมัยอย่างน้อยไม่ใช่ state-of-the-art ดังนั้นเราจึงชักชวนให้มีโครงการการปรับโครงสร้างครั้งใหญ่ได้สำเร็จและเริ่มโครงการเขียนใหม่หลังจากที่เราเชื่อว่าทุกอย่างจะดีขึ้น
เราทำงานอย่างหนักและยาวนานในการนำเกือบทุกอย่างไปใช้ในรูปแบบใหม่และทันสมัยโดยใช้ห้องสมุดใหม่คุณลักษณะภาษาใหม่ ใกล้ถึงจุดสิ้นสุดเราพยายามอย่างมากที่จะนำทุกอย่างมารวมกันเพื่อให้แอปพลิเคชั่นรุ่นใหม่ที่มีการใช้งานยาวนานพร้อมด้วยรหัสฐานที่ได้รับการปรับปรุงใหม่
ตามที่คาดไว้รุ่นใหม่มีปัญหาการงอกของฟันเนื่องจากห้องสมุดใหม่ที่เรายังไม่คุ้นเคยและการโต้ตอบบางอย่างในรหัสของเราที่เราไม่ได้คาดการณ์ไว้ อย่างไรก็ตามในที่สุดเราก็จัดการให้ได้มาตรฐานเดียวกันกับรุ่นก่อนหน้าและออกไปข้างนอก เราถอนหายใจด้วยความโล่งอกที่ "ความสำเร็จ" ของเรา จากนั้นกลุ่มย่อยของนักพัฒนากลับไปที่ฝ่ายบริหารเพื่อขอโครงการ refactoring ใหม่เพราะรหัสใหม่ของเราไม่ใช่กระสุนเงินที่พวกเขาคาดหวังว่าจะเป็นและพวกเขาเห็นโอกาสในการเขียนบางสิ่งบางอย่างอย่างสมบูรณ์ ...

คุณธรรมของเรื่องราว: บ่อยครั้งที่สิ่งต่าง ๆ ไม่ได้เกือบจะแตกหักเหมือนที่ปรากฏและ 'เริ่มต้นใหม่' มักจะหมายความว่าคุณจะแลกเปลี่ยนชุดปัญหาที่ทราบด้วยชุดของปัญหาที่ไม่รู้จักที่มีขนน้อยที่สุด Refactor ทีละส่วน!

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

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

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

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

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

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

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

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

นี่คือสิ่งที่ฉันทำในสถานการณ์เช่นนี้ (ใน 15 ปีของการทำงานในฐานะนักพัฒนาที่ฉันเจอรหัสดังกล่าวเกือบทุกวัน)

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

ฝ่ายบริหารไม่ได้จัดสรรเวลาสำหรับการเรียกรหัสซ้ำอีกครั้ง (พวกเขาไม่มีทรัพยากรเพียงพอ!) ดังนั้นการทำอย่างช้า ๆ และสม่ำเสมอเป็นแนวทางที่ถูกต้อง

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

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

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

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

หัวหน้ากลุ่มซอฟต์แวร์และทีมจัดสรรเวลาของทีม

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

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

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

ตัวเลือกโครงการก่อนสร้างวัฏจักรชั่วร้ายสำหรับการปรับโครงสร้างใหม่

การบำรุงรักษาซอฟต์แวร์นั้นยาก มันยากเป็นสองเท่าถ้าคนอื่น ๆ ในองค์กรกำลังตัดสินใจเลือกค่าใช้จ่ายของคุณ สิ่งนี้ผิด แต่ไม่ใช่เรื่องใหม่ มันได้รับการแก้ไขโดย Barry Boehm ซึ่งเป็นหนึ่งในนักเขียนซอฟต์แวร์ที่ยอดเยี่ยมของเราที่นำเสนอรูปแบบการจัดการที่เขาอธิบายว่าเป็นทฤษฎี W.

http://csse.usc.edu/csse/TECHRPTS/1989/usccse89-500/usccse89-500.pdf

บ่อยครั้งที่นักพัฒนาซอฟต์แวร์ใช้ค้อนทุบเพื่อผลิตภายใต้วิธีการจัดการ Theory-X ซึ่งบอกว่าคนงานขี้เกียจโดยทั่วไปและจะไม่ทำงานจนกว่าจะถูกส่งเข้ามา Boehm สรุปและเปรียบเทียบโมเดลที่เสนอของเขาดังนี้:

"แทนที่จะทำให้ผู้จัดการเป็นผู้มีอำนาจเด็ดขาด (ทฤษฎี X), โค้ช (ทฤษฎี Y) หรือผู้อำนวยความสะดวก (ทฤษฎี Z) ทฤษฎี W แสดงบทบาทหลักของผู้จัดการในฐานะผู้เจรจาระหว่างหน่วยงานต่าง ๆ ของเขาและผู้ทำโครงการแก้ปัญหา ด้วยเงื่อนไขการชนะสำหรับทุกฝ่ายนอกเหนือจากนี้ผู้จัดการยังเป็นผู้กำหนดเป้าหมายติดตามความคืบหน้าสู่เป้าหมายและนักกิจกรรมในการค้นหาความขัดแย้งของโครงการที่แพ้และแพ้ในแต่ละวัน และเปลี่ยนพวกเขาเป็นสถานการณ์ที่ชนะ "

เร็วและสกปรกมักจะเป็นเพียงสกปรก

Boehm กล่าวต่อไปถึงเหตุผลที่สิ่งต่าง ๆ มีความสุขสำหรับนักพัฒนาในทีมบำรุงรักษา

"การสร้างผลิตภัณฑ์ที่รวดเร็วและเลอะเทอะอาจเป็น" win "ราคาต่ำระยะสั้นสำหรับนักพัฒนาซอฟต์แวร์และลูกค้า แต่มันจะเป็น '' สูญเสีย '' สำหรับผู้ใช้และผู้ดูแลรักษา" โปรดทราบว่าในรูปแบบของ Boehm ลูกค้าเป็นผู้ดูแลสัญญามากกว่าผู้ใช้ปลายทาง ใน บริษัท ส่วนใหญ่ให้คิดว่าผู้จัดการผลิตภัณฑ์เป็นตัวแทนลูกค้าหรืออาจเป็นบุคคลที่ซื้อผลิตภัณฑ์สำหรับรายการคุณสมบัติ

ทางออกของฉันจะไม่ปล่อยทีมพัฒนาดั้งเดิม (หรืออย่างน้อยนำต้นฉบับ) จนกว่ารหัสจะ refactored อย่างน้อยตามมาตรฐานการเข้ารหัส

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

การเปลี่ยนโครงสร้างไม่สามารถต่อรองได้

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

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

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

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

ฉันคิดว่าคำตอบของวิธีการหาเวลาขึ้นอยู่กับว่าทำไมคุณต้องการ refactor รหัส

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

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

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

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

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

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

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

ปัญหาหลักของคุณคือรหัสไม่ได้รับการเปิดเผยเพียงพอ

ฉันที่แนะนำให้ใช้เครื่องมือการรวมอย่างต่อเนื่องเช่นเจนกินส์และเครื่องมือวิเคราะห์รหัสแบบคงที่ที่รวมอยู่ในนั้นจะวัดความซับซ้อนของวงจรมาตรฐานการตั้งชื่อความยาวโค้ด ฯลฯ

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

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

รหัสได้วิธีนี้ช้ากว่าการเปลี่ยนแปลงเล็กน้อย มันจะต้องแก้ไขด้วยวิธีนั้นเช่นกัน

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

มีการประชุมและกำหนดมาตรฐานการเข้ารหัสที่สอดคล้อง

แนะนำกฏพื้นฐานที่จะใช้ตามที่คุณไป:

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

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

เมื่อใดก็ตามที่โปรแกรมเมอร์แก้ไขไฟล์เขาจะต้องแก้ไขคำเตือนของคอมไพเลอร์ทั้งหมดในไฟล์นั้นและอัปเดตโค้ดเพื่อให้เป็นไปตามมาตรฐานการเข้ารหัสใหม่

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

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

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

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

รหัสอึมักจะไม่แพงเกินกว่าจะแก้ไขได้ หากไม่มีการทดสอบการถดถอยแบบอัตโนมัติค่าใช้จ่ายในการทดสอบรหัส refactored จึงสูงมาก

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

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

แปลกไม่มีใครพูดถึงเรื่องนี้:

เพื่อทำให้สิ่งต่าง ๆ เป็นเรื่องสำคัญทำให้เป็นเรื่องง่าย: รับเครื่องมือการปรับโครงสร้างที่ดี

มีเครื่องมือ refactoring ที่ยอดเยี่ยมอยู่ที่นั่น (อย่างน้อยสำหรับ. NET afaik) โอ้และอย่าลืมเขียนการทดสอบหน่วยล่วงหน้า (เหมือนที่คนอื่นชี้ไปแล้ว)

โชคดี!