Tôi nên hỏi những câu hỏi nào khi cố gắng xác định xem một hệ thống có nên được tái phát triển không?

Question

Tôi đã tham gia vào việc đánh giá xem một số hệ thống của chúng tôi có cần phải được viết lại từ đầu hoặc nếu chúng được viết lại một phần hoặc nếu chúng chỉ tiếp tục với các bản vá ở trên cùng.

Để đánh giá tình hình tốt hơn, tôi đã tự hỏi mình nên hỏi những câu hỏi nào và hỏi người khác giúp xác định hành động thích hợp để thực hiện?

Answer 1

Nói chung, tôi thấy rằng viết lại mã có xu hướng gây rắc rối (tốn kém, tốn thời gian và liên quan đến giai đoạn khám phá làm cho hệ thống đầu tiên trông đẹp hơn).

Điều đó nói rằng, đây là một vài câu hỏi để hỏi:

1. Would lõi refactoring đủ? Bạn sẽ biết từ việc đánh giá hệ thống liệu các vấn đề trung tâm có đi sâu hơn mã hay không. Nếu các vấn đề nằm trong cơ sở mã (thay vì bản thân công nghệ), tôi thích tái cấu trúc lại.

2. Hệ thống hiện tại có thể kiểm tra ở mức độ nào?Khả năng kiểm tra đi một chặng đường dài để mở rộng tuổi thọ của bất kỳ mô-đun hệ thống nào vì mã có thể thử nghiệm thường dễ dàng hơn để mở rộng và bảo trì. Điều này cũng liên quan đến # 1.

3. Cuối cùng, giá trị được cung cấp từ viết lại có biện minh cho nỗ lực không. Đây là một câu hỏi kinh doanh, chắc chắn, nhưng một câu hỏi mà nhà phát triển có thể và nên giúp đỡ.

Trong hầu hết các trường hợp tôi gặp phải, câu trả lời là không.

Answer 2

Tôi khuyên bạn nên đọc Things You Should Never Do, Part I. Anh ta tạo ra một trường hợp mạnh mẽ để không tái phát triển.

quote Money:

Điều quan trọng là phải nhớ rằng khi bạn bắt đầu từ đầu hoàn toàn không có lý do để tin rằng bạn sẽ làm một công việc tốt hơn bạn đã làm lần đầu tiên. Trước hết, bạn có thể thậm chí không có cùng một nhóm lập trình làm việc trên phiên bản một, vì vậy bạn không thực sự có "kinh nghiệm nhiều hơn". Bạn sẽ chỉ làm cho hầu hết các lỗi cũ một lần nữa, và giới thiệu một số vấn đề mới mà không có trong phiên bản gốc.

Có lẽ bạn nên tự hỏi mình nếu bạn biết hệ thống đủ tốt để khắc phục sự cố mà không cần phải viết lại. Nếu không, có thể nói rằng bạn không biết hệ thống đủ tốt để phát triển lại từ đầu.

Answer 3

theo thứ tự sau:

• nó thực hiện công việc một cách chính xác?
• có nhanh không?
• có dễ bảo trì không?
• có dễ dàng mở rộng không?

Answer 4

Cuối cùng bạn muốn đạt được điều gì đó bất cứ khi nào bạn viết lại hệ thống từ đầu. Bạn nên tự hỏi mình muốn đạt được điều gì? Bạn có muốn:

• Giảm nguy cơ của một hệ thống xây dựng với công nghệ cũ
• Giảm chi phí: quá tốn kém để duy trì
• ?

Bạn có thể thực hiện phân tích hòa vốn để xem khi nào hệ thống mới của bạn bắt đầu thanh toán. Theo tôi, bạn sẽ có thể giảm viết lại hệ thống về chi phí và có thể thấy rằng một cái mới có giá thấp hơn cái cũ.

Answer 5

1. Bạn sẽ không thể giao hàng trong bao lâu? Bao nhiêu thời gian Bạn đã đánh giá thấp những yếu tố nào trước đây? Bao nhiêu thời gian bạn có thể đủ khả năng trong trường hợp xấu nhất?

2. Số lượng nhân lực hiện đang chuyển thành duy trì hệ thống hiện tại? Bạn có nhân lực này có sẵn ngoài cho những người phát triển hệ thống mới không?

3. Làm cách nào để đảm bảo bạn không tạo lại cùng một hệ thống với cùng một vấn đề? Tránh các lỗi kiến ​​trúc rõ ràng thường không đủ.

4. Bạn có thể cạnh tranh/tồn tại nếu bạn không có tài nguyên để cải thiện hệ thống hiện tại không?

---

Thậm chí nếu "Refactor và Sửa chữa" có nghĩa là, về lâu dài, thay thế hầu hết các hệ thống hiện có, nó có nghĩa là đặt tất cả ressources vào một hệ thống, chứ không phải là hai.

Answer 6

Tôi đề nghị bạn cần một ngữ cảnh cho cuộc thảo luận, và điều tốt nhất tôi quen thuộc được tìm thấy trong cuốn sách "Tái cấu trúc" của Martin Fowler. Đối với tôi câu hỏi thực sự là "Ứng dụng này có thể tái cấu trúc được không?"

Nguyên tắc cụ thể đầu tiên sẽ là "Được viết bằng nguyên tắc thiết kế OO tốt?" Nếu không, thông thường bạn cần phải đặt nó vào hỗ trợ cuộc sống, và/hoặc bắt đầu lại. Nếu có, thì cuốn sách sẽ cung cấp rất nhiều trợ giúp; và trong kinh nghiệm của tôi có lý do tốt cho hy vọng.