ฉันจะโน้มน้าวให้ฝ่ายบริหารจัดการกับหนี้ทางเทคนิคได้อย่างไร


158

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

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


5
"ทำงานกับนักพัฒนา" "สื่อสารสิ่งนี้กับฝ่ายบริหาร" คุณถามเรื่องอะไร นักพัฒนาหรือผู้จัดการ? คุณต้องการเปลี่ยนพฤติกรรมของใคร
S.Lott

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

7
Mike> ฉันคิดว่าคุณมีชีวิตอยู่ในโลกที่มีข้อ จำกัด น้อยกว่าเนื่องจากกำหนดเวลาและงบประมาณที่ จำกัด ครอบงำโลกที่ฉันอาศัยอยู่หากซอฟต์แวร์ไม่สามารถปรับตัวให้เข้ากับความต้องการในอนาคตได้และต้องการงานจำนวนมากในการแก้ไข มันและให้ bolting กับคุณสมบัติ ตอนนี้ companines จำนวนมากที่ฉันได้ทำงานในการใส่ timesheets ในสถานที่ดังนั้นนักพัฒนาจำเป็นต้องบันทึกงานของพวกเขาและถ้าเวลาไม่ได้มีการลงทุนในที่ผู้บริหารเห็นธุรกิจที่มีศักยภาพแล้วคุณเสียเวลาของคุณ
Desolate Planet

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

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

คำตอบ:


191

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

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

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


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

4
+1 คุณแบ่งปันความรู้สึกของฉันอย่างแน่นอน ... ยกเว้นคุณแสดงตัวเองอย่างมีชั้นเชิงมากขึ้น)
Michael Brown

7
คำตอบที่ดี. ฉันยังเห็นธุรกิจที่ยินดีเซ็นสัญญากับโครงการ 'refactoring' ซึ่งจะไม่ก่อให้เกิดประโยชน์กับลูกค้าเพียงรหัสที่เป็นระเบียบเท่านั้น Refactor as-you-go
JBRWilkinson

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

8
@ jmort253: มีปัญหาหนึ่ง (เล็กน้อย) กับนโยบายที่ยอดเยี่ยมนี้ -> มันเป็นไปไม่ได้สำหรับการเปลี่ยนแปลงที่ครอบคลุม (เช่นการเปลี่ยนฐานข้อมูลตามที่กล่าวโดย OP) สิ่งเหล่านั้นจะต้องได้รับการจัดการอย่างชัดเจน
Matthieu M.

48

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

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

ฉันคิดว่าฉันชอบสิ่งที่ Renesis กล่าวในคำตอบของเขาเพราะเป็นหนึ่งในไม่กี่คนที่เข้าใจว่าฝ่ายบริหารคิดแตกต่างจากวิศวกรรมมาก และฉันคิดว่าเราทุกคนเห็นความก้าวหน้าของ บริษัท ที่จะขับเคลื่อนด้วยวันที่และบริหารโครงการมากขึ้นเมื่อเทียบกับลูกค้าและคุณภาพที่มุ่งเน้น โดยสิ่งนี้ฉันหมายถึง บริษัท ทั่วไปไม่ใช่คนที่แข็งแกร่งจริงๆที่มีความกล้าที่จะพูดว่า "มันจะเสร็จเมื่อมันเสร็จ" (เช่น Apple Computer หรือ id Software - และใช่ฉันเข้าใจว่าบางครั้งผู้คนไม่ได้มีเสรีภาพ เพื่อใช้วิธีการนั้น)

แต่นี่คือสิ่งที่: บริษัท ที่ใช้แนวทางคุณภาพแรก ... คุณสังเกตเห็นอะไรบ้าง ถูกต้องพวกเขาดำเนินการโดยวิศวกรไม่ใช่พนักงานขายนักการตลาดผู้จัดการโครงการหรือนักบัญชี นึกถึง HP, Apple, id, Google, Microsoft และ IBM ทุกคนเริ่มต้นและประสบความสำเร็จโดยวิศวกรไม่ใช่พนักงานขายแม้ว่าพนักงานขายจะมีส่วนร่วมและฉันมั่นใจว่าหลายคนคงอภิปรายว่า Microsoft มีส่วนเกี่ยวข้องกับคุณภาพ :) และในบรรดาคนที่ตกต่ำก็ห่างจากความเป็นผู้นำที่ขับเคลื่อนด้วยวิศวกรรม มีข้อโต้แย้งมากมายในแถลงการณ์นั้นเนื่องจากมี บริษัท ด้านเทคนิคมากมายที่ล้มเหลวในที่สุดเนื่องจากไม่สามารถปรับตัวเข้ากับเวลาที่เปลี่ยนแปลงและจัดการการเติบโตของตนเอง ฉันไม่เห็นความเป็นผู้นำทางวิศวกรรมเป็นสาเหตุของความล้มเหลวเหล่านั้นสำหรับฉัน ' เป็นเรื่องของทักษะและความเฉียบแหลมทางธุรกิจที่ไม่ขึ้นกับใครบางคนที่เป็นนักพัฒนาหรือนักบัญชี อย่างไรก็ตามฉันคิดว่าโดยทั่วไปแล้วการพูดนั้นมีความทุ่มเทด้านวิศวกรรมต่อความแข็งแกร่งของความรับผิดชอบและวินัยที่เป็นประโยชน์ต่อ บริษัท ที่วิศวกรรมเป็นส่วนประกอบ

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

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


