Bạn có nên cấu trúc lại mã hiện tại không bị phá vỡ trong một dự án tập trung vào các tính năng mới không?

Đưa ra một dự án nhỏ nhằm mục đích thêm chức năng mới vào ứng dụng, những thay đổi được giới thiệu chạm đến một số mã hiện có, liên quan đến việc cập nhật những điều này trong một số lĩnh vực nhất định. Trong quá trình thực hiện, tôi đã tìm thấy một số mã được cập nhật có các ứng cử viên để tái cấu trúc.

Đây có phải là thời điểm thích hợp để tái cấu trúc, do đó sẽ yêu cầu kiểm tra hồi quy cho các thành phần bị ảnh hưởng (do đó có thể giới thiệu phạm vi ban đầu không phải là một phần của dự án)? Hoặc tôi nên trì hoãn, hoàn thành chức năng và có thể có một dự án riêng để tái cấu trúc (mặc dù tôi hơi do dự vì người dùng doanh nghiệp có thể không tài trợ đầy đủ cho một dự án không thêm bất kỳ chức năng nào, trừ khi họ coi trọng khả năng duy trì mã ...)?

Chắc chắn rồi.

Tái cấu trúc nên được thực hiện trong một dự án làm việc và "vượt qua". Khi tất cả các thử nghiệm của bạn (ở cấp độ đơn vị, hệ thống và chấp nhận) vượt qua, bạn biết rằng sản phẩm của bạn đáp ứng yêu cầu. Khi bạn tái cấu trúc, bạn có thể tiếp tục xác nhận rằng tất cả các bài kiểm tra tiếp tục vượt qua. Nếu bất kỳ bài kiểm tra nào bắt đầu thất bại, thì bạn đã làm sai và cần phải sửa nó. Nếu bạn có các bài kiểm tra thất bại, bạn nên sửa chúng trước khi tái cấu trúc để bạn luôn có thể đảm bảo việc tái cấu trúc của bạn không làm thay đổi chức năng của hệ thống.

Đây cũng là thời điểm hoàn hảo để tái cấu trúc, giả sử bạn có thời gian và nguồn lực để thực hiện tái cấu trúc và vẫn giao hàng đúng thời gian và ngân sách. Tái cấu trúc bây giờ sẽ giúp bạn dễ hiểu và bảo trì hệ thống của mình hơn, vì vậy khi bạn thêm nhiều tính năng mới hơn, nó sẽ trở nên dễ dàng hơn. Bạn cần phải chiến đấu chống lại sự thối mã và entropy phần mềm .

Như Joel Etherton chỉ ra trong các bình luận, bạn cần quản lý phạm vi tái cấu trúc. Tập trung vào tái cấu trúc các bộ phận của hệ thống mà bạn sẽ sớm thêm các tính năng vào, thực hiện các phép tái cấu trúc sẽ giúp làm việc dễ dàng hơn hoặc thêm các tính năng mới. Việc sử dụng phân tích tĩnh, công cụ số liệu và đánh giá mã có thể giúp bạn xác định các khu vực quan trọng nhất. Bạn không muốn bỏ lỡ thời hạn vì bạn đã tái cấu trúc - bạn vẫn cần tiếp tục gia tăng giá trị cho khách hàng.

Bạn đề cập đến khách hàng không thấy giá trị trong tái cấu trúc. Thông thường, khách hàng không quan tâm đến chất lượng của mã, nhưng về sản phẩm. Tái cấu trúc sẽ giúp bạn dễ dàng duy trì chất lượng sản phẩm cao và tiếp tục cung cấp một sản phẩm đáp ứng nhu cầu thay đổi của khách hàng. Hãy cố gắng thương lượng thời gian để tái cấu trúc lịch biểu của bạn (khách hàng muốn các tính năng X trong Y ngày, thử xem bạn không thể có các tính năng Y + Z ngày hay XN để bạn có thể dành thời gian cho thiết kế, tái cấu trúc và triển khai), nếu bạn có thể.

