จะปรับปรุงการฝึกอบรมนักเรียนเกี่ยวกับการบำรุงรักษาได้อย่างไร? [ปิด]

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

นอกจากนี้โครงการที่อยู่ระหว่างการบำรุงรักษาถือเป็นโครงการใหญ่โดยรวม ตามhttp://www.vlegaci.com/298/interesting-statistics-%E2%80%93-numbers-of-programmers-in-maintenance-vs-development/สัดส่วนของโครงการที่อยู่ในการบำรุงรักษาประมาณ 2 / 3

ฉันเพิ่งเจอคำถามนี้ที่ผู้ชายดูประหลาดใจสวยค้นพบว่างานของเขาส่วนใหญ่เกี่ยวกับการบำรุงรักษา ฉันจึงตัดสินใจเปิดการสนทนา (ภาษาฝรั่งเศส)บนเว็บไซต์หลักของชุมชนผู้เชี่ยวชาญด้านการพัฒนาซอฟต์แวร์ของฝรั่งเศส ( http://www.developpez.com/ ) การอภิปรายนี้มีชื่อว่า "นักเรียนได้รับการฝึกฝนอย่างดีพอกับความเป็นจริงของการพัฒนาซอฟต์แวร์มืออาชีพหรือไม่" และส่วนใหญ่เกี่ยวกับการบำรุงรักษา ชี้ให้เห็นว่าอย่างน้อยในฝรั่งเศสผู้คนไม่พร้อมที่จะเผชิญกับการบำรุงรักษาทั้งสองด้าน:

• รักษารหัสที่มีอยู่
• ทำให้รหัสบำรุงรักษา

คำถามของฉันที่นี่สะท้อนถึงการสนทนานี้และมุ่งหวังที่จะหาวิธีที่ดีในการสอนการบำรุงรักษา

• เราจะสอนการบำรุงรักษาได้อย่างไร
• คุณจะแนะนำการออกกำลังกายแบบไหน?
• หากคุณได้รับการฝึกอบรมอย่างดีเกี่ยวกับการบำรุงรักษาหลักสูตรใดที่คุณเรียนโดยเฉพาะ

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

เราจะสอนการบำรุงรักษาได้อย่างไร

นั่นเป็นเรื่องของการปฏิบัติ

วิธีที่ตรงไปตรงมาที่สุดในการฝึกฝนในแบบที่ฉันคิดได้คือการจำลองโครงการบำรุงรักษาทั่วไปดังนี้

รับโครงการ ( โครงการ A ) ที่ทำได้ดีและนำเสนอปัญหาเล็กน้อย: ฉีดบั๊ก, โค้ดดีเจที่ซ้ำซ้อนและโค้ดที่ไม่ต้องใช้, วางคุณสมบัติบางอย่าง, ทดสอบหน่วยและเอกสารที่นี่และที่อื่น ๆ คุณอาจมีความทุ่มเท ชื่อที่เช่นโครงการเอ - รุ่นที่เสียหาย

สร้างตัวติดตามปัญหาและกรอกคำขอที่เกี่ยวข้องกับความเสียหายเฉพาะที่คุณทำ สร้างกฎพื้นฐานและการปฏิบัติสำหรับกระบวนการพัฒนา - กระทำ VCS, ความคิดเห็นรหัส, QA ฯลฯ - พิจารณาสิ่งที่คุณสามารถตรวจสอบรายชื่อจากที่ระบุไว้ในโจเอลทดสอบ

• การเรียนการสอน 1.
  แก้ไขข้อบกพร่องเพิ่มการทดสอบหน่วยที่หายไปเอกสารและคุณสมบัติ
• หลักสูตร 2.
  Refactor
• การเรียนการสอน 3. การ
  บำรุงรักษา / การปรับปรุงโครงการดั้งเดิมที่จะใช้โดยนักเรียนในปีหน้า
  - โครงการ A รุ่น 2.0และโครงการ A - รุ่นที่เสียหาย 2.0ตามลำดับ
  _{โดยการปรับปรุงเวอร์ชันที่เสียหายฉันหมายถึงการสร้างความเสียหายทางวิชาการที่ดีขึ้น :)}

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

คำเตือน: ฉันเพิ่งได้รับปริญญา CS ของฉัน ฉันไม่ใช่ครู

นี่อาจฟังดูชัดเจน แต่ฉันคิดว่าวิธีที่ดีที่สุดในการสอนการบำรุงรักษารหัสคือให้นักเรียนทำการบำรุงรักษารหัส นี่คือสิ่งที่ฉันจะทำ:

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

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

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

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

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

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

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

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

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

