ฉันจะได้รับเงินเพื่อลดหนี้ทางเทคนิคได้อย่างไร

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

ลูกค้าพูดถึงคุณลักษณะใหม่มูลค่าทางธุรกิจและอื่น ๆ เท่านั้น ปัญหาคือแม้ว่ารหัสอยู่ใน C # มันค่อนข้างขั้นตอน ไม่มี abstractions จะใช้คลาสที่ Visual Studio ต้องการเท่านั้น - ฟอร์มเป็นต้น การใช้งานของคลาสเหล่านี้แย่จริงๆและรหัสยากที่จะรักษา

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

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

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

ความคิดใด ๆ

ขั้นตอนที่ 1: หยุดทำงานล่วงเวลาที่ค้างชำระ

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

ขั้นตอนที่ 2: ทำบันทึก

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

... รหัสนี้ยากต่อการบำรุงรักษา

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

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

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

ใช้กฎลูกเสือ : ปล่อยให้รหัสเป็นระเบียบเล็กน้อย (เช่นมีหนี้สินทางเทคนิคน้อยกว่า) ทุกครั้งที่คุณสัมผัส

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

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

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

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

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

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

คุณต้องแสดงให้ผู้บริหารเห็นว่าการปรับโครงสร้างและการปรับปรุงผลิตภัณฑ์จะเป็นประโยชน์ต่อ บริษัท อย่างไร

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

ดังนั้น ... คุณต้องโน้มน้าวฝ่ายบริหารว่าการเปลี่ยนแปลงที่คุณเสนอจะช่วยให้ บริษัท :

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

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

แน่นอนเขาต้องห่อมันไว้ในอุปมายานยนต์เพื่อให้ผู้ชมของเขาสามารถเกี่ยวข้องกับมันได้

"ชิ้นหนึ่งครั้ง" - จอห์นนี่เงินสด

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

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

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

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

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

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

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

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

และอย่าลืมคำนึงถึงปัจจัยในเครื่องมือที่ดีกว่า Resharper เป็นเครื่องมือ refactoring ที่ยอดเยี่ยมที่เชื่อมต่อกับ Visual Studio