Làm thế nào để cải thiện việc đào tạo sinh viên về khả năng duy trì? [đóng cửa]

Bảo trì là một cổ phần lớn của phát triển phần mềm chuyên nghiệp. Thật vậy, bảo trì gần như luôn là phần dài nhất của vòng đời phần mềm, vì nó kéo dài từ khi phát hành dự án cho đến khi cơ bản kết thúc.

Hơn nữa, các dự án đang được bảo trì chiếm phần lớn trong tổng số các dự án. Theo http://www.vlegaci.com/298/interesting-statistic-%E2%80%93-numbers-of-programmers-in-maintenance-vs-development/ , tỷ lệ các dự án đang được bảo trì là khoảng 2 / 3.

Gần đây tôi đã bắt gặp câu hỏi này , nơi anh chàng trông khá ngạc nhiên khi phát hiện ra rằng công việc của anh ta chủ yếu là về bảo trì. Sau đó tôi quyết định mở một cuộc thảo luận (tiếng Pháp) trên trang web chính của cộng đồng các chuyên gia phát triển phần mềm của Pháp ( http://www.developpez.com/ ). Cuộc thảo luận có tiêu đề "Các sinh viên có được đào tạo tốt về thực tế phát triển phần mềm chuyên nghiệp không?" và chủ yếu là về khả năng bảo trì . Nó đã chỉ ra rằng, ít nhất là ở Pháp, mọi người không đủ chuẩn bị để đối mặt với việc bảo trì trong cả hai khía cạnh của nó:

• duy trì mã hiện có
• tạo mã duy trì

Câu hỏi của tôi ở đây lặp lại cuộc thảo luận này và nhằm mục đích tìm ra một cách tốt để dạy khả năng bảo trì.

• Làm thế nào chúng ta có thể dạy bảo trì?
• Những loại bài tập bạn sẽ đề nghị?
• Nếu bạn đã được đào tạo tốt về khả năng bảo trì, bạn đã tham gia loại khóa học cụ thể nào?

[sửa] Sau một số hiểu lầm, tôi nghĩ rằng tôi phải làm rõ câu hỏi của mình. Là một nhà lãnh đạo dự án và nhà phát triển phần mềm, tôi thường làm việc với các thực tập sinh hoặc sinh viên mới tốt nghiệp. Tôi đã từng tốt nghiệp bản thân mình. Có điều là sinh viên thường không quen thuộc với các nguyên tắc như RẮN làm tăng khả năng duy trì của một dự án. Chúng tôi thường kết thúc với những khó khăn quan trọng làm cho các dự án phát triển (khả năng bảo trì thấp). Những gì tôi đang tìm kiếm ở đây là một ví dụ học thuật cụ thể về việc giảng dạy thành công về tầm quan trọng của khả năng duy trì và làm thế nào để tạo ra mã tốt hơn về điểm đặc biệt này; hoặc đề xuất có thể để cải thiện cách đào tạo sinh viên.

Làm thế nào chúng ta có thể dạy bảo trì?

Đó là vấn đề thực hành.

Cách đơn giản nhất để thực hành nó theo cách có kiểm soát mà tôi có thể nghĩ đến là mô phỏng dự án bảo trì điển hình như sau.

Nhận một số dự án ( Dự án A ) được thực hiện tốt và giới thiệu một số vấn đề về nó: tiêm một số lỗi, tạm dừng mã trùng lặp và mã chết, bỏ một số tính năng, kiểm tra đơn vị và tài liệu ở đây và v.v. Tên cho điều đó, như Dự án A - phiên bản bị hư hỏng .

Thiết lập trình theo dõi vấn đề và điền vào đó với các yêu cầu tương ứng với các thiệt hại cụ thể mà bạn đã thực hiện. Thiết lập các quy tắc và thực tiễn cơ bản cho quy trình phát triển - VCS cam kết, đánh giá mã, QA, v.v. - xem xét lấy những gì bạn có thể từ danh sách kiểm tra được cung cấp trong Thử nghiệm Joel .

• khóa học 1.
  Sửa lỗi, thêm các bài kiểm tra đơn vị, tài liệu và tính năng bị thiếu.
• khóa học 2.
  Tái cấu trúc.
• khóa học 3.
  Bảo trì / cải thiện các dự án ban đầu được sử dụng bởi các sinh viên năm tới
  - Dự án A phiên bản 2.0 và Dự án A - phiên bản 2.0 bị hư hỏng , tương ứng.
  _{Bằng cách cải thiện phiên bản bị hư hỏng, tôi có nghĩa là tạo ra thiệt hại giáo dục tốt hơn cho nó. :)}

Trong số các thực tiễn được đề cập ở trên, đặc biệt chú ý đến các đánh giá mã . Đây có thể là cách hiệu quả nhất để đảm bảo rằng mã dễ bảo trì, như được chỉ ra, ví dụ như câu trả lời hàng đầu trong câu hỏi liên quan .

