Tôi muốn hỏi bạn một số câu hỏi về mã bẩn. Có một số người mới bắt đầu mã hóa trên một dự án vừa. Mã là một quả bóng bùn rất lớn. Họ không phải là những lập trình viên tiên tiến. Họ chỉ biết sử dụng bàn phím một chút về java. Họ chỉ viết mã với 12 000 dòng trong lớp chính của họ, tuy nhiên, 6 000 dòng thuộc về chính NetBeans.

Công việc của tôi là phân tích mã và đề xuất một cách tốt để duy trì mã. Ý tưởng của tôi là loại bỏ dự án và bắt đầu một dự án mới với phương pháp OOP. Gần đây tôi đã thu thập một số ghi chú và ý tưởng về vấn đề này, từ trang web này và một số người khác.

Bây giờ, tôi có các câu hỏi sau:

1. Chúng ta có nên sửa mã và đổi nó thành OOP không? Chúng tôi đang gỡ lỗi nó.
2. Mã này không có ý kiến, không có tài liệu, không có phong cách lập trình cụ thể, v.v. Thay đổi nó thực sự tốn kém và mất thời gian. Chúng ta có thể làm gì về điều này?
3. Làm cách nào tôi có thể dạy họ tuân theo tất cả các quy tắc (nhận xét, OOP, chất lượng mã tốt, v.v.)?
4. Mã bị lỗi và dễ bị lỗi. Chúng ta có thể làm gì? Kiểm tra? Chúng tôi gần như viết hai hoặc ba bài báo A4 để sửa, nhưng dường như là vô tận.

Tôi phải nói rằng tôi là người mới với họ. Tôi nghĩ rằng tôi cũng đã phá vỡ các quy tắc về việc thêm người quá muộn vào dự án. Bạn có nghĩ rằng tôi phải rời bỏ họ?

Bước 0: Sao lưu vào SCM

Bởi vì, như được gợi ý bởi JBRWilkinson trong các bình luận, kiểm soát phiên bản là tuyến phòng thủ đầu tiên của bạn chống lại thảm họa (không thể đảo ngược).

Cũng sao lưu chi tiết cấu hình phần mềm, quy trình để tạo phân phối, v.v ...

Bước 1: Kiểm tra đầu tiên

Sau đó bắt đầu bằng cách viết bài kiểm tra :

• cho những gì hoạt động,
• và cho những gì thất bại.

Bất kể bạn quyết định làm gì, bạn đều được bảo vệ. Bây giờ bạn có thể:

• bắt đầu từ đầu và viết lại ,
• hoặc sửa nó.

Lời khuyên của tôi sẽ là bắt đầu kiến ​​trúc chung từ đầu , nhưng trích xuất từ mớ hỗn độn các bộ phận xác nhận điểm kiểm tra và cấu trúc lại những thứ này khi bạn thấy phù hợp.

Bước 2: Xác minh và giám sát

Thiết lập hệ thống Tích hợp liên tục (để bổ sung cho bước 0 và bước 1 ) VÀ hệ thống Kiểm tra liên tục (để chuẩn bị cho bước 4 ).

Bước 3: Đứng trên vai người khổng lồ

(như bạn luôn luôn nên ...)

• Tái cấu trúc các mẫu
• Tái cấu trúc: Cải thiện thiết kế mã hiện có .
• Hoạt động hiệu quả với Bộ luật kế thừa (theo khuyến nghị của Jason Baker )
• Tái cấu trúc

Bước 4: Làm sạch

Việc đó không cần phải nói, nhưng thay vì đọc lướt qua mã, bạn có thể chỉ muốn chạy linters / phân tích tĩnh và các công cụ khác trên cơ sở mã bị hỏng để tìm lỗi trong thiết kế và khi triển khai.

Sau đó, bạn cũng có thể muốn chạy một trình định dạng mã, điều đó sẽ giúp một chút với việc dọn phòng.

Bước 5: Xem lại

Thật dễ dàng để giới thiệu các lỗi nhỏ bằng cách tái cấu trúc hoặc dọn dẹp mọi thứ. Nó chỉ có một lựa chọn sai và nhấn nhanh vào một phím, và bạn có thể xóa một cái gì đó khá quan trọng mà không nhận ra lúc đầu. Và đôi khi hiệu ứng sẽ xuất hiện chỉ vài tháng sau đó. Tất nhiên, các bước trên giúp bạn tránh điều này (đặc biệt là bằng cách triển khai khai thác thử nghiệm mạnh), nhưng bạn không bao giờ biết những gì có thể và sẽ vượt qua. Vì vậy, hãy đảm bảo rằng các phép tái cấu trúc của bạn được xem xét bởi ít nhất một cặp bóng mắt chuyên dụng khác (và tốt nhất là nhiều hơn thế).

Bước 6: Chứng minh tương lai Quy trình phát triển của bạn

Lấy tất cả những điều trên và biến nó thành một phần vốn có của quá trình phát triển thông thường của bạn, nếu nó chưa có. Đừng để điều này xảy ra một lần nữa trên đồng hồ của bạn và cùng với nhóm của bạn thực hiện các biện pháp bảo vệ trong quy trình của bạn và thực thi điều này (nếu điều đó thậm chí có thể) trong chính sách của bạn. Làm cho sản xuất Mã sạch là một ưu tiên.

Nhưng thực sự, thử nghiệm . Rất nhiều .

