Những công cụ hoặc kỹ thuật nào hữu ích để mô tả một cơ sở mã không quen thuộc? [đóng cửa]

Khi kiểm tra thủ công mã không quen thuộc (để xem lại hoặc sửa đổi), tôi dường như có ba tùy chọn.

• Một từ trên xuống đọc của mã, lựa chọn từng tập tin nguồn tiếp theo bằng cách cơ bản các tên tập tin dường như. Tôi thường đọc gần như tất cả mọi thứ. Một số tập tin hai lần.
• Một chiều rộng đầu tiên đọc , nơi tôi tìm và đọc tất cả các phương pháp cách gọi với sự hiểu biết tối thiểu. Sau đó đọc tất cả các hàm mà hàm gọi, v.v. Ngăn xếp tinh thần của tôi có xu hướng tràn nếu tôi thực hiện một vài cuộc gọi sâu.
• Một đọc sâu-đầu tiên , nơi tôi bước qua tất cả các mã trong một trình gỡ lỗi, không chắc chắn về việc liệu này sẽ mất 8 phút hoặc 8 giờ.

Khi tôi đã đọc đủ mã để có một sự hiểu biết khá chắc chắn về những gì nó đang làm, tôi thường phản ánh rằng tôi đã đọc 80% hoặc hơn mã cơ sở, trong khi mã cơ bản là 20% hoặc ít hơn . Tôi đã lãng phí rất nhiều thời gian.

Công cụ nào hữu ích để nắm bắt nhanh mã không hài lòng? Có công cụ nào có thể đưa ra một "bức tranh lớn" về đường dẫn mã quan trọng và cho phép tôi đi sâu vào chi tiết của bất kỳ phần nào không?

Tất nhiên, điều tốt nhất là dành cho ai đó biết cơ sở mã để đưa bạn đi qua nó. Nếu đó không phải là một lựa chọn, thì có một số công cụ có thể giúp bạn.

• VisualStudio có thể tự động tạo sơ đồ lớp UML của cơ sở mã. Ít nhất nó sẽ cho bạn thấy hệ thống phân cấp lớp.
• Doxygen có thể cực kỳ hữu ích. Ngay cả khi mã không có các nhận xét kiểu doxygen, doxygen vẫn có thể tạo tài liệu có thể đọc được, sơ đồ lớp và biểu đồ cuộc gọi, có thể rất hữu ích cho việc tìm đường của bạn xung quanh một cơ sở mã lạ.

Nói chung, bạn cũng muốn sử dụng một IDE đầy đủ tính năng, nơi bạn có thể nhấp chuột phải vào bất cứ thứ gì và "đi đến định nghĩa". Điều này có thể giúp bạn tiết kiệm rất nhiều thời gian, so với việc sử dụng grep trên nhiều tệp trong cấu trúc thư mục phức tạp.

Một điều quan trọng khác, tùy thuộc vào thời gian bạn sẽ phải xử lý mã. Nếu có bài kiểm tra đơn vị, sau đó xem qua các bài kiểm tra. Nếu không có bài kiểm tra, hãy bắt đầu viết chúng. Hình thành một giả thuyết về những gì một lớp hoặc chức năng cụ thể làm, và viết một bài kiểm tra để kiểm tra nó. Điều này đòi hỏi rất nhiều kỷ luật, nhưng nó là một cách tuyệt vời để có câu trả lời về những gì xảy ra trong mã.

Đây là một cách tiếp cận quyết liệt hơn. Kỹ thuật này có thể hữu ích cho một dự án có nhiều lớp không được tổ chức thành các không gian tên có ý nghĩa.

Mục tiêu của bài tập này là khám phá mối quan hệ của lớp. Tạo một bản sao của dự án, và sau đó cố gắng đặt một số lớp vào không gian tên. Để tiết kiệm thời gian cho các lần thử lặp lại, hãy sử dụng một số công cụ xử lý tệp Regex để tự động hóa thay đổi này.

Điều này sẽ gây ra rất nhiều lỗi biên dịch. Trong quá trình sửa các lỗi này, người ta sẽ hiểu rõ hơn về cách các lớp này phụ thuộc vào nhau và quyết định lớp nào có thể được đưa vào cùng một không gian tên.

Kỹ thuật này hữu ích ở chỗ người ta có thể áp dụng nó ngay cả với ít hiểu biết về tổ chức mã của dự án. Với điều này có nguy cơ rằng một số lớp có thể bị thất lạc bởi kỹ thuật này do sự hiểu lầm.