Tuyên bố miễn trừ trách nhiệm: Tôi vừa có bằng CS. Toi khong phai la giao vien.

Điều này nghe có vẻ rõ ràng, nhưng tôi nghĩ cách tốt nhất để dạy bảo trì mã là để sinh viên thực hiện bảo trì mã. Đây là những gì tôi sẽ làm:

1. Thực hiện một vấn đề phức tạp vừa phải và hai triển khai giống hệt nhau về mặt ngữ nghĩa, nhưng một vấn đề có thể duy trì hơn nhiều so với vấn đề khác.
2. Yêu cầu một số thay đổi / bổ sung tính năng dễ thực hiện hơn trên cơ sở mã tốt hơn. Một nửa số sinh viên phải thực hiện những điều này trên cơ sở mã dễ bảo trì hơn, nửa còn lại trên cơ sở ít bảo trì hơn.
3. Để công bằng, bạn có thể muốn lặp lại bài tập này với các vai trò đảo ngược.
4. So sánh số lượng trung bình của các thay đổi được triển khai thành công giữa các cơ sở mã tốt và xấu và thời gian dành cho việc thực hiện chúng. Yêu cầu học sinh chia sẻ kinh nghiệm, nói lên sự bất bình và nói chung về công việc họ đã làm.

Ý tưởng là không chỉ để sinh viên làm việc với mã của người khác, mà còn để họ phát triển sự đánh giá cao về mã có thể duy trì, hy vọng sẽ cải thiện kỹ năng thiết kế của họ.

Bảo trì là một đức tính, không phải là một kỹ năng. Có nhiều con đường để tạo ra các dự án có thể bảo trì, nhưng không có một công thức nào được đảm bảo để sản xuất chúng.

Nếu bạn coi trọng những đức tính như lòng tốt và sự rộng lượng, bạn sẽ tìm cách để thực hành tương tự trong cuộc sống hàng ngày của bạn. Điều này cũng tương tự với khả năng bảo trì: nếu bạn và tổ chức của bạn coi trọng khả năng duy trì, bạn sẽ giữ nó trong tâm trí của bạn trong khi thiết kế và thực hiện dự án của bạn. Nó sẽ là một lý do chính đáng để dành thêm một chút thời gian để xây dựng một cái gì đó bởi vì bạn biết rằng khả năng bảo trì được đánh giá cao. Ngược lại, dành thêm thời gian cho mục đích duy trì trong một tổ chức không coi trọng nó là điều không được khuyến khích.

Nếu bạn muốn dạy mọi người làm cho mọi thứ có thể duy trì được, bạn nên bắt đầu bằng cách làm rõ rằng tổ chức của bạn coi trọng khả năng duy trì. Chỉ định nó trong các yêu cầu cho các dự án của bạn. Làm cho nó một trong những tiêu chí để đánh giá mã thành công. Tóm lại, làm cho khả năng duy trì một phần của văn hóa của bạn .

Tiếp theo, sẵn sàng dành một số tài nguyên để cải thiện khả năng bảo trì trong các dự án hiện tại của bạn. Xác định các phần của dự án nơi các lỗi liên tục xuất hiện hoặc sửa lỗi hoặc thực hiện các thay đổi là rất khó khăn và mất nhiều thời gian, và thiết kế lại hoặc tái cấu trúc để tạo điều kiện bảo trì.

Cuối cùng, truyền bá các nhà phát triển mới vào văn hóa khả năng duy trì của bạn bằng cách chỉ định họ cho các nhóm đã thực hành nó hàng ngày. Không có cách nào tốt hơn để giúp ai đó chấp nhận một giá trị hơn là cung cấp cho họ nhiều ví dụ và hướng dẫn tốt.

Tôi không thích thuật ngữ Duy trì liên quan đến phát triển phần mềm. Thực tế là tất cả các phần mềm đều có thể bảo trì ở chỗ nó có thể phải chịu công việc bảo trì, vì vậy vấn đề thực sự là phần mềm có đắt hay không tốn kém để bảo trì hay không, nói một cách tương đối. Tôi biết điều này nghe có vẻ như là một tuyên bố rất khoa trương khi bắt đầu câu trả lời, tuy nhiên quan điểm của tôi sẽ trở nên rõ ràng hơn trong giây lát.