Cá nhân, tôi sẽ không bắt đầu dự án này cho đến khi tôi có một bản sao Làm việc hiệu quả với Legacy Code tiện dụng. Nghiêm túc mà nói, nó được viết cho chính xác loại điều này. Nó có đầy đủ các chiến lược để xử lý mã phức tạp và đi sâu vào chi tiết hơn nhiều so với những gì tôi có thể cung cấp cho bạn ở đây.

Tôi đã ở đó nhiều lần. Quy tắc của tôi là: nếu phần mềm không tầm thường (hơn 1 tuần làm việc cho tài nguyên bạn có) và nó hoạt động, thì hãy giữ nó và tiến hành tái cấu trúc gia tăng.

Nếu phần mềm không thực sự hoạt động (số lượng lỗi rất cao, yêu cầu không rõ ràng, v.v.) thì tốt hơn là nên viết lại từ đầu. Tương tự nếu nó khá nhỏ.

Điểm quan trọng trong việc tái cấu trúc (như trong cuốn sách của Fowler và của http://www.ievustriallogic.com/xp/refactoring/ ) là nó giữ cho hệ thống hoạt động, có thể việc tái cấu trúc sẽ mất gấp đôi thời gian nhưng rủi ro là bằng không.

Viết lại từ đầu có thể đưa ra nhiều rủi ro, từ yêu cầu hiểu sai đến thực hiện sai (sau khi tất cả các nhóm sẽ giống nhau).

Tôi thực sự đã thấy một thủ tục phức tạp được viết lại từ đầu hai lần và vẫn không hoạt động như mong đợi.

Tôi sẽ viết lại nó hoàn toàn. Đôi khi không thể sửa chữa một mã như vậy. Một lựa chọn khác là làm cho nó hoạt động, mà không cần thêm bất kỳ tính năng mới nào. Để dạy nhóm viết mã tốt (được thiết kế tốt, ghi lại, với các bài kiểm tra) hãy để họ sửa mã mà bạn có bây giờ. Hãy để mọi người sửa lỗi / xem lại mã của các nhà phát triển khác, không phải phần của anh ấy / anh ấy. Sau một số lần thử, họ sẽ hiểu rằng gần như không thể xem lại / sửa các mã đó.

Thêm người vào các dự án muộn giúp rất hiếm khi. Thông thường nó phá vỡ thời hạn. Bạn nên làm mọi thứ có thể để hoàn thành dự án thành công, và sau đó suy nghĩ về việc rời đi.

Lời khuyên của tôi sẽ không loại bỏ toàn bộ mã. Đây là vấn đề cuộc sống hàng ngày, mọi nhóm phát triển phải đối mặt. Tấn công một phần của mã tại một thời điểm. Sửa chữa nó, làm sạch nó, tài liệu nó. Và sau đó chuyển sang phần khác. Điều chính là luôn giữ một số mã có thể vận chuyển trong tay. Viết lại toàn bộ mã từ đầu sẽ mất khoảng thời gian đã sử dụng cho đến bây giờ và sẽ không có gì đảm bảo rằng nó sẽ đẹp hơn hiện tại.
Nhưng sau đó mọi người cũng nên tránh viết mã theo cách này. Dành thêm thời gian để đánh giá mã. Thích nghi với một số phong cách mã hóa thống nhất. Thảo luận về thiết kế đầu tiên và sau đó viết mã. Những điều đơn giản như vậy sẽ tạo ra những thay đổi lớn.

Blog hay nói lý do tại sao Netscape lỏng lẻo

Nếu nó hoạt động, tái cấu trúc nó. Có những công cụ giúp bạn làm điều đó. Nếu nó không hoạt động, hãy sử dụng lệnh cải thiện mã ma thuật, tức là deltreetrên Windows resp. rm -rftrên Linux.

Chúng ta có nên sửa mã và đổi nó thành OOP không? Chúng tôi đang gỡ lỗi nó. [... Chứa lỗi, không có tài liệu ...]

Tôi đã từng ở đó, bạn có cảm tình của tôi. Tôi thậm chí đã viết một bài báo về điều này có thể giúp bạn có được một số quan điểm. Nhưng tóm lại:

Nếu mã chứa nhiều bản sao, bạn nên viết lại. Nếu không có cấu trúc rõ ràng (không có giao diện rõ ràng, spaghetti), tái cấu trúc sẽ thất bại và có lẽ bạn nên viết lại.

Làm thế nào tôi có thể dạy họ tuân theo tất cả các quy tắc?

Bắt đầu với việc giải thích lý do tại sao họ có thể muốn làm điều đó bằng cách cho họ thấy những gì họ có thể nhận được từ cá nhân. Khi họ đồng ý với điều này và sẵn sàng học hỏi, hãy bắt đầu dạy họ bằng cách sử dụng shuhari .

Đề xuất của tôi là sự kết hợp giữa câu trả lời của @ duros & @Manoj R.

Bắt đầu từ đầu, hãy ghi nhớ để tạo mã tốt / OOP / nhận xét / vv lần này, tham khảo / sao chép và dán từ mã cũ của bạn. Khi bạn gặp các phần xấu của mã cũ, hãy viết lại / cấu trúc lại chúng.

Nếu các nhà phát triển của bạn không được đào tạo tốt, tôi nghĩ thật tốt khi gửi cho họ các khóa học. Nó quan trọng để đào tạo lại thường xuyên trong ngành công nghiệp CNTT thay đổi nhanh chóng