/ มีวิธีการที่ถูกต้องในการบอกผู้บริหารว่ารหัสของเราแย่แค่ไหน?

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

ไฮไลท์บางส่วน:

• เรายังคงใช้เฟรม (ลองนำบางสิ่งออกจากการสืบค้นซึ่งเป็นไปไม่ได้เกือบ)
• VBScript
• แหล่งที่มาที่ปลอดภัย
• เรา 'ใช้'. NET - โดยที่ฉันหมายถึงเรามี. wrappers สุทธิที่เรียก COM DLLs ทำให้แทบเป็นไปไม่ได้ที่จะตรวจแก้จุดบกพร่องได้อย่างง่ายดาย
• ทุกอย่างนั้นเป็นฟังก์ชั่นใหญ่อย่างหนึ่ง
• รหัสไม่สามารถบำรุงรักษาได้ แต่ละหน้ามีหลายไฟล์ที่สร้างขึ้นทุกครั้งที่มีการสร้างหน้าใหม่ หน้าหลักโดยทั่วไปจะไม่ Response.Write () หลายครั้งเพื่อแสดง HTML (runat = "server"? no way) หลังจากนั้นอาจมีตรรกะจำนวนมากในฝั่งไคลเอ็นต์ (VBScript) และในที่สุดหน้าก็จะส่งไปยังตัวเอง (มักจะเก็บสิ่งต่าง ๆ ในเขตข้อมูลที่ซ่อนอยู่) ซึ่งมันจะโพสต์ไปยังหน้าการประมวลผลซึ่งสามารถทำสิ่งต่าง ๆ เช่นบันทึก data ไปยังฐานข้อมูล
• ข้อมูลจำเพาะที่เราได้รับนั้นน่าหัวเราะ บ่อยครั้งที่พวกเขาเรียกหาสิ่งต่าง ๆ เช่น "เติมข้อมูลฟิลด์ X อัตโนมัติด้วยฟิลด์ Y หรือฟิลด์ Z" โดยไม่มีข้อบ่งชี้ว่าจะเลือกฟิลด์ Y หรือฟิลด์ Z เมื่อใด

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

ฉันจะทำอย่างไร ฉันจะนำปัญหาเหล่านี้มาได้อย่างไร 75% ของทีมเห็นด้วยกับฉันและนำปัญหาเหล่านี้มาใช้ในอดีต แต่ก็ไม่มีอะไรเปลี่ยนแปลง

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

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

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

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

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

เขียนใหม่เสร็จสมบูรณ์หรือไม่ เกือบจะเป็นความคิดที่ดีเสมอ

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

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

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

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

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

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

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

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

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

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

วิธีที่เลวร้ายที่สุดที่ฉันเคยเห็นคือพยายามกระโดดครั้งใหญ่โดยตรงจากระบบเดิมเป็นรุ่นล่าสุดและยิ่งใหญ่ที่สุดเช่นกระโดดจากการทำงาน แต่ระบบ VB6 / Classic ASP / COM + clunky ไปเป็นระบบ MVC / Entity Framework

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

(ถอดความบางส่วนจากความคิดเห็นของ Azkar กับคำถาม)

เริ่มอ่านJoel บนซอฟต์แวร์ (Joel Spolsky / ผู้ก่อตั้ง Stack Exchange) ...

สิ่งแรกที่ผมจะทำคือการดำเนินการทดสอบโจเอล

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

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

หวังว่าจะช่วย! ยินดีต้อนรับสู่การเขียนโปรแกรม (รหัส yesterdays มักจะ sucks) ;-)

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

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

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

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

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

ตัวอย่างอาจใช้สำหรับ "รหัสไม่สามารถบำรุงรักษาได้":

รหัสปัจจุบันไม่สามารถบำรุงรักษาได้เนื่องจากX , YและZ (รายการสาเหตุที่ทำให้ไม่สามารถรักษาได้) สิ่งนี้ทำให้การร้องขอการเปลี่ยนแปลงและคุณสมบัติใหม่ทำได้ยากมากเนื่องจากX , Y , Z (สาเหตุที่ทำให้การเปลี่ยนแปลงนั้นยาก) เนื่องจากการเปลี่ยนแปลงนั้นยากทีมพัฒนาจึงไม่สามารถตอบสนองต่อการแก้ไขข้อบกพร่องและการปรับปรุงได้อย่างง่ายดาย

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

โชคดี. คุณจะต้องการมัน

"ฉันเริ่มต้นใหม่จากวิทยาลัย" - ควรตอบคำถามของคุณ

ฝ่ายจัดการอาจทราบว่ารหัสนั้นเหมาะสมที่สุด รหัสส่วนใหญ่คือถ้าคุณจ้าง Ray Gosling, Guido Van Rossum หรือคนอื่นที่ดีและมีราคาแพงในการเขียน

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

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

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

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

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

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

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

การจัดการไม่สนใจรหัส พวกเขาสนใจเกี่ยวกับการมีผลิตภัณฑ์ที่จะขาย

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

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

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

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

อย่าทำมัน

การเขียนโครงการขนาดใหญ่ใหม่จากศูนย์เป็นความผิดพลาดครั้งใหญ่

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

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

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

มีผู้จัดการสองประเภท: คนที่แกล้งทำเป็นเข้าใจสิ่งที่คุณทำและคนที่ไม่ทำ คนที่แกล้งเข้าใจซอฟต์แวร์จะเป็นศัตรูกับคุณ คนที่คุณไม่รำคาญเท่านั้น

ไม่ว่าในกรณีใดผู้จัดการก็เป็นคนโกหกทั้งหมด

ประเด็นของฉันคือถ้าคุณบอกว่าซอฟต์แวร์ล้าสมัยพวกเขาจะใช้เป็นข้ออ้าง พวกเขาไม่สนใจ