43

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

การปล่อยให้ไม่ได้รับค่าจ้างนั้นมาพร้อมกับค่าใช้จ่ายจำนวนมากซึ่งไม่สามารถมองเห็นหรือวัดได้ง่าย

แสดงรายการปัญหาต่าง ๆ ดังต่อไปนี้สำหรับการจัดการ:

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

7
+1 แม้ว่าฉันคิดว่ากระสุนนัดสุดท้ายควรเป็น "สมาชิกในทีมที่ดี / ดีที่สุดกำลังจะจากไป"
Ken Henderson

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

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

2
@Renesis "ไม่มีเหตุผลว่าทำไมทางลัดไม่สามารถให้เสียงในทางเทคนิค" - นั่นไม่จริง
quant_dev

3
และบางครั้งก็ไม่ใช่หนี้ด้านเทคนิคเลยมันเป็นแค่เรื่องยุ่ง ๆ : sites.google.com/site/unclebobconsultingllc/ …
TrueWill

30

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

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

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

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

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


20

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

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

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


12

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

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

แน่นอนคุณควรจะเปิดเกี่ยวกับเรื่องนี้เราไม่ได้พูดถึง "แอบใน" โครงการใหม่ที่นี่

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

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

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


5
+1 แต่นักพัฒนา 9-5 คนนั้นคุณต้องการประตูหมุนสำหรับพวกเขาโดยเฉพาะกับตัวเร่งความเร็วบางรูปแบบ
Orbling

3
@Orbling: +1 หากพวกเขาไม่สนใจพวกเขาควรทำงานที่อื่น มันมี devs ที่ยอดเยี่ยมมาหาคุณด้วย "ฉันเพิ่งมีความคิดนี้ ... "
quick_now

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

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

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

12

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

หรือพวกเขาลงไปอย่างรวดเร็ว

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

ในฐานะวิศวกรฉันชอบที่จะสร้างรหัสเก่าซึ่งไม่เหมาะกับวัตถุประสงค์อีกต่อไปทุกครั้งที่บางสิ่งบางอย่างล้าสมัยหรือเลิกใช้แล้ว แต่ดัง MD ของฉันในทุก บริษัท ที่ฉันเคยทำงานให้ฉัน: "ใครจะจ่ายเงิน"


12

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

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


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

7

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

วิเคราะห์เวลาที่นักพัฒนาถูกบังคับให้ใช้ความช่วยเหลือในการสนับสนุนกับปัญหาการผลิตจากนั้นทำกรณีที่การแก้ไขรหัสเก่า crufty จะ A. ลดจำนวนปัญหาการสนับสนุน B. ทำให้ง่ายขึ้นสำหรับฝ่ายสนับสนุนในการแก้ไขปัญหาโดยไม่ต้องเลื่อนการพัฒนา C. ลดเวลาที่การพัฒนาใช้ไปกับปัญหาการผลิตเมื่อเกิดขึ้น เก็บไว้ในรูปของเงินดอลลาร์ที่บันทึกไว้โดยไม่มีนักพัฒนาผูกติดอยู่กับการทำงานสนับสนุน นอกจากนี้ชี้ให้เห็นว่าทุก ๆ ชั่วโมงที่นักพัฒนาใช้ในการสนับสนุนเป็น "double whammy" เพราะคุณไม่เพียง แต่จ่ายเงินให้นักพัฒนาเพื่อสนับสนุน แต่คุณกำลังลดค่าใช้จ่ายโอกาสของสิ่งที่นักพัฒนานั้นสามารถทำได้ (เพิ่มคุณสมบัติใหม่ ฯลฯ ) .)

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


