Tôi chắc rằng bạn đã có mặt ở đó, bạn tham gia vào một dự án nơi có một cơ sở mã creaky cũ mà chỉ vừa vặn với mục đích và bạn phải đưa ra quyết định viết lại từ đầu hoặc sửa chữa tồn tại.Viết lại hoặc sửa chữa?
Sự khôn ngoan thông thường có xu hướng gợi ý rằng bạn không nên cố viết lại từ đầu vì rủi ro thất bại rất cao. Vì vậy, bạn đã làm gì khi đối mặt với vấn đề này, làm thế nào bạn đưa ra quyết định và làm thế nào nó đã trở thành?
Nó thực sự phụ thuộc vào mức độ tồi tệ của nó.
Nếu đó là một hệ thống nhỏ, và bạn hoàn toàn hiểu nó, sau đó viết lại không phải là điên.
Mặt khác, nếu đó là một con quái vật thừa kế khổng lồ với mười triệu dòng mã bí ẩn không có giấy tờ, thì bạn sẽ thực sự gặp khó khăn khi viết lại toàn bộ.
điểm cần xem xét:
Tôi thực sự ngần ngại thực hiện một dự án viết lại khổng lồ cho một hệ thống lớn mà không thể phát hành phiên bản mới một phần tại một thời điểm.
Nó không phải như vậy màu đen và trắng ... nó thực sự phụ thuộc vào rất nhiều yếu tố (quan trọng hơn là "những gì hiện người đó trả tiền bạn muốn bạn làm")
Nơi tôi làm việc chúng tôi lại viết một khung phát triển và mặt khác, chúng tôi tiếp tục sửa đổi một số hệ thống cũ không thể di chuyển được (vì công nghệ và hạn chế thời gian của khách hàng). Trong trường hợp này, chúng tôi cố gắng để mantain phong cách mã hóa và đôi khi bạn phải thực hiện rất nhiều cách giải quyết vì cách nó được xây dựng
Refactor trừ khi nó là rất xấu thực sự.
Joel has a lot to say on this...
Ít nhất, viết lại mã với mã cũ trước mặt bạn và không chỉ bắt đầu lại từ đầu. Các mã cũ có thể là khủng khiếp, nhưng nó là cách nó là vì một lý do và nếu bạn bỏ qua nó bạn sẽ kết thúc nhìn thấy các lỗi tương tự mà có lẽ đã được cố định năm trước trong mã cũ.
Xem bài viết của Joel Spolsky Things You Should Never Do. Tóm lại, khi bạn viết lại, bạn sẽ mất tất cả các bài học bạn đã học để làm cho mã hiện tại của bạn hoạt động theo cách cần thiết để hoạt động.
Xem thêm: Big Ball of Mud
Chỉ cần dọn dẹp mã một chút mỗi khi bạn làm việc với nó. Nếu chưa có, hãy thiết lập một khung kiểm thử đơn vị. Tất cả các mã mới sẽ nhận được các bài kiểm tra bằng văn bản. Bất kỳ mã cũ nào bạn sửa chữa là kết quả của lỗi, hãy thử trượt trong các thử nghiệm.
Khi tiến trình dọn dẹp, bạn sẽ có thể quét ngày càng nhiều mã khó chịu vào thùng được đóng gói. Sau đó, bạn có thể chọn từng cái một trong tương lai.
Một công cụ như javadoc hoặc doxygen, nếu chưa được sử dụng, cũng có thể giúp cải thiện tài liệu mã và tính toàn diện.
Các đối số chống viết lại hoàn toàn khá mạnh. Những tấn "lỗi nhỏ" và hành vi được mã hóa trong khung thời gian của dự án ban đầu sẽ lẻn vào lại một lần nữa.
Một lý do để viết lại một trong các công việc trước đây của tôi là không thể tìm thấy nhà phát triển có đủ kinh nghiệm để làm việc trên cơ sở mã gốc.
Quyết định được đưa ra trước tiên để làm sạch cấu trúc cơ sở dữ liệu cơ bản, sau đó viết lại vào thứ gì đó sẽ giúp tìm nhân viên và/hoặc nhà thầu toàn thời gian dễ dàng hơn.
Tôi chưa từng nghe nhưng làm thế nào nó làm việc ra :)
Tôi nghĩ mọi người có xu hướng đi cho viết lại vì nó có vẻ vui hơn trên bề mặt.
Chúng tôi sẽ xây dựng lại từ đầu!
Chúng tôi sẽ làm điều đó ngay thời gian này!
vv
Rất hiếm khi viết lại bất kỳ điều gì phức tạp để thành công. Đó là hấp dẫn, nhưng một chiến lược tỷ lệ phần trăm thấp.
Lấy mã kế thừa dưới các thử nghiệm đơn vị và cấu trúc lại nó, và/hoặc thay thế hoàn toàn các phần nhỏ của nó tăng dần khi có cơ hội.
Có sách mới sắp ra, Brownfield Application Development in .NET bởi Baley và Belcham. Chương đầu tiên là miễn phí, và nói về những vấn đề này từ một quan điểm chủ yếu là nền tảng thuyết bất khả tri.
Tùy thuộc vào trường hợp của bạn, bạn có thể có tùy chọn khác: mã bên thứ ba trong giấy phép.
Tôi đã tham khảo ý kiến tại một số công ty mà đó sẽ là lựa chọn hợp lý, mặc dù dường như "bỏ IP" có thể là rào cản lớn đối với việc quản lý. Tại công ty hiện tại của tôi, chúng tôi đã xem xét nghiêm túc tùy chọn sử dụng mã của bên thứ ba để thay thế khung cốt lõi của chúng tôi, nhưng ý tưởng đó cuối cùng bị từ chối vì lý do kinh doanh hơn là lý do kỹ thuật.
Để trả lời trực tiếp câu hỏi của bạn, cuối cùng chúng tôi đã chọn viết lại khung cũ - quyết định mà chúng tôi đã không đưa ra một cách nhẹ nhàng! 14 tháng sau, chúng tôi không hối tiếc sự lựa chọn này. Chỉ cần xem xét thời gian dành cho việc sửa lỗi, khung công tác mới của chúng tôi gần như đã tự trả tiền. Về mặt tiêu cực, nó không hoàn toàn đầy đủ tính năng, vì vậy chúng tôi đang ở trong vị trí không thể phủ nhận của việc duy trì hai khung riêng biệt song song cho đến khi chúng tôi có thể chuyển đổi ứng dụng "front-end" cuối cùng của mình.
Tôi đặc biệt khuyên bạn nên đọc "Làm việc hiệu quả với Mã kế thừa" của Michael Feathers.Đó là lời khuyên huấn luyện về cách cấu trúc lại mã của bạn để nó có thể kiểm thử được.
Sửa chữa hoặc quan trọng hơn là refactor. Cả hai vì Joel said so và cũng vì, nếu đó là mã của bạn, bạn có thể đã học được nhiều thứ hơn kể từ khi bạn chạm vào mã này trước. Nếu bạn đã viết nó trong .NET 1.1, bạn có thể nâng cấp nó lên 3.5 SP1. Bạn có thể đi vào và thanh lọc tất cả các mã nhận xét cũ. Bạn hiện tốt hơn 100 lần so với nhà phát triển so với lần đầu tiên bạn viết mã này.
Một ngoại lệ mà tôi nghĩ là khi mã sử dụng công nghệ thực sự cổ - trong trường hợp đó bạn có thể được phục vụ tốt hơn bằng cách viết phiên bản mới. Nếu bạn đang xem xét một số ứng dụng VB6 với 10.000 dòng mã với phần phụ trợ cơ sở dữ liệu Access được thiết lập bởi một người không biết nhiều về cơ sở dữ liệu hoạt động như thế nào (có thể là bạn 8 năm trước) thì bạn có thể kéo một giải pháp dựa trên C#/SQL nhanh hơn trong một phần nhỏ thời gian và mã.
Đường phân chia giữa chỉ xấu và rất xấu ở đâu? –