จะรักษาผลิตภัณฑ์ซอฟต์แวร์ที่มีขนาดใหญ่และซับซ้อนได้อย่างไรในช่วงหลายปีที่ผ่านมา?

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

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

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

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

ทางออกที่แท้จริงเพียงอย่างเดียวในการหลีกเลี่ยงรหัสเน่าคือรหัสดี

รหัสวิธีดีเป็นคำถามอื่น มันยากพอแม้ว่าคุณเป็นโปรแกรมเมอร์ที่ยอดเยี่ยมที่ทำงานคนเดียว ในทีมที่ต่างกันมันก็ยิ่งยากขึ้นไปอีก ในโครงการเอาต์ซอร์ซ (sub) ... แค่อธิษฐาน

แนวทางปฏิบัติที่ดีตามปกติอาจช่วย:

1. ง่าย ๆ เข้าไว้.
2. ง่าย ๆ เข้าไว้. สิ่งนี้ใช้ได้กับสถาปัตยกรรมโดยเฉพาะ "ภาพใหญ่" หากนักพัฒนาจะมีช่วงเวลาที่ยากที่จะได้รับภาพใหญ่ที่พวกเขากำลังจะให้รหัสกับมัน เพื่อให้สถาปัตยกรรมง่ายขึ้นเพื่อให้นักพัฒนาทั้งหมดได้รับมัน หากสถาปัตยกรรมต้องมีความเรียบง่ายน้อยกว่านั้นผู้พัฒนาจะต้องได้รับการฝึกฝนให้เข้าใจสถาปัตยกรรมนั้น หากพวกเขาไม่ได้ทำให้เป็นภายในมันก็ไม่ควรเขียนมัน
3. มีจุดมุ่งหมายเพื่อการมีเพศสัมพันธ์ในระดับต่ำและการทำงานร่วมกันสูง ตรวจสอบให้แน่ใจว่าทุกคนในทีมเข้าใจแนวคิดนี้ ในโครงการที่ประกอบไปด้วยชิ้นส่วนที่หลวมและเหนียวหากชิ้นส่วนบางชิ้นกลายเป็นสิ่งที่ไม่สามารถแก้ไขได้คุณสามารถถอดและเขียนส่วนนั้นใหม่ได้ มันยากหรือใกล้เคียงไม่ได้ถ้าคัปปลิ้งคับ
4. คงเส้นคงวา. มาตรฐานใดบ้างที่จะต้องปฏิบัติตามเล็กน้อย แต่โปรดทำตามมาตรฐานบางอย่าง ในทีมทุกคนควรปฏิบัติตามมาตรฐานเดียวกันแน่นอน ในทางกลับกันก็ง่ายที่จะยึดติดอยู่กับมาตรฐานเกินไปและลืมส่วนที่เหลือ: โปรดเข้าใจว่าในขณะที่มาตรฐานมีประโยชน์พวกเขาเป็นเพียงส่วนเล็ก ๆ ของการสร้างรหัสที่ดี อย่าทำมันเป็นจำนวนมาก
5. การตรวจสอบโค้ดอาจเป็นประโยชน์ในการทำให้ทีมทำงานอย่างต่อเนื่อง
6. ตรวจสอบให้แน่ใจว่าเครื่องมือทั้งหมด - IDE, คอมไพเลอร์, การควบคุมเวอร์ชัน, การสร้างระบบ, เครื่องกำเนิดเอกสาร, ห้องสมุด, คอมพิวเตอร์ , เก้าอี้ , สภาพแวดล้อมโดยรวมฯลฯ - ได้รับการดูแลอย่างดีเพื่อให้นักพัฒนาไม่ต้องเสียเวลากับปัญหารอง เนื่องจากการต่อสู้กับเวอร์ชันของไฟล์โครงการที่ขัดแย้งกันการอัปเดต Windows เสียงรบกวนและสิ่งที่น่ารำคาญ แต่สิ่งที่น่ารำคาญ ต้องเสียเวลาจำนวนมากซ้ำ ๆ กับสิ่งที่ไม่น่าสนใจเช่นนี้ช่วยลดขวัญกำลังใจซึ่งอย่างน้อยก็จะไม่ปรับปรุงคุณภาพของรหัส ในทีมขนาดใหญ่อาจมีผู้ชายอย่างน้อยหนึ่งคนที่มีหน้าที่หลักคือดูแลเครื่องมือของนักพัฒนาซอฟต์แวร์
7. เมื่อทำการตัดสินใจทางเทคโนโลยีให้คิดว่าจะต้องทำอย่างไรเพื่อเปลี่ยนเทคโนโลยี การตัดสินใจใดกลับไม่ได้และไม่เป็นการตัดสินใจ ประเมินการตัดสินใจที่ไม่สามารถย้อนกลับได้อย่างระมัดระวังเป็นพิเศษ ตัวอย่างเช่นหากคุณตัดสินใจที่จะเขียนโครงการในJavaนั่นเป็นการตัดสินใจที่ไม่สามารถย้อนกลับได้ หากคุณตัดสินใจที่จะใช้รูปแบบไบนารี่ที่ต้มเองสำหรับไฟล์ข้อมูลนั่นเป็นการตัดสินใจที่ไม่สามารถย้อนกลับมาได้อีกด้วย แต่สามารถปรับสีของ GUI ได้อย่างง่ายดายโดยสามารถเพิ่มฟีเจอร์ที่เหลือไว้ในภายหลังได้ดังนั้นโปรดลดความเครียดเกี่ยวกับปัญหาดังกล่าว

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

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