Hãy xem xét việc trả lời các câu hỏi dưới đây, sau đó bạn sẽ dễ dàng đưa ra quyết định. Sự khôn ngoan "đừng sửa nó nếu nó không bị hỏng" rất hấp dẫn nhưng không phải lúc nào cũng đúng với công việc chuyên môn.

0-Có khiếu nại của khách hàng về mã này không?

1-Điều này có cần thiết cho chức năng của ứng dụng không

2-Mã hiện tại có hại không?

3-Chi phí thay đổi có đáng không?

4-Bạn có đủ khả năng chi trả?

5-Đây có phải là cách sử dụng tốt nhất các kỹ năng của bạn cho tổ chức

6-Các thay đổi của bạn có yêu cầu người dùng của bạn cài đặt lại thay đổi mới không - Bạn có thể biện minh điều đó cho khách hàng không?

7-Bạn có thể chịu đựng được rủi ro của một sửa chữa xấu?

8-Thay đổi có ảnh hưởng đến mã khác ngoài dự án của bạn không?

9-Đây là một sản phẩm đang phát triển hay một sản phẩm ổn định? Nếu nó đang phát triển, bạn có thể bao gồm các thay đổi với bản phát hành tiếp theo không?

Tái cấu trúc sớm, tái cấu trúc thường xuyên.

Nếu bạn có đủ khả năng (thời gian, tiền bạc, v.v.) bạn nên làm điều đó.

Tôi nói điều này bởi vì đôi khi bạn có thể hết thời gian, hoặc như bạn nói không nhận được tiền để can thiệp bảo trì mã, hoặc bạn muốn hoàn thành dự án của mình càng sớm càng tốt, và nói chung là vì tái cấu trúc cần tài nguyên. Nhưng ngoài ra, đó luôn là thời điểm tốt để tái cấu trúc.

Bạn muốn một mã cập nhật và nếu bạn cảm thấy rằng mã của bạn thực sự cần một số thay đổi, đặc biệt là khi thêm các chức năng mới, thì bạn nên thay đổi nó.

Đừng quên với một hệ thống kiểm soát phiên bản, bạn thực sự có thể chia dự án của mình thành một nhánh mới, vì vậy bạn hoàn toàn không ảnh hưởng đến mã hiện tại của mình.

Nếu việc tái cấu trúc là cần thiết để thực hiện chức năng mới thì nó nên được thực hiện và là một phần của sự phát triển mới.

Có mã trùng lặp sẽ khiến bạn (cả cá nhân bạn và công ty) mất nhiều thời gian hơn vì các chỉnh sửa được thực hiện ở một nơi chứ không phải ở nơi khác.

Bạn cần phải có một bộ kiểm tra - kiểm tra đơn vị tự động hoặc kiểm tra hồi quy mà bạn có thể chạy để chứng minh rằng bạn chưa đưa ra các vấn đề cho chức năng hiện có.

Nếu việc tái cấu trúc chỉ là "tốt để làm" - tức là nó không bị ảnh hưởng trực tiếp bởi chức năng mới thì tôi sẽ để nó một mình. Bạn đang giới thiệu một sự thay đổi vì lợi ích của sự thay đổi.

Nghe có vẻ như tái cấu trúc mã sẽ giúp việc thêm các tính năng mới dễ dàng hơn; đó là lý thuyết. Bao gồm điều này trong phạm vi của các tính năng mới. Bạn có nhiều khả năng nhận được mua từ người dùng doanh nghiệp theo cách này. Trong trường hợp này, bạn sẽ có thể đưa ra một cuộc tranh luận bắt buộc và biện minh cho thời gian để tái cấu trúc. Hy vọng rằng họ sẽ hiểu rằng đây là một phần cần thiết của quá trình phát triển và sẽ có ít sự phản đối hơn. Bạn có thể không phải lúc nào cũng có thể chứng minh lợi ích trực tiếp này.