Bắt đầu một kiến ​​trúc mạch lạc trong một ứng dụng cũ

Tôi có trách nhiệm cho một trang web lớn dựa trên Asp.Net. Nó hiện là một trang web (không phải ứng dụng web), một số dịch vụ windows và một số thư viện lớp.

Lớp dữ liệu sử dụng hỗn hợp LLBLGEN và Linq To LLBGen, cũng như một số trường hợp SQL nội tuyến kế thừa chưa được cấu trúc lại.

Có một số cách triển khai kiểu người quản lý, nhưng trong nhiều trường hợp, ứng dụng thể hiện mô hình chống UI thông minh (nghĩa là quá nhiều logic kinh doanh trong mã phía sau các lớp)

Trang web có lưu lượng truy cập khá cao và hiệu suất vẫn ổn, nhưng chúng tôi đang phát triển khả năng phát triển của mình lên một nhóm khoảng 10 người, và ngày càng rõ ràng chúng tôi cần một thiết kế xếp chồng lên trên phần mềm trung gian hiện có.

Câu hỏi của tôi là bắt đầu từ đâu? Chúng tôi có 10 năm mã (một số trong đó vẫn thực sự chỉ di chuyển các công cụ ASP Classic), nhiều cách tiếp cận và phong cách khác nhau.

Tái cấu trúc toàn bộ cơ sở mã là không thực tế và, có lẽ không mong muốn

Tôi biết đây không phải là một tình huống mới lạ, có ý tưởng hay khái niệm hữu ích nào về cách tiếp cận vấn đề này không?

Tôi cũng đã làm việc trong những tình huống tương tự và tôi có thể cho bạn lời khuyên sau.

1. Bạn cần giảm nợ kỹ thuật . Hiện nay. Tại sao? Bởi vì nợ kỹ thuật giống như nợ tài chính. Bạn sẽ trả lãi cho nó.
2. Vì việc tái cấu trúc toàn bộ cơ sở mã là không khả thi, hãy tự hỏi: điều gì đang ngăn chặn nó? Nó chỉ đơn giản là quá nhiều công việc? Tại sao?
3. Tạo một kế hoạch để giảm nợ kỹ thuật kịp thời. Ví dụ: bằng cách thiết lập các quy tắc là " mọi bit mã được nhóm chạm vào phải được cố định / tái cấu trúc theo tiêu chuẩn mới ". Thông thường: các bài kiểm tra đơn vị phải được viết, mã phải được di chuyển trong các lớp chính xác, v.v ... Điều này cho phép bạn sửa rất nhiều mã mà không cần dùng đến các dự án "tái cấu trúc" đắt tiền và lố bịch.
4. Bọc crap. Decoupling là chìa khóa để tái cấu trúc và kiến ​​trúc tốt. Nếu bạn có thể phân vùng cơ sở mã bằng cách nào đó, bạn có thể cấu trúc lại các bit nhỏ hơn.
5. Không tăng nợ công nghệ hơn nữa. Không tăng nợ công nghệ hơn nữa. Không tăng nợ công nghệ hơn nữa. Đừng...

Bạn đúng rằng việc tái cấu trúc toàn bộ cơ sở mã là không mong muốn. Tái cấu trúc là điều bạn làm trước sự phát triển mới để làm cho sự phát triển đó suôn sẻ hơn. Nếu bạn không có kế hoạch sửa đổi tất cả mã trong cơ sở mã của mình, thì việc tái cấu trúc sẽ chứng minh việc sử dụng thời gian không hiệu quả.

Một số lời khuyên ngoài những gì Sklivvz nói:

1. Tách mã thành các phần được sửa đổi thường xuyên và không thường xuyên. Chỉ các phần được sửa đổi thường xuyên cần phải được đưa đầy đủ vào kiến ​​trúc mới. Tích hợp mã được sửa đổi không thường xuyên với kiến ​​trúc mới bằng cách sử dụng càng ít thay đổi càng tốt (hoặc không có thay đổi nếu bạn có thể thoát khỏi nó). Chống lại sự cám dỗ của việc viết lại đầy đủ, nó sẽ tốn kém hơn bạn kiếm được từ nó. Đánh giá cao rằng mã hiện có hoạt động, ngay cả khi nó xấu.

