Làm thế nào để sửa chữa một dự án với cơ bản không có cấu trúc?

Tôi đã làm việc trong một dự án phần mềm chủ yếu là solo trong hơn 5 năm. Đó là một mớ hỗn độn khi bắt đầu (tôi là nhà phát triển thứ ba hoặc thứ tư đang làm việc với nó), và mặc dù bây giờ nó đã bớt lộn xộn hơn nhưng nó vẫn vô tổ chức. Tốc độ tiến bộ trong việc kiểm soát nó là rất lớn và tôi bắt đầu cảm thấy tuyệt vọng về tình trạng của nó. Làm thế nào để tôi thực sự bắt đầu sửa chữa nó?

Chi tiết cụ thể của dự án: Đây là một chương trình bán hàng được viết gần như hoàn toàn bằng Visual Basic Classic (VB6) với phần cuối của MySQL và một công cụ báo cáo được viết bằng C #. Mô-đun báo cáo C # là một niềm vui để làm việc, nó chỉ được viết trong vài năm qua và trước đó tất cả các báo cáo đã được thực hiện trong Báo cáo Crystal 9 (vâng, chúng tôi vẫn có một số báo cáo dựa trên nó).

Tuy nhiên, chương trình thực tế là một thảm họa hoàn chỉnh. Không có tổng cộng 90 nghìn LỘC và khoảng 10 nghìn dòng bình luận (chủ yếu không phải là tài liệu, nhưng mã cũ đã được nhận xét). 158 tệp mẫu và 80 tệp mô-đun. Tôi không biết có bao nhiêu trong số đó thực sự được sử dụng, bởi vì một số tính năng của chương trình chỉ đơn giản là không dùng nữa và (uh, đôi khi) lưu ý như vậy mà không xóa mã liên quan khỏi chương trình. Tôi đoán rằng chỉ có 50% mã được sử dụng trong sản xuất thực tế.

Tôi sợ chạm vào nhiều mã chỉ vì tôi không chắc liệu tôi có phá vỡ thứ gì đó mà một khách hàng khó hiểu dựa vào hay không, nó đã xảy ra nhiều lần hơn tôi có thể đếm được. Nó giống như có những quả mìn rải khắp mã.

Không thực sự có bất kỳ cấu trúc nào cho dự án. Nó không phải là hướng đối tượng ngoại trừ ở một vài nơi tôi đã có kiên nhẫn để cải cách cho đến nay. Nếu bạn cần lấy dữ liệu trên một biểu mẫu, bạn khởi tạo một đối tượng cơ sở dữ liệu, khai báo truy vấn của bạn ngay trong hàm, thực hiện nó và làm những gì bạn muốn với tập dữ liệu.

Khi tôi bắt đầu làm việc với dự án, không có kiểm soát nguồn nào được sử dụng. Tôi đã cố gắng khuyến khích những người khác mà tôi đang làm việc để sử dụng nó, nhưng tôi là người mới và những nỗ lực của tôi để khiến mọi người sử dụng lật đổ tất cả nhưng không thành công. Nhà phát triển hàng đầu của công ty cuối cùng đã gặp phải một lỗi nghiêm trọng trong vài năm qua và anh ấy chắc chắn rằng tất cả các nhà phát triển đều sử dụng kiểm soát nguồn trên tất cả các dự án, vì vậy ít nhất đó là một số tiến bộ.

Tôi nghĩ rằng nếu tôi có thể làm việc để cải cách toàn bộ dự án, tôi sẽ có thể đạt được tiến bộ tốt và thậm chí có thể ước tính được tôi sẽ mất bao lâu để hoàn thành dự án, nhưng nó đang được sử dụng tích cực và tôi đang sử dụng liên tục được yêu cầu dập lửa, sửa lỗi, thêm tính năng, v.v.

Vì vậy, làm thế nào để tôi bắt đầu thực sự sửa chữa dự án này? Hãy thử công cụ VB6 với ngôn ngữ khác? Hãy thử và viết lại chương trình trong thời gian rảnh của tôi? Hay điều này là hoàn toàn vô vọng?

Cập nhật

Sau bài đăng này, tôi đã quay lại dự án với lòng nhiệt thành mới, nhưng lại rơi vào tình trạng vô vọng trong vòng vài tháng sau khi thấy tốc độ tiến triển chậm như vậy. Sau đó tôi đã lặp lại chu kỳ này 2 hoặc 3 lần nữa trong năm tới hoặc lâu hơn.

Tôi đã chuyển sang một công việc khác. Mặc dù sau rất nhiều năm vb6, và chỉ có kinh nghiệm ngoại vi với các công nghệ khác, việc tìm kiếm rất khó khăn và tôi đã phải đối mặt với nhiều sự từ chối trên đường đi (khoảng một chục cuộc phỏng vấn trong suốt một năm). Lời khuyên của tôi cho những người khác trong tình huống này là xem xét để lại cho yếu tố này một mình. Hãy xem xét thiệt hại bạn có thể gây ra cho sự nghiệp của mình bằng cách ở trong một vị trí cuối cùng như thế này.