ในฐานะที่เป็นผลข้างเคียงที่ดีการทดสอบหน่วยก็หวังว่าจะลดจำนวนข้อผิดพลาดของคุณ

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

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

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

มีหลายสิ่งที่เราสามารถทำได้:

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

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

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

การเขียนโค้ดที่ดีที่สุดทำให้สถาปัตยกรรมดูได้ง่ายขึ้นจากโค้ด - ใช้เวลาในการ refactor, comment code, พัฒนาการทดสอบหน่วย ฯลฯ สิ่งต่าง ๆ เช่นการตั้งชื่อแบบแผนการประชุมและการเขียนโค้ดแบบสะอาดสามารถช่วยในการสื่อสารสถาปัตยกรรม ใช้เวลาในการพัฒนาและปฏิบัติตามมาตรฐานของคุณเอง

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

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

วิธีที่ฉันไปเกี่ยวกับปัญหานี้คือการตัดที่ราก:

คำอธิบายของฉันจะใช้เงื่อนไขจาก Microsoft / .NETแต่จะใช้ได้กับแพลตฟอร์ม / กล่องเครื่องมือใด ๆ :

1. ใช้มาตรฐานสำหรับการตั้งชื่อการเข้ารหัสเช็คโฟลว์การไหลของกระบวนการ
2. อย่ากลัวที่จะกล่าวคำอำลากับสมาชิกในทีมที่ไม่ปฏิบัติตามมาตรฐาน นักพัฒนาบางคนไม่สามารถทำงานได้ภายในมาตรฐานที่กำหนดและจะกลายเป็นศัตรูคอลัมน์ที่ 5 ในสนามรบเพื่อรักษาความสะอาดของรหัส
3. อย่ากลัวที่จะจัดสรรสมาชิกในทีมที่มีทักษะต่ำกว่าให้ทำการทดสอบเป็นเวลานาน
4. ใช้เครื่องมือทุกชิ้นในคลังแสงของคุณเพื่อหลีกเลี่ยงการตรวจสอบในรหัสเน่าเปื่อย: นี้เกี่ยวข้องกับเครื่องมือเฉพาะเช่นเดียวกับการทดสอบหน่วยที่เขียนไว้ล่วงหน้าที่ทดสอบไฟล์สร้างไฟล์โครงการโครงสร้างไดเรกทอรี ฯลฯ
5. ในทีมงานที่มีสมาชิกประมาณ 5-8 คนให้คนที่ดีที่สุดของคุณทำการปรับโครงสร้างใหม่เกือบตลอดเวลา - ทำความสะอาดสิ่งที่คนอื่นทิ้งไว้ แม้ว่าคุณจะพบผู้เชี่ยวชาญที่ดีที่สุดในสนามคุณจะยังคงมีระเบียบ - มันหลีกเลี่ยงไม่ได้ แต่สามารถถูก จำกัด โดยการปรับโครงสร้างอย่างต่อเนื่อง
6. ทำการเขียนการทดสอบหน่วยและบำรุงรักษา - ไม่ขึ้นอยู่กับการทดสอบหน่วยเพื่อให้โครงการสะอาดอยู่เสมอ
7. พูดคุยทุกอย่าง อย่ากลัวที่จะใช้เวลาหลายชั่วโมงเพื่อพูดคุยเรื่องต่าง ๆ ในทีม สิ่งนี้จะเผยแพร่ข้อมูลและจะลบสาเหตุของรหัสที่ไม่ดีอย่างใดอย่างหนึ่ง: ความสับสนเกี่ยวกับเทคโนโลยีเป้าหมายมาตรฐานและอื่น ๆ
8. จะมากระวังกับที่ปรึกษาการเขียนรหัส: รหัสของพวกเขาจะเกือบโดยนิยามเป็นสิ่งที่ห่วยจริง
9. ทำรีวิวโดยเฉพาะอย่างยิ่งเป็นขั้นตอนกระบวนการก่อนเช็คอิน อย่ากลัวที่จะย้อนกลับ
10. อย่าใช้หลักการเปิด / ปิดยกเว้นในขั้นตอนสุดท้ายก่อนปล่อย: มันจะนำไปสู่การเน่ารหัสที่จะได้กลิ่น
11. เมื่อใดก็ตามที่มีปัญหาเกิดขึ้นให้ใช้เวลาในการทำความเข้าใจอย่างเต็มที่ก่อนที่จะดำเนินการแก้ปัญหา - เน่ารหัสส่วนใหญ่มาจากการดำเนินการแก้ปัญหาที่ไม่เข้าใจ
12. ใช้เทคโนโลยีที่เหมาะสม สิ่งเหล่านี้มักจะมาเป็นชุดและสดใหม่: จะเป็นการดีกว่าที่จะพึ่งพาเฟรมเวิร์กเวอร์ชันเบต้าที่คุณมั่นใจได้ว่าจะได้รับการสนับสนุนในอนาคตมากกว่าจะขึ้นอยู่กับความเสถียรอย่างมาก แต่เฟรมเวิร์กล้าสมัย
13. จ้างคนที่ดีที่สุด
14. เลิกจ้างส่วนที่เหลือ - คุณไม่ได้เปิดร้านกาแฟ
15. หากผู้บริหารไม่ใช่สถาปนิกที่ดีที่สุดและพวกเขาเข้าไปยุ่งเกี่ยวกับกระบวนการตัดสินใจ - หางานอื่น

