Các chủ đề sau có liên quan tiếp tuyến:
Đối với phần đầu tiên của luận án, tôi đã dành 18 tháng để sửa đổi mã Fortran không có giấy tờ và một trong những nhiệm vụ đầu tiên là thử và hiểu cấu trúc tổng thể của một cơ sở mã. Điều quan trọng nhất tôi khuyên bạn nên làm là ghi chú trong tệp văn bản bất cứ khi nào bạn phát hiện ra điều gì đó. Bạn không muốn phải học lại hoặc khám phá lại mọi thứ trong quá trình tốn thời gian và bực bội này.
Trong trường hợp của tôi, không có "API" nào để nói, trong đó các đối số của các hàm không tự ghi lại, bởi vì lập trình viên trước đó đã sử dụng kiểu giống Fortran 77, và do đó, các định danh ngắn mà không có chút gợi ý nào. ý họ là. Không có bài kiểm tra nào, và vì đó là Fortran, không có tiêu đề. Thêm nhiều niềm vui hơn vào hỗn hợp, có một vài chức năng ở đây và được viết bằng C hoặc C ++.
Những điều làm việc cho tôi (giả sử bạn làm việc trong Linux):
grep. Học cách yêu thương grep; bạn sẽ sử dụng nó trong trình bao để tìm nơi các hàm được khai báo và gọi và đầu ra sẽ cho bạn biết những tập tin nào cần tìm.- Lệnh "find" trong trình soạn thảo mã hoặc IDE yêu thích của bạn. Khi bạn biết tập tin nào cần tìm, lệnh "find" sẽ giúp bạn tiết kiệm thời gian tìm kiếm các cuộc gọi chức năng.
- Tái cấu trúc mạnh mẽ, nếu bạn có thể thay đổi cơ sở mã. Tôi đã tự đặt tên biến thành tài liệu để không phải tốn công sức tinh thần để học lại những thứ tôi đã tìm ra. Tôi cũng sắp xếp hợp lý thiết kế mã khi tôi tìm ra nó để nó bớt khó hiểu hơn. Không có hơn 1000 dòng chương trình chính dài!
- Bình luận tích cực. Một lần nữa, nếu bạn có thể thay đổi cơ sở mã, hãy bình luận mọi thứ để bạn biết những gì bạn đã tìm ra. Tôi đã không sử dụng Doxygen, nhưng Doxygen tốt cho việc này.
nm. Nó có thể hữu ích trên các thư viện nếu bạn không có mã nguồn cho chúng, nhưng muốn biết liệu một chức năng bạn gặp phải có trong thư viện đó không. Tuy nhiên, nó chỉ hoạt động nếu các biểu tượng của thư viện chưa bị tước.- Bước qua mã với trình gỡ lỗi. Đó là cách hiệu quả hơn so với sử dụng
printbáo cáo. dddvà gdbrất tuyệt, và trên hầu hết mọi hệ thống Linux ngoài kia. Hãy sử dụng trình gỡ lỗi yêu thích của bạn.
- Lỗi các nhà phát triển. Tùy chọn này thực sự tốt nhất cho các câu hỏi rất nhắm mục tiêu. Nếu bạn đến gặp họ (như tôi đã làm) và nói: "Tôi không hiểu chuyện gì đang xảy ra ở đây", họ có thể thương hại bạn và cố gắng giải thích mọi thứ một cách chi tiết, nhưng điều đó sẽ bị hạn chế sử dụng Về lâu dài. Bạn sẽ phải làm việc chân tay, bởi vì các nhà phát triển đã không làm điều đó cho bạn trong việc viết tài liệu và giải thích cấu trúc cơ sở mã của họ bằng văn bản. Các nhà phát triển thực sự tốt khi bạn thực sự bị mắc kẹt trong những điều nhỏ nhặt (nếu họ nhớ những gì họ đã làm).
Những điều tôi muốn tôi nghĩ đến sớm hơn, hoặc chỉ là những lựa chọn không phù hợp với tôi:
- Doxygen. Nếu bạn điều chỉnh các tùy chọn Doxyfile, Doxygen sẽ tự động tạo ra rất nhiều tài liệu cho bạn, ngay cả khi không có cú pháp nhận xét Doxygen đặc biệt, có thể là một nơi tốt để bắt đầu; Tôi đã sử dụng điều này cho các dự án sau này tôi gặp phải và nó rất hữu ích.
- Kiểm tra đơn vị. Nếu bạn có thể thay đổi cơ sở mã và bạn có một số ý tưởng về những gì nó phải làm, hãy viết các bài kiểm tra đơn vị cho các chức năng khác nhau. (Đó là một kỹ năng hữu ích để nhận bất kể.)
- Nếu bạn đang làm việc với C / C ++, hãy xem các tiêu đề.
- Viết chương trình ví dụ. Không phải là một lựa chọn cho tôi trong dự án Fortran đó, nhưng nó hữu ích cho tôi trong việc chọn API của bên thứ ba. Ngoài ra, nhìn vào các chương trình ví dụ của họ , nếu họ có bất kỳ.
- Sử dụng
gcovvà lcovđể thực hiện phân tích bảo hiểm về các lần chạy mã điển hình, nếu bạn có ví dụ hoặc thực thi để làm việc. Nếu có các ví dụ được cho là thực thi các phần lớn của cơ sở mã, hai công cụ này được kết hợp sẽ cho bạn biết số lần mỗi dòng mã được truy cập. Nó hữu ích nhất với cờ gỡ lỗi được kích hoạt. Nếu một phần của mã không được truy cập ở tất cả, có lẽ việc hiểu nó ngay lập tức ít quan trọng hơn. Nếu một phần của mã được truy cập nhiều, có lẽ bạn nên hiểu nó là gì. Có thể mã được thực thi rất nhiều vì đó là một vòng lặp không quan trọng hoặc nó có thể là một hàm chính mà rất nhiều hàm khác dựa vào. Bạn không thể chỉ nói về phân tích bảo hiểm, nhưng phân tích bảo hiểm cung cấp cho bạn một số ý tưởng về nơi tập trung thời gian của bạn.
- Các công cụ phân tích mã tĩnh như
splintcó thể cho bạn biết nếu một cái gì đó tanh đang xảy ra trong mã, như một số biến không bao giờ được sử dụng.
- Hồ sơ. Một lần nữa, cung cấp cho bạn dữ liệu không ngay lập tức cho bạn biết điều gì là quan trọng hoặc không quan trọng, nhưng gợi ý những gì có thể quan trọng. Nếu nhiều thời gian CPU dành cho việc gọi một chức năng, bạn có thể muốn xem xét điều đó và xem nó làm gì. Bạn cũng có thể sử dụng đầu ra định hình với
dotvà graphvizđể tạo biểu đồ cuộc gọi và xem số lần gọi các hàm, như phân tích vùng phủ sóng. Đối với các mã phức tạp, một phân tích đồ họa có thể hữu ích hơn rất nhiều.
- Nếu bạn đang làm việc tại C, Frama-C được cho là hữu ích trong việc phân tích mã, nhưng tôi chưa bao giờ sử dụng nó vì nó có vẻ quá phức tạp không đáng để bỏ công sức. Tôi làm một số công việc trong C thuần túy, nhưng chủ yếu là mã mà tôi viết; Tôi chưa bao giờ làm việc với mã C không có giấy tờ.