โทษความเจ็บป่วยของวันนี้เกี่ยวกับหนี้ทางเทคนิคของเมื่อวานนี้


38

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

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

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

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

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

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

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


17
เป็นเรื่องน่าขันที่ในคำถามเกี่ยวกับการไม่เล่นเกมโทษคุณใช้จ่ายเต็ม 3 ย่อหน้าซึ่งประกอบด้วยประมาณ 50% ของคำถามที่คุณคุยโวเกี่ยวกับทีมก่อนหน้านี้ และแท็กคำถาม [รหัสไม่ดี] และ [โปรแกรมที่ไม่ดี]
Aaronaught

8
@Aaraught เอาล่ะฉันจะกัดฉันติดป้ายbad-codeเพราะรหัสนั้นทำให้เกิดข้อบกพร่องและปัญหา ฉันติดป้ายกำกับbad-programmerเพราะฉันกลัวว่าฉันจะกลายเป็นหนึ่งเดียวโดยโทษทีมก่อนหน้านี้เป็นข้อแก้ตัวที่เหนื่อยล้าและซ้ำซากที่เราเคยได้ยินมาก่อน เท่าที่สามย่อหน้าแรกได้รับการพิจารณาบางทีฉันไม่จำเป็นต้องอธิบายอย่างนั้น แต่ฉันต้องการวาดภาพที่ถูกต้องเกี่ยวกับสถานการณ์ปัจจุบันของฉันและให้ประวัติของสิ่งที่ฉันรวบรวมมา
maple_shaft

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

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

เรื่องราวในชีวิตของฉัน
Iulian Onofrei

คำตอบ:


46

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

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

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


4
+1 สำหรับคำอธิบายที่ดีมากโดยไม่มีการตำหนิว่าโครงการสามารถเลือก (ถูกต้อง!) เพื่อเข้าสู่หนี้ทางเทคนิคได้อย่างไร
Joris Timmermans

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

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

2
+1 ถึง "นี่เป็นจริงแม้ว่าคุณจะเขียนใบสมัครของคุณอย่างถูกต้อง"
Mauricio Scheffer

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

23

IMO ส่วนใหญ่คุณจะทำสิ่งนี้ในทางที่ถูกต้อง: คุณไม่ได้แนะนำการเขียนซ้ำเพราะ "รหัสเก่าแย่" แต่แก้ไขสิ่งหนึ่งครั้ง

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

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


3
+1: โทษผู้บริหารเก่าที่ล้มเหลวในการส่งมอบผลิตภัณฑ์ที่มีคุณภาพจากนั้น (หวังว่า) ผู้บริหารใหม่จะได้รับข้อความ (หรือกำจัดคุณทั้งสองกรณีจะชนะเท่าที่คุณกังวล)
gbjbaanb

15
@gbjbaanb - อย่าโทษใครเลย! ออกไปในทางของคุณเพื่อไม่ให้โทษใคร เพียงแค่สร้างสถานการณ์ปัจจุบันและสถานการณ์ที่ต้องการแล้วสร้างข้อโต้แย้งที่สมเหตุสมผลว่าคุณต้องการไปถึงอย่างไรและทำไม
Joris Timmermans

เอ๊ะตรวจสอบให้แน่ใจว่ามีการจัดการใหม่ เจ้านายเดียวกันอาจยังอยู่ที่นั่น และแม้ว่าเขาจะย้ายเขาอยู่ที่ไหนสักแห่งที่นั่น ตรวจสอบให้แน่ใจก่อนที่จะออกไปขว้างคนที่อยู่ใต้รถบัส
ฟิลิป

ฉันหวังว่ามันจะง่ายพอ ๆ กับที่ไม่โทษใครเลย ฝ่ายบริหารยืนยันว่ามีใครบางคน / บางอย่างชี้ไปที่ ถ้าฉันไม่ชี้ไปที่บุคคลหรือกลุ่มบุคคลที่ฉันจะชี้ไป
maple_shaft

4
@maple_shaft - ขอโต้แย้งในคำตอบของฉันต่อการจัดการและถ้าพวกเขายังคงยืนยันใน "โทษ" โพสต์ประวัติย่อของคุณบนเว็บไซต์มากเท่าที่คุณจะหาเพราะสิ่งต่าง ๆ กำลังจะแย่มากสำหรับคุณเมื่อพวกเขา ตัดสินใจที่จะเริ่มโทษคุณเพราะไม่มีใครชี้ไปที่
Joris Timmermans

7

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

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

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

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