Cách tiếp cận tốt để làm sạch các dự án cũ là gì?


11

Tôi đã có một số phần mềm mà tôi đã viết khoảng 2 năm trước và cần một số tính năng được thêm vào phần mềm. Tôi đã nhận ra rằng đó là một mớ hỗn độn khủng khiếp và tôi có mong muốn di chuyển mọi thứ xung quanh, dọn dẹp, v.v. Tôi đã đọc bài viết Joel trên Phần mềm về việc không bắt đầu lại , vậy cách nào tốt nhất về phía trước?


Những quyết định từ sau đó bạn không đồng ý với ngày hôm nay?

Câu trả lời:


21

Bạn có ba tùy chọn cơ bản:

  1. Nếu ứng dụng rất nhỏlộn xộn thực sự , bắt đầu lại có thể là lựa chọn tốt nhất của bạn.

  2. Tái cấu trúc .

  3. Sống với mớ hỗn độn và hack trong các tính năng bổ sung.

Thông thường, tùy chọn (2) là đặt cược tốt nhất của bạn.

Bao nhiêu tái cấu trúc bạn thực sự làm sẽ phụ thuộc vào tài nguyên bạn đặt vào so với giá trị bạn nhận được. Các câu hỏi sẽ bao gồm:

  1. Thời gian / ngân sách có sẵn?
  2. Bạn dự đoán bao nhiêu sửa đổi trong tương lai?
  3. Ai khác sẽ thấy mã? (tức là mã lộn xộn sẽ làm tổn hại danh tiếng của bạn?)
  4. Có ai khác dự kiến ​​sẽ duy trì mã?
  5. Những công cụ tái cấu trúc có sẵn để giúp bạn?
  6. Kinh nghiệm của bạn về tái cấu trúc là gì?
  7. Bạn sẽ có được kinh nghiệm gì từ việc tái cấu trúc?
  8. Những loại tái cấu trúc sẽ cung cấp cho bạn những lợi ích nhất?
  9. Những bài kiểm tra tự động đã tồn tại? Cần phải được viết?
  10. Bao nhiêu thử nghiệm thủ công sẽ được yêu cầu?
  11. Bạn sẽ cảm thấy thế nào nếu bạn để lại mã như vậy?

Theo kinh nghiệm của tôi, rất dễ dàng để đi vào vũng bùn thích hợp trong một phiên tái cấu trúc. Những bài học quan trọng nhất mà tôi đã học được là:

  1. Làm một việc tại một thời điểm.
  2. Thực hiện các bước nhỏ.
  3. Sử dụng tốt kiểm soát nguồn của bạn (kiểm tra thường xuyên + bao gồm các bình luận).
  4. Sử dụng các công cụ tái cấu trúc tự động.
  5. Biết IDE.

6
Tôi cũng muốn thêm vào để tránh tình trạng bị hỏng quá lâu. Tôi đã thấy nhiều dự án nguồn mở nhanh chóng chết trong quá trình viết lại / thiết kế lại đầy tham vọng. Một dự án phi chức năng giết chết động lực nhanh chóng.
LennyProgrammer

2
Chắc chắn rồi. Liên quan đến việc viết lại / thiết kế đầy tham vọng, tôi đã phạm lỗi này nhiều lần. Bây giờ, tôi cố gắng thực hiện mọi thứ trong các bước nhỏ hơn. Tôi đã thêm gợi ý này vào câu trả lời của mình.
Kramii

Tôi cũng nói thêm rằng bạn không nên cấu trúc lại bất cứ thứ gì không có bài kiểm tra viết cho nó. Chống lại sự thôi thúc sửa chữa mọi thứ và chỉ tập trung vào các khu vực cần thay đổi để thêm các tính năng mới. Một khi bạn đã hoàn thành, sau đó quyết định bạn muốn bỏ thêm bao nhiêu nỗ lực để tái cấu trúc phần còn lại.
TMN

1
@TMN: Lý tưởng nhất là có. Tuy nhiên, bạn không phải lúc nào cũng cần kiểm tra tự động. (1) Nếu mã được phát triển mà không có kiểm tra tự động thì có thể không dễ / có thể kiểm tra đơn vị phù hợp với retro cho đến khi bạn đã thực hiện một số phép tái cấu trúc (2) Có thể tốn kém khi viết thử nghiệm trước khi thực hiện các thay đổi nhỏ, cục bộ. (3) Các công cụ tái cấu trúc tự động + Các tính năng IDE có thể giúp ngăn chặn việc phá mã do tái cấu trúc.
Kramii

2
Tôi đã thêm - trong kiểm soát nguồn của bạn, đặt tất cả các cấu trúc lại trên một CHI NHÁNH riêng. Điều này giúp thực hiện một bước hợp lý cũng như so sánh khối lớn. Điều này có thể là vô giá nếu mọi thứ chuyển sang sữa trứng (MÀ HỌ S)).
quick_now

5

Chà, ít nhất là tái cấu trúc đủ để tính năng mới có thể được thêm một cách an toàn. Tức là đừng làm nó tệ hơn nữa. Phần còn lại phụ thuộc vào động lực, ngân sách và thời gian hạn chế - nhưng lưu ý rằng việc dọn dẹp hoàn toàn một mớ hỗn độn có thể mất nhiều thời gian hơn so với việc tạo ra nó.


1
Tất nhiên đây là Quy tắc Boyscout nổi tiếng: luôn để mã ở trạng thái tốt hơn bạn tìm thấy.
Jörg W Mittag

2

Lần này trong khi sửa chữa những điều chắc chắn để ghi lại nó. Lần sau bạn sẽ thấy mã sẽ dễ dàng hơn nhiều để nhớ lại mọi thứ.


1

Nó phụ thuộc vào việc nó sẽ tốn nhiều thời gian hơn để duy trì nó bởi vì nó là một mớ hỗn độn, hoặc viết lại nó để nó không phải là một mớ hỗn độn và dễ dàng bảo trì. Cá nhân tôi đang thực hiện điều này ngay bây giờ, tôi đang chuyển đổi một trang web mạng nội bộ sang ASP.Net MVC3 vì mã cũ là một đống tào lao (mà tôi đã viết) vì nó được cho là dùng một lần (vâng, tôi nên biết rõ hơn ). Một đống rác cũ vẫn còn ở đây, và thật đau đầu khi thêm các tính năng và sửa lỗi. MVC rất đẹp và làm cho nó thực sự dễ chịu, vì vậy nó sẽ được viết lại.

Khi sử dụng trang web của chúng tôi, bạn xác nhận rằng bạn đã đọc và hiểu Chính sách cookieChính sách bảo mật của chúng tôi.
Licensed under cc by-sa 3.0 with attribution required.