Tái cấu trúc tác động thấp và làm sạch mã của mã cẩu thả trong khi chờ yêu cầu

Tôi đã thừa hưởng một cơ sở mã hiện có cho một sản phẩm cẩu thả một cách đáng trách. Thiết kế cơ bản là không đủ, điều không may là tôi không thể làm được gì nếu không có bộ tái cấu trúc hoàn chỉnh (khớp nối CAO, độ kết dính THẤP, sao chép mã tràn lan, không có tài liệu thiết kế kỹ thuật, kiểm tra tích hợp thay vì kiểm tra đơn vị). Sản phẩm này có lịch sử, tiếp xúc nhiều với các khách hàng "tiền mặt" quan trọng với khả năng chịu rủi ro tối thiểu, nợ kỹ thuật sẽ khiến người Hy Lạp đỏ mặt, mã hóa RẤT lớn và phức tạp, và cách tiếp cận thất bại trong trận chiến với các lỗi của đội trước tôi.

Đội cũ nhảy tàu sang một bộ phận khác để họ có cơ hội phá hỏng một dự án khác. Rất hiếm khi tôi gặp phải Thất bại trong Dự án Không đủ kỹ thuật trái ngược với Thất bại trong Quản lý Dự án nhưng đây thực sự là một trong những trường hợp đó.

Hiện tại tôi chỉ có một mình nhưng tôi có rất nhiều thời gian, tự do quyết định và định hướng trong tương lai và khả năng xây dựng một đội ngũ từ đầu để giúp tôi.

Câu hỏi của tôi là thu thập ý kiến ​​về tái cấu trúc tác động thấp đối với một dự án như thế này khi bạn có thời gian rảnh trong giai đoạn thu thập các yêu cầu chức năng. Có hàng ngàn cảnh báo về trình biên dịch, hầu hết tất cả chúng đều không được sử dụng, các biến cục bộ chưa đọc, không có kiểm tra kiểu và phôi không an toàn. Định dạng mã rất khó đọc và cẩu thả đến nỗi có vẻ như người viết mã bị mắc bệnh Parkinsons và không thể kiểm soát số lần thanh không gian được nhấn trên bất kỳ dòng nào. Các tài nguyên tệp và cơ sở dữ liệu khác thường được mở và không bao giờ đóng một cách an toàn. Đối số phương thức vô nghĩa, phương thức trùng lặp làm cùng một việc, v.v.

Trong khi tôi chờ đợi các yêu cầu cho tính năng tiếp theo, tôi đã làm sạch những thứ có rủi ro thấp có tác động thấp khi tôi đi và tự hỏi liệu tôi có đang lãng phí thời gian hay làm việc đúng đắn hay không. Điều gì xảy ra nếu tính năng mới có nghĩa là trích xuất mã mà tôi đã dành thời gian trước đó? Tôi sẽ bắt đầu một cách tiếp cận Agile và tôi hiểu điều này có thể chấp nhận được và bình thường để liên tục tái cấu trúc trong quá trình phát triển Agile.

Bạn có thể nghĩ về bất kỳ tác động tích cực hoặc tiêu cực nào của tôi khi làm điều này mà bạn muốn thêm không?

Trước tiên tôi muốn chỉ ra rằng các bài kiểm tra đơn vị không phải là sự thay thế cho các bài kiểm tra tích hợp. Hai cần phải tồn tại cạnh nhau. Hãy biết ơn vì bạn đã có các bài kiểm tra tích hợp, nếu không, một trong những phép tái cấu trúc nhỏ của bạn cũng có thể khiến một trong những con bò tiền mặt có khả năng chịu đựng thấp đi theo bạn.

Tôi sẽ bắt đầu làm việc với các cảnh báo của trình biên dịch và các biến và nhập không sử dụng. Nhận xây dựng sạch trước. Sau đó bắt đầu viết các bài kiểm tra đơn vị để ghi lại hành vi hiện tại, sau đó bắt đầu tái cấu trúc thực sự.