6

หลังจากคำอธิบายเกี่ยวกับหนี้ทางเทคนิคนี้ฝ่ายบริหารของคุณควรได้รับความมั่นใจในการชำระหนี้:

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

ห้องครัวคือรหัสของคุณอาหารเป็นผลิตภัณฑ์ของคุณและการรับประทานคือการขายผลิตภัณฑ์ของคุณ

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


4

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

เราใช้ถ้อยคำนี้ใหม่เพื่อวางตำแหน่งตัวคุณในฐานะลูกค้า มีบทบาทเก่าดี

สมมติว่าคุณซื้อตู้เย็น และคุณสามารถซื้อตู้เย็นราคา $ 1,000 ที่ใช้งานได้ดีจาก Acme Corp. หรือตู้เย็นราคา $ 2,000 จาก Acme Deluxe Fridges ที่ดูภายนอกและมีคุณสมบัติทางเทคนิคเหมือนกัน แต่มีค่าบำรุงรักษาต่ำเนื่องจากสถาปัตยกรรมภายในที่สะอาดกว่า

ในฐานะลูกค้าคุณจะซื้ออะไร

และวิศวกรของ Acme Deluxe คิดว่าอะไรคือคำตอบที่ดีกว่า


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

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

3

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

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


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

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

แต่ฝ่ายบริหาร (ในกรณีส่วนใหญ่อย่างถูกต้อง!) เห็นด้วยวิธีนี้ ฉันมี magimix ปี 1980 ที่ยังใช้งานได้และบอกให้คุณแทนที่มันเพราะความเก่าและสีไม่เป็นที่นิยม!
James Anderson

2

คุณควรหยุดบ่นเกี่ยวกับมัน

นี่คือเหตุผล:

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

ดังนั้นวิธีที่ดีที่สุดคือ:

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

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

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

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

1

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

นี่เป็นโครงการที่ยากที่สุดที่จะทำให้สำเร็จ ปัญหาบางอย่างที่คุณจะพบคือ

  1. กฎทางธุรกิจจะสูญหายในเวลา
  2. เอกสารและการนำไปใช้งานไม่สอดคล้องกันโดยสิ้นเชิง
  3. สิ่งที่คุณเห็นว่าเป็นข้อบกพร่องที่ผู้ใช้เห็นว่าเป็นคุณสมบัติ
  4. "ฟีเจอร์" จำนวนมากในทางกลับกันจะถูกมองว่าเป็นข้อบกพร่องของผู้ใช้
  5. คุณจะไม่ได้รับการสั่งซื้อจากผู้ใช้ - พวกเขาจะคำนึงถึง "การค้นหาข้อเท็จจริง" ของคุณเป็น "ผู้ถามคำถามโง่ ๆ " พวกเขาจะพิจารณาความพยายามในการทดสอบว่าเป็นการเสียเวลาพวกเขาจะยืนยันในการเพิ่มคุณสมบัติใหม่ มีกำหนดการล่าช้า
  6. โอกาสที่ซอร์สโค้ดไม่ตรงกับ 100% กับการทำงานที่รันได้
  7. ในขณะที่แผนกของคุณกำลังยุ่งเกี่ยวกับการพัฒนา refactoring ธุรกิจจริง ๆ ไม่ต้องการทำ
  8. โอกาสที่แฟคตอริ่งของคุณจะเกี่ยวข้องกับ "อินเตอร์เฟสที่ปรับปรุงดีขึ้น" ดังนั้นการลากโครงการอื่น ๆ เข้าสู่หล่มของการส่งมอบล่าช้าและการทดสอบที่ล้มเหลว
  9. หลังจากโครงการกระป๋อง (มากกว่า 50% ของความพยายามเหล่านี้ล้มเหลวโดยสิ้นเชิง) คุณจะสูญเสียความน่าเชื่อถือทั้งหมด - คุณจะต้องย้ายไปที่ บริษัท อื่นในเมืองอื่นเพื่อหาคนที่พร้อมจะรับฟังคุณ
  10. หากโครงการ "สำเร็จ" ทุกคนจะจำได้ว่าฝันร้ายมันคืออะไร - คุณจะ .......

ฉันขอแนะนำให้คุณหลีกเลี่ยงโครงการที่เขียนซ้ำ / การปรับโครงสร้างซ้ำเช่นกาฬโรคพวกเขาอาจเป็นประสบการณ์ที่เลวร้ายที่สุดในอาชีพการงานใด ๆ