Vấn đề với trình độ CNTT chuyên ngành phát triển phần mềm là họ thực sự chỉ dạy cho sinh viên mức tối thiểu nhất mà sinh viên cần biết về viết phần mềm. Kỹ năng và kiến ​​thức chuyên môn có được thông qua việc học được thực hiện trong vài năm đầu sau đóđủ điều kiện cho bằng cấp. Đây là khi một sinh viên tốt nghiệp bắt đầu làm việc trên các dự án thực sự quan trọng đối với khách hàng, trong một môi trường có áp lực lớn để thực hiện, và kỳ vọng là tạo ra một sản phẩm theo tiêu chuẩn chuyên nghiệp. Đáng buồn thay, nhiều công ty không khuyến khích một nền văn hóa nơi các tiêu chuẩn chuyên nghiệp về phần mềm được duy trì và kết quả là các dự án trở nên tốn kém để phát triển và duy trì kết quả. Thật không may cho sinh viên tốt nghiệp của chúng tôi, họ học được rất nhiều thói quen xấu trong môi trường như vậy trong những năm đầu sự nghiệp, và có lẽ phải rất lâu sau họ mới học được cách khắc phục những thói quen này ... nếu có.

Bạn sẽ tốt hơn nếu dạy cho sinh viên cách viết mã sạch và cách xác định các vấn đề trong phần mềm thường phát sinh nợ kỹ thuật . Tìm hiểu các cuốn sách về Clean Code , Tái cấu trúc và Phát triển phần mềm tinh gọn như một điểm khởi đầu và bắt đầu dạy học sinh viết các bài kiểm tra đơn vị trước mã thực thi để đảm bảo mức độ bao phủ thử nghiệm cao. Dạy học sinh nhận ra các mẫu trùng lặp và lặp lại trong mã của chúng và cách cấu trúc lại mã để loại bỏ sự trùng lặp đó. Giúp học sinh hiểu và áp dụng các nguyên tắc như RẮN và KHÔ. Quan trọng nhất, loại bỏ ý tưởng này rằng khả năng duy trì mã là thứ được thực hiện chỉ dựa trên thiết kế và triển khai mã, và thay vào đó thấm nhuần ý thức về sự khéo léo và chất lượng trong sản xuất phần mềm ngay từ đầu, tìm cách tinh chỉnh mã khi nó được triển khai để giảm thiểu tác động của nợ kỹ thuật và do đó giữ cho chi phí duy trì phần mềm ở mức tối thiểu theo thời gian.

Tôi nghĩ rằng cách tốt nhất để học các loại kỹ năng này là bằng cách thực hiện đánh giá mã và lập trình cặp. Trong quá trình đánh giá mã, nhân viên có kinh nghiệm có thể chỉ ra cách làm cho mã dễ bảo trì hơn (thường bằng cách làm cho nó dễ đọc hơn) và giải thích lý do tại sao một số lựa chọn nhất định có thể tạo mã dễ bảo trì hơn.

Lập trình cặp là một cách thậm chí tốt hơn để dạy loại điều này, bởi vì nó mang lại cho nhân viên ít kinh nghiệm trực tiếp hơn trong việc duy trì mã với một người đã biết cách làm tốt nó.

Ngoài ra còn có một số cuốn sách tuyệt vời mà bạn có thể đọc về việc viết mã sạch, có thể bảo trì. Clean Code đến với tâm trí.

Thật khó để có được trải nghiệm này thông qua các học viện vì sinh viên hiếm khi sửa đổi các cơ sở mã lớn. Hầu hết các kỹ năng này sẽ đến từ việc học trong công việc, và đánh giá mã và lập trình cặp có thể thực sự tạo điều kiện thuận lợi cho việc học này.

Mã tốt = Ít bảo trì và Dễ dàng nâng cao / thêm tính năng.

Mã xấu = cơn ác mộng bảo trì

Về cơ bản, chúng tôi phải thông báo cho các sinh viên rằng "bất cứ khi nào có một mã tào lao trong một dự án, một nhà phát triển mới sẽ gia nhập công ty vì tác giả ban đầu của mã sẽ bị ảnh hưởng và phần mềm bị ảnh hưởng như thế nào . "

Vì vậy, một trong những cách tốt nhất để dạy sinh viên về bảo trì phần mềm là đưa ra ví dụ về cả mã tốt và mã xấu và yêu cầu họ thêm một tính năng và sau đó dạy họ rằng viết mã tốt không chỉ để tự hài lòng mà còn để tạo ra nó dễ dàng cho những người sẽ duy trì mã.

Tập thể dục:

1) Có một mã xấu được viết sẵn (ví dụ) mã trùng lặp, một phương thức nói "để tính toán khoản thanh toán thế chấp" được viết ở 9 vị trí trong một dự án.

Yêu cầu học sinh tăng cường tính năng "thêm phụ phí 1,2% cho tất cả các khoản thanh toán thế chấp".

Bây giờ học sinh sẽ thấy nỗi đau của việc định vị và sửa mã ở tất cả 9 vị trí. Có nhiều cơ hội anh ta không thể xác định được tất cả 9 địa điểm "thanh toán thế chấp" được tính toán.

