ต่อสู้กับหนี้ทางเทคนิคในฐานะ“ ผู้พัฒนาที่ต่ำที่สุด” หรือไม่?

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

function add(a,b){return a + b;}

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

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

คุณรับมือกับสถานการณ์เหล่านี้อย่างไร? คุณต่อสู้กับหนี้ทางเทคนิคในฐานะ "ผู้พัฒนาที่ต่ำที่สุด" ได้อย่างไร?

ชี้แจง:

• คุณคือ "implementer" ซึ่งต่ำที่สุดในลำดับชั้น

• คุณเห็นปัญหา แต่ไม่ได้พูดกับเรื่องนี้

• ฉันไม่ได้ระบุปริมาณหนี้ทางเทคนิคหรือมองหาเครื่องมือ

• เกี่ยวกับ"ซ้ำ" ที่สาม

  • การ Refactoring & Rewrite - คุณถูกล็อคในงานของคุณ คุณไม่ได้รับค่าตอบแทนในการทำสิ่งพิเศษ
  • ภาพรวมสถาปัตยกรรม - คุณรู้ระบบโดยรวม แต่ไม่มีแนวคิดเกี่ยวกับสถาปัตยกรรม
  • Code Freeze - ไม่ใช่การโทรของคุณ คุณไม่ได้จัดการ
  • การทำให้เป็นโมดูล - ไม่มีแนวคิดเกี่ยวกับสถาปัตยกรรม โมดูลเปลี่ยนแปลงตามความต้องการที่เปลี่ยนแปลง
  • การทดสอบอัตโนมัติ - ไม่มีอยู่

ทุกครั้งที่คุณสังเกตเห็นสิ่งนั้นให้ป้อนตั๋วใหม่เข้าสู่ระบบติดตามปัญหาของคุณ

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

ใช้เครื่องมือที่เหมาะสมสำหรับงาน ฉันทำเสมอและขอแนะนำให้คุณทำเช่นเดียวกัน

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

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

สรุป:ลดความซับซ้อนของการออกแบบที่เกี่ยวข้องParticularPieceOfCode

คำอธิบาย:
ในระหว่างการใช้งานต่อ TICKET-12345 รหัสที่เกี่ยวข้องกับการใช้งานที่เพิ่มParticularPieceOfCodeขึ้นของความยุ่งยากเล็กน้อยและค่อนข้างยากที่จะอ่านทำความเข้าใจและบำรุงรักษา (ดูตัวอย่างโค้ดขนาดด้านล่าง)

หาวิธีทำให้มันง่ายขึ้น

ตัวอย่างของรหัสที่ต้องการการออกแบบสามารถพบได้ในClassName#methodName:

<a piece of code like one behind the right door here:>

FWIW คำแนะนำของฉันมีผลบังคับใช้อย่างเป็นอิสระจากระดับ "คุณ"

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

ลองคิดดูสิไม่มีเลเวลไม่ว่าคุณจะมีสิทธิอำนาจมากแค่ไหนก็ไม่มีทางที่ดีกว่านี้อีกแล้ว

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

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

ใช้เครื่องมือที่เหมาะสมสำหรับงาน สำหรับงานที่คุณอธิบายปัญหาการติดตามเป็นเครื่องมือที่เหมาะสม

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

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

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

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

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

คุณเป็นผู้พัฒนาที่ต่ำที่สุดในห่วงโซ่

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

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

ใช้! อย่ารอจนกระทั่งมีคนทำให้คุณต้องรับผิดชอบ

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

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

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

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

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

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

ตัวอย่างเช่นสมมติว่าคุณนำรถของคุณไปที่ช่างซ่อมเพื่อเปลี่ยนหลอดไฟ ช่างสังเกตสิ่งที่สี่:

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

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

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

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

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

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

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

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

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