ทำความสะอาดรหัสที่เน่าเสียโดยการปรับโครงสร้างใหม่ในขณะที่เขียนการทดสอบหน่วย ชำระหนี้ (นี้) ออกแบบหนี้ในรหัสทั้งหมดที่คุณสัมผัสทุกครั้งที่คุณ:

• พัฒนาฟีเจอร์ใหม่
• แก้ไขปัญหา

เพิ่มความเร็วในการพัฒนารอบแรกของการทดสอบโดย:

• การปรับโครงสร้างใหม่เพื่อแปลงโมดูลโค้ดเป็นภาษาสคริปต์
• ใช้เครื่องทดสอบที่ทำงานบนคลาวด์อย่างรวดเร็ว

รหัส Refactor เพื่อใช้การเชื่อมต่อต่ำ (ของหน่วยภายในสูงมาก) โดย:

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

การเจริญเติบโตแบบอินทรีย์นั้นดี การออกแบบด้านหน้าขนาดใหญ่ไม่ดี

มีผู้นำที่มีความรู้เกี่ยวกับการออกแบบในปัจจุบัน ถ้าไม่อ่านรหัสของโครงการจนกว่าคุณจะมีความรู้

อ่านหนังสือการปรับโครงสร้างใหม่

คำตอบง่ายๆ: คุณไม่สามารถ