Tôi thực sự không thể thấy bất kỳ tác động tiêu cực. Bạn sẽ có được nhiều hiểu biết sâu sắc về cơ sở mã, điều này sẽ giúp cho các phép tái cấu trúc lớn hơn. Hầu như luôn luôn thích cấu trúc lại hơn là viết lại, vì trong quá trình tái cấu trúc, bạn vẫn có một sản phẩm hoạt động, trong khi trong quá trình viết lại thì bạn không. Và cuối cùng doanh số bán hàng của sản phẩm phải trả lương cho bạn.

Khi các yêu cầu bắt đầu xuất hiện, tôi sẽ sử dụng cái mà tôi gọi là phương pháp ánh đèn sân khấu. Làm điều nhanh nhẹn thông thường (ưu tiên, sau đó cắt một tấm nhỏ để lặp lại và làm việc đó) và dành khá nhiều thời gian để cải tiến mã. Sau đó, refactor nơi bạn đang làm việc. Theo thời gian, điều này sẽ bao gồm các khu vực rộng lớn của cơ sở mã mà không bao giờ bạn phải mạo hiểm vào các khu vực mà bạn sẽ gặp khó khăn trong việc chứng minh cho quản lý lý do tại sao bạn làm việc trên phần đó của mã.

Viết bài kiểm tra đơn vị có thể sử dụng thời gian của bạn có giá trị hơn: nó sẽ cung cấp cho bạn một số thông tin chi tiết về hoạt động hiện tại của cơ sở mã, và nếu bạn quyết định bắt đầu từ những gì bạn có thay vì viết lại mọi thứ từ đầu, bạn sẽ có cơ sở vững chắc để thực hiện thay đổi mà không có quá nhiều rủi ro. Rất có thể là khi viết các bài kiểm tra đơn vị, bạn cũng sẽ thực hiện các thay đổi đối với cơ sở mã chỉ để đưa nó vào một hình dạng có thể kiểm tra được; những cái đó là tốt, bởi vì đơn vị kiểm tra thường cũng có nghĩa là mô-đun, đóng gói và chủ yếu là độc lập với trạng thái bên ngoài. Và, hầu hết tất cả, các bài kiểm tra đơn vị được viết tốt là tài liệu kỹ thuật vô giá. Với các bài kiểm tra đơn vị tại chỗ, bạn sẽ có thể đánh giá những gì cơ sở mã hiện tại có thể và không thể làm, thay vì đưa ra những phỏng đoán hoang dã hoặc viết lại mọi thứ chỉ trong trường hợp.

Pha trộn câu trả lời - suy nghĩ của tôi sẽ là pha trộn thử nghiệm và dọn dẹp - có thể là 50/50? Nếu bạn làm việc một khu vực thực hiện một cách tiếp cận TDD - thiết lập các thử nghiệm bạn cần biết rằng thử nghiệm đơn vị và tích hợp là như mong muốn và sau đó bắt đầu sửa chữa. Di chuyển khi thời gian cho phép.

Điều đó có thể có nghĩa là bạn sẽ không đạt được nhiều tiến bộ, nhưng điều đó có nghĩa là bạn sẽ có một cơ sở mã ổn định độc đáo ở một số khu vực, ít nhất, và bạn sẽ có một cơ sở khởi đầu tốt.

Phản ứng ruột của tôi ban đầu là "có thể thực sự đau khi dọn sạch mã bị hỏng không?" (hay còn gọi là lỗi trình biên dịch), nhưng sau đó tôi nhớ những lần sửa lỗi thực sự đã phá vỡ chức năng trong một số trường hợp thực sự kỳ lạ bởi vì thay vì một luồng bị chết, nó để lại bộ nhớ ở những vị trí xấu - về cơ bản là một lỗi hỏng còn che giấu một lỗi thậm chí còn tồi tệ hơn. Nó thực sự có thể là một hộp Pandora của những bất ngờ khó chịu.

Cho rằng bạn đang làm điều này trong khi chờ đợi thêm yêu cầu, tôi nghĩ rằng bất cứ điều gì bạn có thể chẩn đoán sự hỗn loạn sẽ bổ sung rất nhiều cho sự tỉnh táo lâu dài của bạn.