2) Bây giờ hiển thị mã Tốt có phương thức này tính toán khoản thanh toán thế chấp ở một và chỉ một nơi . chứng minh cho học sinh thấy cách dễ dàng tăng cường mã được viết tốt và giải thích cho anh ta cách nó tăng cường khả năng duy trì của mã / dự án.

BTW, tôi thích cách tiếp cận của bạn trong việc đưa các sinh viên đến khả năng bảo trì của phần mềm.

@mattmattj: Vì có rất nhiều câu trả lời và liên kết tôi đã đăng cũng có một số gợi ý hay, tôi sẽ thêm một cái gì đó hy vọng không phải là sự lặp lại của các câu trả lời đã được đăng.

Đầu tiên, một PHẢI định nghĩa "khả năng bảo trì" - không có một định nghĩa nào được chấp nhận bởi tất cả - tương tự như định nghĩa của kiến ​​trúc phần mềm. Vì vậy, chọn một cái mà bạn cảm thấy là quan trọng nhất, tất cả bao gồm và nêu nó trong tối đa 3-4 dòng. Sau đó, bạn có thể nói về một số số liệu như - thời gian để nhớ lại / hiểu mã của riêng bạn (hoặc của người khác), số WTF mỗi phút / giờ, v.v. Giữ cho nó nhẹ nhàng (hài hước) - điều đó sẽ khiến họ dễ tiếp nhận hơn với những gì bạn có để nói sau đó

Một số bài tập (nghe có vẻ hơi trùng lặp với một số câu trả lời, xin vui lòng tha thứ cho điều đó)

Chia lớp thành hai - cung cấp cho một phần một bài tập mã hóa đơn giản cần thực hiện trong 1-2 ngày. Tối đa Hạn chót. Họ phải hoàn thành công việc trong mọi trường hợp - hướng dẫn - "mã làm việc" khi họ thấy phù hợp. Đối với nhóm sinh viên khác, bài tập tương tự nhưng có một danh sách các quy ước (đặt tên) và một số hướng dẫn về thiết kế và cách trừ điểm nếu không tuân theo. Điều này KHÔNG phải là gian lận, ngay cả khi nó có vẻ như vậy;) Bây giờ họ đã trao đổi mã, tức là nhóm 1 bây giờ hoạt động trên những gì nhóm 2 đã làm và ngược lại. Bây giờ đề nghị sửa đổi cho bài tập mã hóa ban đầu và yêu cầu họ thực hiện nó trong cùng khung thời gian. Tái cấu trúc và hỏi họ xem nó dễ / khó như thế nào và mở ra các cuộc thảo luận / ý kiến. Điểm chắc chắn sẽ về nhà - cơ hội cao 50% lớp học sẽ hạnh phúc và thấy nó dễ dàng và 50% thấy khó khăn. Bạn cũng có thể yêu cầu họ tự làm việc sau 3 tuần và xem họ có thể làm việc đó trong 1 ngày không;)

(Một thay đổi tốt là bạn viết cùng một đoạn mã theo cách dễ hiểu và đưa cho lớp để sửa đổi cùng với mã của họ)

Đây là nơi bạn đặt nền tảng của khả năng bảo trì - mỗi dòng mã được sửa đổi / cập nhật đều tiêu tốn tiền của công ty. Việc đọc và hồi tưởng mã càng dễ dàng thì việc sửa đổi càng tốt / nhanh hơn sẽ giúp giảm thời gian tiếp thị. Rất quan trọng trong không gian công nghệ nhịp độ nhanh ngày nay. Bảo trì là chìa khóa để phát triển hiệu quả của các hệ thống.

Điều quan trọng là phải hiểu sự khác biệt giữa phát triển trường xanh và trường nâu - không phải mọi dự án hoặc hệ thống sẽ được tạo ra từ đầu (khá khó để tìm hoặc là một phần của các dự án "từ đầu"). Giải thích rằng trường có màu nâu "vốn có" và bạn phải dành thời gian định hình nó khi bạn đi cùng với giai đoạn cuối cùng khi nó phát triển "ngoài tầm tay" (chỉ có thể khi độ trôi quá nhiều và 'không thể nhận ra'). Càng sớm chấp nhận điều đó càng tốt. Điều này thật khó khăn vì lập trình vốn đã rất sáng tạo nhưng việc tăng cường mã của người khác không được coi là như vậy - xoay vòng nó. Sáng tạo có khả năng hiểu mã và sau đó áp dụng sáng tạo "của bạn" để nâng cao mã - nếu được duy trì tốt hơn, bạn sẽ có thể nâng cao nó một cách sáng tạo hơn trong tương lai.

Vui lòng tham khảo tương tự spaghetti trong liên kết ở trên ... hy vọng điều này sẽ giúp đạt được một số điểm về nhà. Các câu trả lời khác giúp điền vào các khoảng trống và sẽ giúp bạn với việc giảng dạy! May mắn nhất!