นั่นเป็นเหตุผลที่คุณควรตั้งเป้าหมายในการเขียนซอฟต์แวร์ขนาดเล็กและเรียบง่าย มันไม่ง่าย.

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

การแก้ปัญหาที่แท้จริงมีขนาดใหญ่และซับซ้อนสามารถแก้ไขได้โดยการสร้างโมดูลขนาดเล็กและเรียบง่าย

ในคำอื่น ๆ ตามที่คนอื่นชี้ให้เห็นความเรียบง่ายและการมีเพศสัมพันธ์หลวมเป็นส่วนผสมที่สำคัญ

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

ฉันทำงานบนรหัสฐานสำหรับผลิตภัณฑ์ที่ได้รับการพัฒนาอย่างต่อเนื่องตั้งแต่ปี 1999 ดังนั้นคุณสามารถจินตนาการได้ว่ามันซับซ้อนมากในตอนนี้ แหล่งที่ใหญ่ที่สุดของการแฮ็กข้อมูลใน codebase ของเรามาจากหลาย ๆ ครั้งที่เราต้องทำการพอร์ตจากASP ClassicไปยังASP.NETจาก ADO ไปยัง ADO.NET จาก postbacks ไปยังAjax , การสลับไลบรารี UI มาตรฐานการเข้ารหัส ฯลฯ

โดยรวมแล้วเราได้ดำเนินการตามสมควรในการดูแลรักษารหัสฐาน สิ่งสำคัญที่เราได้ทำไปนั้นคือ:

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

2) รักษาสภาพแวดล้อมการพัฒนาให้เรียบร้อย -ระมัดระวังเกี่ยวกับการลบรหัสที่ไม่ได้ใช้อีกต่อไปและอย่าทิ้งสำเนาสำรอง / สำเนาการทำงาน / รหัสการทดลองที่มีอยู่ในไดเรกทอรีโครงการ

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

เนื่องจากคุณติดแท็กคำถามด้วยการจัดการโครงการฉันพยายามเพิ่มจุดที่ไม่ใช่โค้ดบาง :)

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

• ความมั่นคง / ความสม่ำเสมอไม่สามารถถูกตรึงเครียดได้เพียงพอ สิ่งนี้จะกีดกันวัฒนธรรมของ 'ไปคนเดียว' และกระตุ้นให้นักพัฒนาใหม่ถามหากพวกเขามีข้อสงสัย

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

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

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

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

หนึ่งในทรัพย์สินของรหัส maitainable สูงเป็นฟังก์ชั่นที่มีความบริสุทธิ์

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

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

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

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

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

นอกจากคำตอบอื่น ๆ ฉันขอแนะนำเลเยอร์ มีไม่มากพอที่จะแยกรหัสประเภทต่าง ๆ ได้

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

อีกวิธีหนึ่งคือการได้รับทุกคนอ่านcomp.risksและThe Daily WTFเพื่อให้พวกเขาได้เรียนรู้ผลกระทบของการออกแบบและการเขียนโปรแกรมที่ไม่ดีที่ไม่ดีและพวกเขาจะกลัวเห็นรหัสของตัวเองโพสต์ในทุกวัน WTF

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

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

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

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

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

และเคล็ดลับส่วนตัวที่ฉันชอบนั้นเป็นคำพูดที่มากกว่าแม้ว่าฉันจะไม่สามารถจำแหล่งที่มาได้:

