Những cách tiếp cận nào tôi có thể thực hiện để giảm tỷ lệ giới thiệu các lỗi mới trong một ứng dụng kế thừa phức tạp?

Nơi tôi làm việc, tôi thường phải phát triển (và sửa lỗi) trong một hệ thống cũ (.NET 1), mã này là spaghetti hoàn chỉnh - với rất ít suy nghĩ được đặt cho tên biến, cấu trúc chương trình cũng như nhận xét.

Do đó, tôi mất nhiều thời gian để hiểu những gì bit cần thay đổi và tôi thường 'phá vỡ' phần mềm hiện có vì tôi đã thực hiện sửa đổi. Tôi thực sự muốn dành một vài tháng (với các đồng nghiệp) để thực hiện tái cấu trúc nhưng các nhà phát triển hiện tại đều không thể thấy được nhu cầu - cũng không nghĩ có thời gian cho việc này (hệ thống rất lớn).

Tôi sợ phải làm việc với mã của nó vì phải mất nhiều ngày để sửa một cái gì đó chỉ để phát hiện ra tôi đã làm hỏng thứ khác. Điều này rõ ràng khiến tôi trông không đủ năng lực - vậy làm thế nào tôi có thể đối phó với điều này?

Bắt đầu viết bài kiểm tra cho các phần bạn đang làm việc. Bạn có thể thử một quy trình làm việc giống như thế này:

1. Viết bài kiểm tra cho phần bạn sắp thay đổi. Điều này cũng sẽ giúp bạn hiểu cách mã hiện tại hoạt động.
   • Mã tái cấu trúc để hỗ trợ kiểm tra nếu cần, nhưng bạn có thể muốn viết các bài kiểm tra không đơn vị nếu thời gian ngắn.
2. Chạy thử nghiệm của bạn để đảm bảo mọi thứ đang hoạt động như bạn mong đợi.
3. Hãy thay đổi. Tái cấu trúc nếu cần theo tinh thần cải tiến mã liên tục, nhưng không được mang đi.
4. Chạy lại các bài kiểm tra của bạn để đảm bảo bạn duy trì chức năng tương tự.

Nếu bạn không vứt bỏ các bài kiểm tra của mình, bạn sẽ theo thời gian xây dựng một bộ kiểm tra bao gồm hầu hết các phần quan trọng (và / hoặc dễ bay hơi) của ứng dụng và thực hiện các thay đổi trong đó sẽ trở nên dễ dàng và an toàn hơn.

Bạn cũng có thể thấy Làm việc hiệu quả với Mã di sản của Michael Feathers hữu ích.

Tôi thích tuân theo Quy tắc Hướng đạo Nam của Bác Bob Martin :

"Khi bạn có một di sản lộn xộn lớn, điều bạn phải làm là Tập những gì bạn phải làm là ngừng tạo ra những mớ hỗn độn và bắt đầu dọn dẹp chúng.

Điều này không có nghĩa là bạn gọi người quản lý của mình vào phòng hội thảo và nói với họ rằng bạn sẽ không cung cấp các tính năng trong ba tháng tới trong khi bạn cấu trúc lại mã. KHÔNG làm điều này! Thay vào đó, điều đó có nghĩa là bạn sẽ áp dụng Quy tắc Hướng đạo của Boy Boy và kiểm tra từng mô-đun trong sạch hơn một chút so với khi bạn kiểm tra nó.

Từ lần lặp đến lần lặp và từ khi phát hành đến khi phát hành, bạn sẽ dọn sạch hệ thống này trong khi tiếp tục thêm các tính năng và chức năng mới cho nó. Không có cách nào khác."

Bạn có thể giải thích cho người quản lý rằng các bản sửa lỗi sẽ mất hàng giờ kết thúc sau nhiều ngày do sự lộn xộn của cơ sở mã. Các nhà phát triển khác sẽ không thấy bất kỳ nhu cầu tái cấu trúc nào nếu họ là nhà phát triển ban đầu - họ sẽ biết hệ thống từ trong ra ngoài, nhưng ban quản lý nên biết rằng sẽ có rủi ro nếu những nhà phát triển đó rời đi và mang theo kiến ​​thức của họ.

Thực hiện tái cấu trúc hoàn chỉnh thường không khả thi, do đó, bạn thường tái cấu trúc các bit nhỏ tại một thời điểm - một vài phương thức hoặc một mô-đun. Heck, nếu phải mất vài ngày để khắc phục, có thể bạn có thể bao gồm một cấu trúc lại nhỏ của mô-đun có vấn đề cùng một lúc.

Bạn có thực sự cần phải dành hàng tháng để cấu trúc lại mã không? Hoặc bạn có thể cấu trúc lại mã khi bạn thực hiện thay đổi. Vì vậy, ví dụ, nếu bạn xác định rằng phương thức Foo cần được sửa đổi, bạn có thể tận dụng cơ hội để cấu trúc lại phương thức Foo. Và nếu bạn phải thực hiện hàng tá phương pháp khác để tìm ra Foo là vấn đề, bạn có thể để lại bình luận trong các phương thức đó để bạn hoặc người khác trong tương lai biết mã phải làm gì. Tất nhiên, điều đó có nghĩa là vẫn còn một đống mã spaghetti, nhưng ít nhất bạn có thể di chuyển cơ sở mã theo đúng hướng và giúp bạn dễ dàng xuống dòng hơn. Nhận được nhiều tháng thời gian để mã cấu trúc lại sẽ là một việc lớn vì điều đó có nghĩa là bạn không cung cấp bất cứ thứ gì mà người dùng cuối muốn trong suốt thời gian đó.

Và việc tạo các bài kiểm tra đơn vị (hoặc, hy vọng, việc mở rộng bộ kiểm tra hiện có) sẽ giúp bạn ít vô tình phá vỡ thứ gì đó.

Một mẹo khác. Khi các con bọ tự biểu hiện, và sau khi áp dụng băng không dừng lại ở đó!

Hỏi năm người, uống viên thuốc màu đỏ và xem lỗ thỏ đi sâu đến đâu, và khắc phục nguyên nhân gốc rễ (và đường dẫn xuống đó).

Bạn học được rất nhiều về hệ thống. Nó giúp ưu tiên những gì cần sửa chữa và tái cấu trúc. Và sau một vài chuyến đi như vậy, bạn có một số "chùm hỗ trợ" vững chắc để củng cố đống mì spaghetti nguyên khối.

Bạn cũng có thể giữ mã cũ tại chỗ cho đến khi hoàn toàn chắc chắn rằng các sửa đổi của bạn là bằng chứng âm thanh. Chỉ cần trường hợp tất cả các thay đổi của bạn, vì vậy bạn có thể chuyển đổi chúng trong thời gian chạy và nhanh chóng xác định vị trí của lỗi hồi quy mới:

// old code
...

if (!File.ReadAllText("c:\patch_control.txt").Contains("StrangeUIBugFix=0"))
{
    // new code goes here
    ...
}

// old + new code
int someValue = 
    IsEnabled("StrangeUIBugFix") ? a + b :  // new code
    a * b; // old code

Một điều: Never change any existing code if you are not sure what effect change would have on complete application.