มีความฉลาดในวลี "ถ้ามันไม่พังไม่ได้แก้ไข"


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

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

1

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

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

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

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

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

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

โชคดี!


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

1
@gnat: "คำตอบ" ส่วนใหญ่ตอบคำถามนั้นโดยตรงอย่างไร ดูตัวอย่างเช่นคำตอบของ James Anderson, tp1 หรือคำตอบใด ๆ ที่ด้านบนด้วยคะแนนโหวตมากที่สุด แต่เพื่อตอบคำถามของคุณฉันได้ให้ทางเลือกที่คล้ายคลึงกันที่ OP สามารถใช้ได้ ดูเหมือนว่าคุณจะไม่เห็นด้วยกับความคิดเห็นของฉันในเรื่องนี้ ไม่เป็นไร แต่ไม่มีเหตุผลที่จะลงคะแนน
Matt Cashatt

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

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

1

คุณต้องให้เหตุผลทางการเงินแก่ผู้บริหารเพื่อจัดการกับหนี้ทางเทคนิคและกรอบการจัดการลดหนี้ทางเทคนิคนั้น

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

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

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

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

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

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

นี่คือวิดีโอของชั่วโมงแรกของเซสชั่นแผนงาน Red Hat Linux ที่ผ่านมา


1

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

ปัจจัยสำคัญในการบรรลุข้อตกลง:

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

รายงานแสดงรายละเอียดปัญหาพร้อมประมาณการค่าใช้จ่ายต่อเนื่องและเสนอ 3 ตัวเลือก:

  1. ตรึงที่เราอยู่ด้วยอาจจะไม่ได้แก้ไขข้อผิดพลาดในอนาคตอันใกล้
  2. เพิ่มประสิทธิภาพรหัสสำหรับพื้นที่เท่านั้นโดยไม่คำนึงถึงการบำรุงรักษาชี้ให้เห็นว่าใครก็ตามที่พยายามรักษารหัสที่ดีที่สุดจะต้องฉลาดกว่าใครก็ตามที่เพิ่มประสิทธิภาพ
  3. การนำไปใช้ใหม่ด้วยความสามารถในการทดสอบและการบำรุงรักษาในระดับสูงในมาตรฐานอุตสาหกรรม, การสอนภาษา, (ANSI C) อย่างกว้างขวางเกี่ยวกับฮาร์ดแวร์ COTS ใหม่, ราคาถูก, (PC-104) โดยมีผู้ขายหลายรายพร้อมอยู่ในบ้าน การ์ดอินเตอร์เฟสที่ออกแบบมาเพื่อให้สามารถทำงานกับฮาร์ดแวร์ที่เหลืออยู่ได้ เพิ่มชุด จำกัด ของคุณสมบัติใหม่ที่เป็นส่วนหนึ่งของการพัฒนาเช่นการจัดเก็บไม่ระเหยเป็นเวลาจ้องจับผิดเพื่อให้การรีสตาร์ทอัตโนมัติในสภาพความผิดบางหน่วยได้รับการกระแทกหลายครั้งต่อวันและต้องมีการเรียกใช้บริการ£ 40 ออกเพื่อรีเซ็ต , การวินิจฉัยที่ดีขึ้นในกระบวนการ

หลังจากได้รับตัวเลือกที่ 3 สัญญา 3 เดือนของฉันกลายเป็น 3 ปีของการทำงานหนักมากทั้งการพัฒนาซอฟต์แวร์และฮาร์ดแวร์ใหม่ แต่มีผลดีมาก

สำหรับกรณีที่มีหนี้ทางเทคนิคน้อยมากฉันมักจะยอมรับสิ่งที่ฉันเรียกว่าการฟื้นฟูกองโจร:

เมื่อมีปัญหากับโมดูลเฉพาะ:

  1. เขียนชุดการทดสอบที่แสดงให้เห็นถึงปัญหาที่อาจเกิดความล้มเหลวโดยไม่ต้องทำการปรับโครงสร้างใหม่
  2. Refactor ซึ่งเป็นส่วนหนึ่งของการพัฒนาชี้ให้เห็นว่าการทดสอบยังคงล้มเหลว
โดยการใช้ไซต์ของเรา หมายความว่าคุณได้อ่านและทำความเข้าใจนโยบายคุกกี้และนโยบายความเป็นส่วนตัวของเราแล้ว
Licensed under cc by-sa 3.0 with attribution required.