Làm thế nào để đối phó với các mã phức tạp trong các dự án (rất lớn)

Tôi đang chuẩn bị một cuốn hồi ký về "Tại sao (một số) dự án CNTT trở nên quá phức tạp và làm thế nào để tránh nó?".

Nếu bạn đã từng gặp các dự án có mã phức tạp hoặc khó bảo trì, làm thế nào bạn quản lý để vượt qua nó?

Nếu bạn phải chọn giữa một số ứng dụng để sử dụng trong dự án của mình, ưu tiên hàng đầu của bạn trong chức năng của chúng là gì và tại sao?

Tài liệu, tài liệu, tài liệu!

Tôi làm việc với một số mã MVC khá phức tạp và hiện tại tôi chỉ thực sự hiểu cách thức hoạt động của nó, trái ngược với việc chấp nhận nó trên đức tin. Bất cứ khi nào tôi thực hiện một thay đổi mà tôi có một thời gian khó khăn để tìm ra, tôi đặt một nhận xét trong mã ở phần đó để giúp làm rõ những gì đang xảy ra. Nó có thể không giúp tôi vì nó không ở đó, nhưng nó sẽ giúp người tiếp theo. Tôi cũng muốn yêu cầu các lập trình viên khác xung quanh tôi xem xét các thay đổi của tôi để xem chúng có rõ ràng không.

Công ty của tôi có một wiki nội bộ mà chúng tôi sử dụng để ghi lại rất nhiều tác vụ meta mà chúng tôi làm, như các sự cố máy chủ ảo, truy vấn phổ biến, v.v ... Bất cứ khi nào tôi gặp phải điều gì đó tôi chưa từng làm trước đây nhưng tôi sẽ phải làm thường xuyên, tôi kiểm tra để xem nếu có wiki trên đó. Nếu không tôi sẽ làm một cái. Gần đây nhiều người đã tham gia vào nó, vì vậy tôi hy vọng nó sẽ phát triển nhanh hơn. Tôi nghĩ rằng nó thực sự giúp truyền thông về các nhiệm vụ trần tục hơn chúng ta có.

Tôi không nghĩ bạn có thể hoàn toàn tránh được sự phức tạp theo thời gian, nhưng có nhiều cách để giảm thiểu nó:

• Giữ mã càng sạch càng tốt mọi lúc, trong phạm vi lý do. (Theo cách "chú Bob định nghĩa" sạch ".)
• Áp dụng đánh giá mã và / hoặc lập trình cặp để giảm tỷ lệ cược của một nhà phát triển quá mức những thứ không cần thiết.
• Duy trì kiểm tra đơn vị đầy đủ và kiểm tra tích hợp.
• Đầu tư vào một máy chủ tích hợp liên tục và xây dựng thường xuyên. Phát hành thường xuyên quá, nếu có thể.

Tất cả điều này phần nào phụ thuộc vào những gì dự án thực sự đòi hỏi. Đôi khi, ví dụ, sẽ có ích khi chấp nhận sự phức tạp để đổi lấy hiệu suất. Không phải tất cả các mã phức tạp nhất thiết phải là một điều xấu. Tuy nhiên, nói chung, tôi nghĩ làm theo các hướng dẫn này sẽ giúp.

• nợ kỹ thuật

  tái cấu trúc để loại bỏ

• thay đổi kinh doanh

  thích nghi và hết hạn

• thay đổi công cụ

  công cụ mới, kiến ​​trúc cũ = sự không khớp trở kháng

Ngoài ra, hãy chống lại sự cám dỗ để thêm các bản hack nhanh vì mã đã phức tạp / xấu / hacky rồi. Theo kinh nghiệm của tôi, bạn sẽ kết thúc với sự phức tạp theo cấp số nhân.