Tập hợp tối thiểu của các thực tiễn tốt nhất / nổi tiếng trong phát triển phần mềm cho một lập trình viên solo là gì? [đóng cửa]

Tôi đã là lập trình viên cô đơn trong công việc của tôi trong một thời gian khá dài. Thông thường tôi đã đọc bài viết và bài viết về

• Hệ thống kiểm soát phiên bản
• Tích hợp / Giao hàng liên tục
• Phương pháp phát triển: Scrum, Waterfall, V-Model, Agile, XP, v.v.
• Quản lý dự án phần mềm

Nhưng hầu như tất cả trong số họ dường như tập trung vào NHÓM. Tôi không phải là một nhóm, vậy đâu là tập hợp tối thiểu tuyệt đối cho chỉ một lập trình viên? Hãy xem xét các điều kiện sau:

• Tôi không có xung đột với mã người khác.
• Tôi không cần phải duy trì các tập tin / cây thư mục, môi trường phát triển của tôi quan tâm đến việc tự phiên bản (phát triển dựa trên hình ảnh).
• Không có yêu cầu chính thức, người dùng của tôi không biết họ muốn gì và họ vẫn ổn với điều đó.
• Người duy nhất có thể quan tâm đến việc cung cấp một bản phát hành hoặc tài liệu là tôi, về cơ bản khách hàng muốn KẾT QUẢ và không quan tâm đến các phương pháp phần mềm, v.v.

Quan điểm của tôi là tôi không muốn dành quá nhiều thời gian và sức lực cho bất cứ điều gì không liên quan trực tiếp đến yêu cầu của khách hàng. Có khuyến nghị nào không?

Không có câu trả lời đúng cho câu hỏi này vì nó phụ thuộc vào mỗi người. Nếu bạn sử dụng iPad để thực hiện tất cả công việc phát triển của mình và khách hàng hài lòng với bạn, bạn không có lý do gì để thay đổi cả.

Tuy nhiên, nếu tôi ở vị trí của bạn, tôi sẽ thực thi mạnh mẽ những điều sau:

• Hệ thống kiểm soát phiên bản - Mặc dù bạn có thể nghĩ rằng một hệ thống phát triển dựa trên hình ảnh thực hiện công việc liên quan đến sao lưu thường xuyên và không có gì, bạn không có chỗ nào luồn lách cho các tính năng thử nghiệm mà người ta thường sử dụng một nhánh . Bạn cũng không có cách nào để giữ lại một phiên bản quan trọng của dự án ( gắn thẻ ). Nếu bạn từng mở rộng ra ngoài chính mình, các nhà phát triển tham gia sẽ nghĩ họ đang ở địa ngục.
• Agile - Phương pháp này cực kỳ áp dụng cho những khách hàng không biết họ muốn gì. Sớm hay muộn, họ sẽ nhận ra rằng họ không muốn chi tiền để theo đuổi cái đuôi của mình - họ sẽ muốn thấy sự tiến bộ.
• Công cụ quản lý dự án - Đây là một điều bắt buộc. Thật là ghê gớm khi có thể giữ lại mọi thứ trong đầu, nhưng bạn không phải làm thế. Kỷ luật và sử dụng một công cụ quản lý dự án (ví dụ Redmine ) sẽ cho phép bạn tách các nhiệm vụ của mình và cung cấp cho bạn một lịch sử dễ duyệt qua công việc của bạn. Nó sẽ rất quan trọng khi bạn bắt đầu sạc mỗi giờ.

Kiểm soát phiên bản là điều bắt buộc đối với bất kỳ lập trình viên nào kể cả một người đơn độc. Điều đó có nghĩa là bạn có thể khôi phục một cách đơn giản và nhanh chóng từ các tệp đã bị xóa và các thay đổi phức tạp chỉ là sai.

Về cơ bản, nó cứu bạn khỏi thứ rác rưởi ngu ngốc bạn làm khi bạn đi làm.

Như những người khác nói, kiểm soát phiên bản hoặc quản lý mã nguồn là vô cùng quan trọng. Sử dụng DVCS và tìm hiểu mọi thứ về nó. Nó thực sự không quan trọng nó là cái gì, mặc dù nó có thể có lợi cho bạn nếu bạn chọn một thứ phổ biến: git hoặc đồng bóng.

Một điều nữa tôi không thấy được đề cập, là một kịch bản xây dựng một bước . Đây không phải là tích hợp liên tục thẳng (theo ý kiến ​​của tôi thiên về BS), nhưng là một công cụ rất hữu ích. Bất cứ khi nào bạn cần thực hiện cập nhật khẩn cấp, bạn có thể chỉ cần chạy tập lệnh và được thực hiện với nó. Khi gần kết thúc dự án, cũng có một số bản dựng được yêu cầu mỗi ngày. Kinh nghiệm của tôi là nó được đền đáp rất nhiều, ngay cả khi quá trình xây dựng không quá phức tạp. Bạn thậm chí có thể thêm khả năng tải lên ftp, báo cáo trong e-mail, chạy thử nghiệm đơn vị, cài đặt trình xây dựng, ký, v.v. Có kịch bản được viết từ đầu, dễ dàng duy trì và mở rộng với nhiều bước hơn khi dự án tiến triển.

Tôi sẽ chỉ trả lời một, kiểm soát phiên bản là rất quan trọng đối với bất kỳ dự án nào và không chỉ các nhóm. Phải mất một khoảng thời gian rất nhỏ khi bạn sử dụng nó nhưng nó cung cấp một lịch sử phong phú để bạn quay trở lại, nó không phải là một viên đạn bạc nhưng chắc chắn sẽ rất tốt để có thể trở lại một bản sao hoạt động nếu điều đó thực sự tính năng thử nghiệm đã phá vỡ hầu hết các ứng dụng.

Kiểm soát phiên bản là tuyệt đối phải. Không chỉ vì giữ nguồn ok, mà vì khảo cổ nguồn. Một năm kể từ khi có thể kiểm tra một lớp học hoặc thủ tục phát triển có thể tiết kiệm rất nhiều đau đớn nếu bạn cố gắng "sửa chữa" một số đoạn mã kỳ lạ.

Đối với phương pháp luận - tôi thực sự khuyên bạn nên tuyên ngôn cho các lập trình viên . Nó thường mang lại kết quả tuyệt vời trong các nhóm nhỏ vì không có chi phí hoạt động và không phải giữ trong đầu bạn cách mà các khung công tác chứa ứng dụng web CMS dựa trên vai trò MVC dựa trên nền tảng J2EE hoạt động .