Bây giờ, đó là trong kiểm soát nguồn, bạn có thể thoát khỏi mã nhận xét.

Tôi đã bắt đầu ở đây trong một tình huống tương tự (ứng dụng 80KLOC VB6 không có kiểm soát nguồn, không có cấu trúc thực, hầu hết mọi thứ được thực hiện trong các trình xử lý sự kiện).

Trong khoảng 2 năm trở đi, tôi đã nhận được hơn một nửa chuyển đổi thành C # (thường là khi các tính năng mới quan trọng được yêu cầu). Tất cả mã C # mới có phạm vi kiểm tra đơn vị. Nó chắc chắn mất nhiều thời gian hơn để chuyển đổi sang C #. Nếu bạn không thêm các mô-đun mới quan trọng, tôi sẽ không đi theo tuyến đường đó.

Một điều tôi đã làm là tạo một lớp truy cập dữ liệu thô sơ tự động tạo từ cơ sở dữ liệu. Rằng ít nhất đã bắt gặp các vấn đề trong đó một tên cột trong bảng đã thay đổi và tôi không tìm thấy tất cả các vị trí trong mã. Ngoài ra, tôi đã dần dần chuyển logic kinh doanh thành các mô-đun, ngoài các trình xử lý sự kiện.

Tôi, tuy nhiên, có lợi thế là ứng dụng chỉ là nội bộ. Vì tôi chỉ có một trang web để triển khai, tôi có thể gặp một số rủi ro lớn hơn bạn có thể. Nếu tôi mắc lỗi, việc sửa nó thường không phải là vấn đề lớn. Âm thanh như bạn không có sự sang trọng.

Tôi thực sự nghĩ rằng đặt cược tốt nhất của bạn là thực hiện theo cách tiếp cận sau:

1. Tìm hiểu từng bit một cách chi tiết. Điều này làm cho nó ít có khả năng bạn sẽ phá vỡ một cái gì đó vô tình.
2. Tái cấu trúc không thương tiếc để cải thiện sự phân tách và cấu trúc, nhưng đừng cố gắng tạo ra một phương pháp mới như lập trình hướng đối tượng trong đó, vì VB6 chỉ hút vào nó.
3. Coi nó như một kinh nghiệm học tập Làm thế nào bạn biết một cách khác sẽ tốt hơn nếu bạn chưa bao giờ thấy cách kém hơn?
4. Đừng bận tâm viết lại bằng ngôn ngữ / khung / nền tảng mới trừ khi bạn có một mô-đun chính để viết. Ngay cả sau đó, xem xét cẩn thận.

Hãy nhớ rằng, mục tiêu của chương trình là trở thành một sản phẩm giúp công ty bạn kiếm tiền. Nó không phải là một tác phẩm nghệ thuật hoàn hảo (và tôi là người cầu toàn nên tôi rất khó để thừa nhận điều đó). Đôi khi tốt hơn là nắm lấy chủ nghĩa thực dụng.

Có rất nhiều lập trình viên COBOL ngoài kia đang duy trì số lượng lớn mã kế thừa. Tôi nghi ngờ rằng tất cả họ đang làm việc điên cuồng khi viết lại nó bằng một số ngôn ngữ mới. :)

Những gì bạn cần làm là tái cấu trúc. Tái cấu trúc là gần như không thể trong tình huống như vậy mà không có bài kiểm tra đơn vị mang lại cho bạn sự tự tin rằng bạn đã không phá vỡ bất cứ điều gì. Do đó, bắt đầu với việc tạo các bài kiểm tra đơn vị. Tài liệu về hành vi của mã - nhưng không (chỉ) trên giấy, mà ở nhiều mã hơn - đơn vị kiểm tra. Khi bạn có các bài kiểm tra tại chỗ, bạn có thể bắt đầu cấu trúc lại mã.

Một quy tắc từ " Gỡ lỗi " của David Agan xuất hiện trong tâm trí: bỏ suy nghĩ và nhìn. Bạn tình cờ có một máy có khả năng xử lý số lượng lớn văn bản. Sử dụng nó để tìm ra chính xác mã nào không còn được sử dụng và loại bỏ nó không thương tiếc. Nếu bạn mắc lỗi, đó là kiểm soát nguồn dành cho.

Đó là phần dễ dàng. Điều bạn cần suy nghĩ tiếp theo là làm thế nào để bạn ăn một con voi? Một lần cắn một lúc. Nhặt " Tái cấu trúc " của Martin Fowler và thực hiện chức năng này theo chức năng, từng tệp một. Đừng bỏ hoàn toàn thứ gì đó và viết lại từ những gì bạn nghĩ là yêu cầu. Làm việc như một người leo núi, không bao giờ loại bỏ sự an toàn trước đây của bạn cho đến khi người tiếp theo được đưa ra.