คุณจะดีกว่าการสอนนักเรียนวิธีการเขียนโค้ดที่มีความสะอาดและวิธีการแจ้งปัญหาในซอฟต์แวร์ที่มักจะจบลงที่เกิดขึ้นหนี้ทางเทคนิค มองหาหนังสือเกี่ยวกับClean Code , RefactoringและLean Software Developmentเป็นจุดเริ่มต้นสำหรับเป็นจุดเริ่มต้นและสอนให้นักเรียนเขียนการทดสอบหน่วยก่อนรหัสการใช้งานเพื่อให้แน่ใจว่าครอบคลุมการทดสอบระดับสูง สอนให้นักเรียนรู้จักรูปแบบการทำซ้ำและซ้ำภายในรหัสของพวกเขาและวิธีการปรับโครงสร้างรหัสเพื่อลบการทำซ้ำดังกล่าว ช่วยให้นักเรียนเข้าใจและประยุกต์ใช้หลักธรรมเช่นSOLIDและDRY. ที่สำคัญที่สุดอย่าไปกับความคิดที่ว่าความสามารถในการบำรุงรักษาโค้ดนั้นเป็นสิ่งที่ทำตามการออกแบบและการนำรหัสมาใช้ แต่เพียงผู้เดียวและปลูกฝังความรู้สึกของงานฝีมือและคุณภาพในการผลิตซอฟต์แวร์ตั้งแต่เริ่มแรก ปรับแต่งรหัสตามที่มีการใช้งานเพื่อลดผลกระทบของหนี้ทางเทคนิคและทำให้ค่าใช้จ่ายในการบำรุงรักษาซอฟต์แวร์ให้น้อยที่สุดเมื่อเวลาผ่านไป

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

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

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

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

รหัสที่ดี = การบำรุงรักษาน้อยลงและง่ายต่อการเพิ่ม / เพิ่มคุณสมบัติ

รหัสไม่ดี = ฝันร้ายการบำรุงรักษา

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

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

การออกกำลังกาย:

1) มีรหัสที่ไม่ดีล่วงหน้า (เช่น) รหัสที่ซ้ำกันวิธีการพูดว่า "เพื่อคำนวณการชำระเงินจำนอง" ถูกเขียนใน 9 สถานที่ในโครงการ

ขอให้นักเรียนปรับปรุงคุณสมบัติ "เพิ่มค่าธรรมเนียม 1.2% สำหรับการชำระค่าจำนองทั้งหมด"

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

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

BTW ฉันชอบวิธีการของคุณในการเปิดเผยให้นักเรียนเห็นถึงความสามารถในการดูแลรักษาของซอฟต์แวร์

@mattmattj: เนื่องจากมีคำตอบมากมายและลิงค์ที่ฉันโพสต์มีตัวชี้ที่ดีเช่นกันฉันจะเพิ่มสิ่งที่หวังว่าจะไม่ซ้ำซ้อนกับคำตอบที่โพสต์แล้ว

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

แบบฝึกหัดบางอย่าง (อาจฟังดูทับซ้อนกับคำตอบบางส่วนโปรดยกโทษให้)

แบ่งชั้นเรียนออกเป็นสองส่วน - ให้การกำหนดรหัสอย่างง่าย ๆ ในส่วนเดียวซึ่งต้องดำเนินการใน 1-2 วัน แม็กซ์ กำหนดเส้นตายอย่างหนัก พวกเขาต้องทำงานให้เสร็จในทุกสถานการณ์ - แนวทาง - "รหัสการทำงาน" ตามที่เห็นสมควร สำหรับนักเรียนกลุ่มอื่น ๆ ที่ได้รับมอบหมายเดียวกัน แต่มีรายการของการประชุม (การตั้งชื่อ) และแนวทางบางอย่างเกี่ยวกับการออกแบบและวิธีการที่จะถูกหักคะแนนถ้าไม่ได้ปฏิบัติตาม นี่ไม่ใช่การโกงแม้ว่ามันฟังดูเหมือน;) ตอนนี้ให้พวกเขาสลับรหัสเช่นกลุ่มที่ 1 ตอนนี้ทำงานกับสิ่งที่กลุ่ม 2 ทำและในทางกลับกัน ตอนนี้ขอแนะนำให้ปรับเปลี่ยนการกำหนดรหัสต้นฉบับและขอให้พวกเขาทำในกรอบเวลาเดียวกัน Reconvene และถามพวกเขาว่ามันง่าย / ยากแค่ไหนและเปิดพื้นเพื่อพูดคุย / แสดงความคิดเห็น จุดจะชนบ้านแน่นอน - โอกาสสูง 50% ของคลาสจะมีความสุขและพบว่าง่ายและ 50% พบว่ามันยาก คุณอาจขอให้พวกเขาทำงานด้วยตัวเองหลังจาก 3 สัปดาห์และดูว่าพวกเขาสามารถทำได้ใน 1 วันหรือไม่)

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

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

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

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