2. Tìm hiểu mục tiêu tái cấu trúc của bạn là gì. Bạn có muốn làm cho việc đưa nội dung vào trang web dễ dàng hơn không? Bạn có nhiều lỗi và muốn cải thiện chất lượng cảm nhận của người dùng? Thay vào đó, bạn muốn giảm thời gian phát triển tính năng? Hay bạn chủ yếu muốn một UX tốt hơn? Kiến trúc của bạn sẽ giúp bạn dễ dàng cấu trúc lại mã để đáp ứng các mục tiêu bạn đặt ra. Đừng bao giờ quên rằng người thụ hưởng chính trong việc tái cấu trúc của bạn phải là người dùng / khách hàng / doanh nghiệp của bạn. Bản thân mã sạch hơn không phải là một mục tiêu, nó là một phương pháp để kết thúc và kết thúc liên quan đến người dùng.

3. Cố gắng tìm càng nhiều kiến ​​trúc tham khảo càng tốt và đừng ngại sao chép chúng. Đừng phát minh lại bánh xe. Nếu ai đó có kiến ​​trúc hoạt động tốt cho các trang web như của bạn, hãy học hỏi từ họ.

4. Hãy suy nghĩ về khía cạnh quản lý con người. Trong các dự án di cư của riêng tôi, phần khó nhất là khiến mọi người học theo những cách mới và bám sát chúng. Bạn sẽ cần triển khai tham khảo và cách dạy kiến ​​trúc cho mọi người trong nhóm (cả cũ và mới). Để giảm sức đề kháng với thay đổi, hãy yêu cầu đầu vào từ mọi người trong nhóm trước khi đưa ra quyết định. Hãy chắc chắn rằng thiết kế mới thực sự cải thiện mọi thứ từ quan điểm cá nhân của các nhà phát triển và không phải là một bước nhảy vọt lớn đến mức họ cảm thấy sâu sắc.

Điều quan trọng nhất tôi thấy khi cố gắng xử lý một cơ sở mã cũ là KHÔNG tiếp tục thay đổi những gì bạn đang chụp. Đó là, tìm ra kiến ​​trúc mong muốn của bạn, sau đó DỄ DÀNG VỚI KẾ HOẠCH! Một trong những vấn đề lớn mà vị trí cuối cùng của tôi gặp phải là codebase có một vài ý tưởng khác nhau về việc nó sẽ trông như thế nào theo thời gian. Mỗi khi một ý tưởng mới được thử, một số mã được chuyển đổi, một số thì không, và sau đó một người khác có ý tưởng 'tốt hơn'. Nó ngày càng trở nên không mạch lạc theo thời gian và cuối cùng đã bị loại bỏ.

Có một cuốn sách / pdf miễn phí thực sự tuyệt vời về phần mềm kế thừa tái cấu trúc: http://scg.unibe.ch/doad/oorp/

Nó nói OO trong tiêu đề nhưng hầu hết các ý tưởng áp dụng cho bất kỳ phần mềm nào. Nó thảo luận về nơi bắt đầu, làm thế nào để đối phó với các phần khác nhau của một hệ thống trong quá trình tái cấu trúc và nhiều hơn nữa các chủ đề đó.

Nếu nó không có kiến ​​trúc mạch lạc, đó là vì quản lý không hiểu / quan tâm đến vấn đề. Chỉ cần mã đi. Bạn nên giới thiệu kiến ​​trúc mới tốt khi bạn viết mã mới.

Bạn nên kiến ​​trúc lại mọi thứ chỉ khi chúng bắt đầu có lỗi thực sự nghiêm trọng, bạn cần mở rộng nó và chỉ không thể, hoặc nó không phù hợp với yêu cầu của nó.

Về cơ bản, tôi chỉ nói về những vấn đề mà các nhà quản lý của bạn thực sự quan tâm, chứ không phải những vấn đề họ sẽ quan tâm nếu họ có kiến ​​thức của bạn.

Nếu bạn có thể bán kiến ​​trúc lại cho quản lý, hãy bắt đầu với thử nghiệm. Nếu họ không muốn đầu tư vào thử nghiệm, những nỗ lực của bạn sẽ chỉ khiến bạn gặp rắc rối.