Tôi hiện là nhà phát triển / kiến trúc sư duy nhất của một ứng dụng web khá lớn (ngăn xếp ASP.NET MVC, khoảng 150K + dòng mã) và kết thúc phát triển đang ở giai đoạn cuối. Như vậy, tôi bắt đầu suy nghĩ về những gì cần phải làm cho dự án và tôi muốn đảm bảo rằng tôi sẽ làm đúng cho bất cứ ai phải duy trì dự án trong tương lai.
Một số điều cần lưu ý khi sẵn sàng giao dự án cho một nhà phát triển hoặc nhóm các nhà phát triển bảo trì khác là gì?
Câu trả lời:
IMHO, nếu bạn chỉ có thể làm một việc trước khi bàn giao dự án của mình (trực tiếp hoặc gián tiếp), tôi khuyên bạn nên kiểm tra gấp đôi và nhân ba xem nó có biên dịch như là từ kiểm soát nguồn không.
Không cười, nhưng tôi không thể nói với bạn bao nhiêu lần tôi đã nhận được "mới nhất" từ một điều khiển nguồn và nó không được biên dịch, chỉ để sau đó tôi không biết "trên hộp cũ của Fred" vì rõ ràng là mã "chỉ biên dịch trên hộp cũ của Fred ". Tôi thậm chí đã có một người chủ cũ nhanh chóng gỡ bỏ máy tính để bàn của tôi khỏi khối lập phương của tôi và thay thế nó bằng "chiếc hộp cũ của Fred" để tôi có thể làm việc trong dự án mà tôi cho là.
Là một phần mở rộng của khuyến nghị ở trên, vì đôi khi nhận được mới nhất không phải là tất cả những gì cần thiết để biên dịch ứng dụng, tôi khuyên bạn nên tạo README.txt và đặt nó vào thư mục gốc của ứng dụng của bạn và đặt nó trong kiểm soát nguồn. Tài liệu README này nên chứa một danh sách các phụ thuộc bên ngoài không thể được kiểm tra trong kiểm soát nguồn (nếu có tồn tại), cách thiết lập cơ sở dữ liệu và bất kỳ sự kỳ quặc nào khác về chu trình biên dịch, thực thi hoặc triển khai của ứng dụng.
Bất cứ điều gì ở trên và ngoài hai đề xuất trên sẽ chỉ là hấp dẫn, nhưng IMHO hai đề xuất trên hầu như được yêu cầu cho bất kỳ dự án nào lớn hơn "Hello World".
BIÊN TẬP:
Về chủ đề tài liệu ...
Trong những năm qua, tôi đã viết và đọc phần tài liệu phần mềm hợp lý của mình với mục đích giảm bớt sự chuyển đổi của nhà phát triển. Tôi muốn nói rằng những tài liệu đó hiếm khi có giá trị như tờ giấy được in trên đó. Các nhà phát triển (bao gồm cả tôi) hiếm khi nghĩ về các phần quan trọng của ứng dụng trong khi viết các tài liệu đó, chúng tôi chỉ có xu hướng nghĩ về các vụ cháy gần đây nhất mà chúng tôi đã chiến đấu. Trên và ngoài thực tế là các tài liệu này có xu hướng không bao gồm tất cả các khía cạnh quan trọng của phần mềm, chúng cũng nhanh chóng bị lỗi thời. Một khi tài liệu đã hết hạn, một nhà phát triển trong tương lai nhiều khả năng sẽ hoàn toàn coi thường nó thay vì đưa nó trở lại để phù hợp với thực tế (nghĩ rằng yêu cầu thay đổi).
Thay vì tài liệu mỗi se, tôi khuyên bạn nên kiểm tra đơn vị. Tôi biết nó có vẻ cũ ở thời điểm này, nhưng hãy để mã làm tài liệu cho bạn. Các bài kiểm tra đơn vị bị hỏng khó có thể bỏ qua (và dễ phát hiện hơn) so với tài liệu Word. Ngoài ra, ngôn ngữ tiếng Anh là không chính xác khủng khiếp để nói rõ các điểm tài chính của thiết kế phần mềm. Đơn giản là có quá nhiều cách để diễn giải ý nghĩa của những câu tiếng Anh đơn giản nhất và điều này chỉ dẫn đến sự nhầm lẫn và / hoặc lỗi.
readmetệp của bạn . Nếu mã biên dịch và chạy, bạn đã thiết lập xong.
Đây chính xác là lý do tại sao ý kiến không phải là mùi mã. Đây cũng là lý do tại sao chúng ta nên ghi lại mã của mình.
Bạn nên chắc chắn rằng bạn có tài liệu vững chắc. Có những chương trình có thể tạo tài liệu từ các bình luận tùy thuộc vào định dạng của các bình luận và ngôn ngữ lập trình.
Xem xét những thông tin bạn muốn về một thư viện hoặc cơ sở mã khi tiếp quản nó. Yêu cầu một người bạn là một lập trình viên đưa ra một cái nhìn nhanh chóng và xem nếu họ phát hiện ra bất kỳ câu hỏi rõ ràng.
Chúc may mắn!
Đảm bảo mã của bạn đang biên dịch & đóng gói ở dạng cuối cùng chỉ bằng một lệnh / lần nhấp.
Tôi không thể đưa ra câu trả lời Một số điều cần chú ý khi chuẩn bị thực hiện dự án? đủ rồi, nên tôi phải viết lại.
Tôi rất kén chọn việc biên dịch bằng một cú nhấp chuột này , vì tôi đã dành quá nhiều thời gian để tìm ra cách biên dịch hoặc đóng gói một dự án mà tôi chỉ phải sửa một lỗi nhỏ. Tôi bắt đầu đưa các tập lệnh bó / bash nhỏ vào các dự án của mình để đóng gói ZIP, JAR hoặc EAR cuối cùng.
Ngoài ra, tôi thêm README.txt vào thư mục gốc mô tả thiết kế tổng thể , các phần phức tạp và môi trường dự án (về mặt giao tiếp với các bộ phận hoặc người khác).
Tôi cố gắng giữ README.txt này nhỏ , vì không ai đọc hơn 200 trang tài liệu đặc tả nếu tất cả những gì bạn muốn làm là sửa lỗi, biên dịch và đóng gói nó. Chi tiết thực hiện được ghi lại trong các bài kiểm tra đơn vị , do đó không cần phải viết lại tất cả trong một cuốn sách ...
Danh sách kiểm tra bàn giao mặc định của tôi:
Nếu bất cứ điều gì bị hỏng, tôi sẽ sửa nó trước khi bàn giao. Không có gì khiến ai đó bắt đầu chạy sau đó kiểm tra dự án, xây dựng và chạy vào ngày bạn nhận được dự án.