"รหัสราวกับว่าคนที่มาหลังจากคุณเป็นโรคจิตที่รู้ว่าคุณอยู่ที่ไหน"

หนึ่งในหลักการที่ว่ายังไม่ได้รับการกล่าวถึง แต่ที่ผมพบที่สำคัญคือเปิด / ปิดหลักการ

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

แค่ 2 เซ็นต์ของฉัน

• เป็นลูกเสือ ปล่อยให้ตัวทำความสะอาดโค้ดอยู่เสมอเกินกว่าที่คุณจะพบ

• แก้ไขหน้าต่างที่เสียหาย ความคิดเห็นทั้งหมดที่ "เปลี่ยนแปลงในรุ่น 2.0" เมื่อคุณอยู่ในรุ่น 3.0

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

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

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

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

• ฟอร์แมตรหัสทั้งหมดใหม่ให้เป็นมาตรฐานการเข้ารหัส

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

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

• เผยแพร่เอกสารการออกแบบซ้ำบนวิกิ สิ่งนี้จะช่วยให้ความรู้เป็นสถาบัน

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

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

• ถ้าหัวหน้าทีมของคุณไม่ทำสิ่งเหล่านี้แสดงว่าไม่ดีสำหรับ บริษัท

• พยายามให้แน่ใจว่ารหัสใหม่ทั้งหมดได้รับการทดสอบหน่วยที่เหมาะสมด้วยความครอบคลุมที่วัดได้ ดังนั้นปัญหาไม่สามารถแย่ลงได้มากนัก

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

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

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

ฉันมาเรียกสิ่งนี้ว่า "Winchester Mystery House Effect" มันเริ่มง่ายพอ แต่ในช่วงหลายปีที่ผ่านมาคนงานหลายคนได้เพิ่มคุณสมบัติแปลก ๆ มากมายโดยไม่มีแผนโดยรวมที่ไม่มีใครเข้าใจจริงๆอีกต่อไป ทำไมบันไดนี้ถึงไม่ไปไหนและทำไมประตูนั้นเปิดทางเดียว? ใครจะรู้?

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

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

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

การบำรุงรักษาโครงการที่ดำเนินมายาวนานนั้นเป็นความรับผิดชอบของผู้จัดการโครงการในฐานะผู้พัฒนารายบุคคล

ผู้คนไม่แนะนำแฮ็กเพราะพวกเขาชอบ พวกเขาถูกบังคับโดยสถานการณ์

ฉันแค่ต้องการวางปัญหาที่ไม่ใช่ด้านเทคนิคและวิธีการปฏิบัติ (อาจจะ)

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

หากคุณฝันถึงคุณภาพของรหัสที่พบในหนังสือเหล่านั้นคุณต้องมีหัวหน้าที่เกี่ยวข้องกับเรื่องนี้

หรือถ้าคุณแค่อยากจะเชื่อเรื่อง "Frankenstein project" นี่คือเคล็ดลับของฉัน:

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

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

นอกเหนือจากการใช้งานฟีเจอร์และการแก้ไขข้อผิดพลาดใช้เวลาในการล้างข้อมูลโค้ด

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

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

คุณสามารถพิจารณาการแชร์ห้องสมุดเล็ก ๆ ที่เป็นอิสระระหว่างหลาย ๆ โครงการ (submodules git เป็นเพื่อนของคุณ)

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

หากคุณใช้ C หรือ C ++ และไม่ชอบความคิดในการมีไฟล์. so ขนาดเล็กจำนวนมากคุณสามารถลิงก์ไลบรารีทั้งหมดเข้าด้วยกันเป็นไฟล์. so ที่ใหญ่กว่าหรือมิฉะนั้นคุณสามารถทำการลิงก์แบบสแตติกได้ เช่นเดียวกันกับ Java เพียงเปลี่ยน. so เป็น. jar

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

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

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

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