Đã có đủ ẩn dụ chưa? Vấn đề là nếu bạn sử dụng nó chậm và ổn định, với nhiều cải tiến đơn giản như đổi tên hoặc tách một chức năng, bạn có thể cải thiện các phần xấu của mã mà không phá hủy các phần tốt của mã được xây dựng qua nhiều năm gỡ lỗi và yêu cầu tính năng . Bạn muốn mã vẫn có thể shippable mọi lúc. Nếu có thể làm điều đó trong khi chuyển sang một ngôn ngữ hiện đại hơn, hãy tìm nó.

Tôi ghét phải nói điều đó nhưng tôi sẽ đi với "hoàn toàn vô vọng" ngoài việc tiếp tục thực hiện một chu kỳ vô tận của bản vá / nâng cao và hy vọng không có gì phá vỡ. Tôi đã thấy quá nhiều dự án VB6 như dự án bạn mô tả và cố gắng cấu trúc lại / viết lại / làm lại chúng thành C # /. NET thất bại khủng khiếp, thường là với những người chịu trách nhiệm về nỗ lực bị sa thải.

Vấn đề là việc viết lại hoàn chỉnh từ đầu sẽ sớm trở nên cần thiết. Các phiên bản VB6 và Windows hỗ trợ tốt đang suy giảm. Tìm kiếm các nhà phát triển biết những điều kỳ quặc của VB6 và những người sẵn sàng làm việc trên các chương trình như thế này đang trở nên hiếm hơn. Các giới hạn bên trong của VB6 sẽ bị tấn công vào các chương trình lớn như thế này, gây ra các lỗi lạ.

Nếu có sự đồng thuận và cam kết tốt đối với toàn bộ, căn cứ, thiết kế lại và viết lại vào thời điểm này, hãy bắt đầu công việc đó và giao bảo trì liên tục cho người khác (nhà thầu, lập trình viên cơ sở, bất cứ điều gì phù hợp với bạn). Nếu mọi người chưa đủ thuyết phục để bắt đầu điều này, chỉ cần chờ đợi nỗi đau trở nên đủ lớn hoặc nếu không thì chuyển sang đồng cỏ xanh hơn.

Một số câu trả lời tốt ở đây đã có, tôi muốn thêm một điều. Thay vì cố gắng viết lại mọi thứ, có lẽ bạn sẽ có cơ hội chuyển ít nhất một số mô-đun đó chủ yếu là 1: 1 sang VB.NET (tất nhiên, bạn phải rất cẩn thận khi thực hiện việc này)? Theo kinh nghiệm của tôi, việc chuyển như vậy có thể được thực hiện với nỗ lực ít hơn ~ 5-10 lần so với cố gắng xây dựng lại tất cả các chức năng hiện có từ đầu. Và sau khi bạn đã chuyển nó, sau đó bạn có thể bắt đầu cấu trúc lại - với tất cả các công cụ có sẵn trong thế giới .NET, như các công cụ kiểm tra đơn vị tốt, công cụ tái cấu trúc tự động, OOP thực, v.v.

Tôi đã ở trong một tình huống tương tự, khi chúng tôi phải chuyển một chương trình C ++ 16 bit cũ (150k LỘC) sang thế giới 32 bit, nơi khung GUI ban đầu được sử dụng không còn nữa. Chúng tôi đã mất một thời gian để hiểu rằng viết lại là không thực tế, nhưng sau khi chúng tôi quyết định chuyển thứ đó sang thế giới .NET, sử dụng C ++, C ++ / CLI và C #, chúng tôi chỉ cần khoảng 9 tháng để thực hiện điều đó (với khoảng 1 dev toàn thời gian làm việc trên dự án đó). Và chúng tôi không có thử nghiệm đơn vị nào cho phần GUI có sẵn, đã thực hiện tất cả các thử nghiệm đó cho các phần đó một cách thủ công.

Mặc dù nó tập trung rất nhiều vào việc kiểm tra đơn vị ứng dụng của bạn, mặc dù điều rất quan trọng phải làm, là một điều khá khó thực hiện trong VB6, Steven McConnell đã viết một cuốn sách tuyệt vời về cách khắc phục một projet như vậy.

Hãy nhìn vào nó:

Steven C. MCCONNELL: Làm việc hiệu quả với Mã kế thừa, Ấn bản thứ hai. Microsoft Press, tháng sáu 2004.

Về cơ bản, quan điểm của anh là đưa nó từ từ, từng chút một. Ông cũng khuyên nên bắt đầu bằng cách sử dụng các kỹ thuật tái cấu trúc rất khó phá vỡ bất cứ thứ gì, đôi khi làm cho nó tồi tệ hơn một chút trong thời gian ngắn và bắt đầu sử dụng các kỹ thuật nâng cao hơn vì mã ngày càng sạch hơn và có các bài kiểm tra đơn vị để hỗ trợ nó.