จะพิสูจน์ได้อย่างไรว่าแอพพลิเคชั่นนั้นสร้างมาจาก codebase ที่ไม่ดี?

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

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

'แต่ตอนนี้ทำงานแล้ว' คือการตอบสนองการจัดการมาตรฐานต่อความผิดหวังที่ถูกกฎหมายของวิศวกรซอฟต์แวร์ สิ่งแรกที่ฉันจะทำคือรวบรวมเอกสาร (ถ้ามี) และใช้สิ่งนั้นเพื่อแสดงความขัดแย้งระหว่างรหัสและเอกสาร

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

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

แน่นอนมันทั้งหมดขึ้นอยู่กับสภาพแวดล้อมของคุณขนาด บริษัท ฯลฯ

ฉันมักจะแนะนำให้ดูที่The Pragmatic Programmerหากคุณยังไม่ได้อ่าน ไม่เพียง แต่จะต้องมีการอ่านสำหรับซอฟต์แวร์มืออาชีพทุกคน แต่มีคำแนะนำที่ดีสำหรับการจัดการผู้ร่วมงานผู้ใช้ ฯลฯ ที่ไม่ได้มองว่าวิศวกรรมซอฟต์แวร์เป็นงานฝีมือ

จากมุมมองของฝ่ายบริหารไม่มีอะไรผิดปกติกับระบบและคุณแค่บ่นเพราะ [คุณแค่ต้องการเขียนมันใหม่ / คุณไม่เข้าใจว่าวิศวกรคนก่อนหน้าทำอะไร / คุณต้องการให้งานของคุณง่าย] ชายฟางบางส่วน แต่เมื่อใครบางคนที่อยู่ด้านบนเห็นว่าสิ่งต่าง ๆ กำลังทำงานได้ดีในตอนนี้พวกเขาจะไม่เห็นวิกฤตที่คุณทำ (ฉันแน่ใจว่ามีการเปลี่ยนแปลงสภาพภูมิอากาศในบางที่ ... .

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

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

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

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

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

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

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

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

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

ในกรณีของคุณฉันคิดว่ามี 2 สิ่งที่ต้องพิสูจน์

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

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

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

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

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

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

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

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

สิ่งที่ทำให้โค้ดเบสไม่ดี:

• ช่องโหว่ด้านความปลอดภัย

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

• ใช้งานไม่ได้

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

• ใช้งานไม่ได้จริง

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

อะไรคือ codebase ที่ไม่ดี (แค่ไม่ดี):

• เขียนบนเทคโนโลยีที่ล้าสมัยไม่ได้รับการสนับสนุน (VB6, COBOL, .net1.1 เป็นต้น)

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

• รหัสที่ไม่มีเอกสาร / จัดรูปแบบไม่ดี

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

คุณได้ตอบคำถามของคุณเองในทางใด

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

จากนั้นจึงมีข้อเสนอง่ายๆในการทำความสะอาดเครื่องชั่งนี้จะเสียค่าใช้จ่าย X ชั่วโมง

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

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

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

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

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

มีเหตุผลว่าทำไมซอฟแวร์ที่เป็นผู้ใหญ่ทั้งหมดดูเหมือนเป็นระเบียบ

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