Những lợi ích thực sự của phân tích mã tĩnh là gì?

Các công cụ như pc-lint hoặc QAC có thể được sử dụng để thực hiện phân tích mã tĩnh trên cơ sở mã.

Theo kinh nghiệm của tôi, phân tích tĩnh thường mang lại một lượng nhiễu lớn, tức là cảnh báo về những thứ không phải là lỗi thực sự nhưng bằng cách nào đó vi phạm một trong các quy tắc trong một bộ quy tắc nhất định. Tắt các quy tắc nhất định (có thể là tốt trong bộ quy tắc hoặc thông qua các nhận xét đặc biệt trong mã) có thể là một quy trình rườm rà thực sự.

Những lợi ích thực sự của phân tích mã tĩnh là gì?

Tôi đã làm việc tại một nơi sử dụng một hệ thống phân tích mã tĩnh thương mại có tên là Coverity Ngăn chặn, và nó thật tuyệt vời! Nó thực sự tinh vi và thông minh.

Chúng tôi đã ném khoảng 18 GB mã C và C ++ mã nguồn mở và độc quyền vào nó, và nó sẽ lần theo các đường dẫn mã và nhanh chóng tìm ra các lỗi tinh vi mà con người sẽ phải theo dõi mãi mãi. Nó cũng tuyệt vời trong việc xác định chính xác những thứ thường là Heisenbugs.

Nó chạy vài ngày một lần so với cơ sở mã của chúng tôi và một tính năng hay là chúng tôi có thể nói với nó, "Đây thực sự không phải là một lỗi", và nó sẽ nhớ điều đó trong tương lai.

Gotcha là, Coverity thực sự đắt tiền. Họ không công bố chi phí, nhưng tôi có cảm giác rằng đối với các dự án thương mại, nó bắt đầu với hàng trăm ngàn đô la mỗi năm. Nhưng nó có thể tiết kiệm cho chúng tôi khi phải thuê cả một nhóm các nhà phát triển và nhân viên QA, vì vậy trên toàn bộ quản lý của chúng tôi dường như nghĩ rằng đó là một mua tốt.

Có kinh nghiệm đó, tôi trông khá thuận lợi về phân tích mã tĩnh.

Khi bắt đầu với một ngôn ngữ mới, thật tuyệt khi có một huấn luyện viên. Đó là cách tôi nghĩ về các công cụ phân tích tĩnh. Tôi viết rất nhiều javascript và lúc đầu tôi đã bắt gặp một vài thói quen xấu chủ yếu là vì tôi đã chuyển một số thứ từ các ngôn ngữ trước đó. Javascript khá linh hoạt để bạn có thể thoát khỏi khá nhiều thứ nhưng nếu tôi có cảnh báo cho tôi về một số mẫu nhất định, tôi sẽ chọn các mẫu mã tốt hơn ngay từ đầu thay vì phải học lại các thứ sau này.

Máy phân tích tĩnh về cơ bản là các đánh giá mã được hỗ trợ bằng máy. Họ sẽ chỉ ra những khu vực nghi vấn có thể bị bỏ qua trong quá trình kiểm tra thường xuyên.

Ví dụ, tác giả có thực sự muốn thực hiện một bài tập trong điều kiện này không?

if (x = 1) {
    ...
}

Hoặc có lẽ một tân binh nhầm lẫn giữa việc đúc từ vựng:

char* number = "123";
int converted = number;

Chắc chắn máy phân tích tĩnh yêu cầu tinh chỉnh. Sau đó, một lần nữa, kiểm soát sửa đổi, wiki, trình theo dõi lỗi, máy in đẹp và các công cụ khác cũng yêu cầu một số thiết lập. Dự án càng lớn, phần thưởng cho lao động ban đầu càng tốt.

Từ quan điểm của một nhà tư vấn, mọi công cụ phân tích tĩnh sẽ có một số nhiễu nhưng không phải tất cả các máy phân tích tĩnh đều được tạo ra như nhau. Các công cụ phân tích tĩnh như Coverity, Klocwork, Grammatech có các kỹ thuật phân tích tốt nên tạo ra kết quả chính xác hơn. Nếu bạn điều chỉnh và tinh chỉnh thêm một số thứ bạn sẽ có kết quả tốt hơn thông thường (xét cho cùng, máy phân tích tĩnh phải có khả năng chạy trên tất cả các loại mã khác nhau từ một thiết bị y tế nhỏ đến hệ điều hành mạng). Xác định "tiếng ồn" cũng phụ thuộc vào tiêu chí của bạn cho những gì tạo thành một báo cáo đáng sửa chữa. Ở một đầu của phổ, một số nhà phát triển đánh dấu tất cả các báo cáo họ không sửa là "sai" (ngay cả mã được viết kém mà họ không có thời gian để sửa) và ở đầu kia,

Một số công cụ này tập trung vào phân tích trung tâm hơn và các công cụ khác tập trung vào máy tính để bàn nhiều hơn - mặc dù cả ba đều có các tính năng hỗ trợ cả hai. Như @Bob đã đề cập, họ tốn tiền.

Trong công ty trước đây của chúng tôi, chúng tôi đã sử dụng máy phân tích tĩnh của Parasoft. Và người ta đã tin rằng trong nhóm có ít nhất 60% lỗi thời gian chạy đã bị bắt trước khi biên dịch.

Phân tích tĩnh cũng có thể được thực hiện mà không cần công cụ, bằng cách thực hiện đánh giá thủ công trên mã phần mềm. Đây thường là cách hiệu quả nhất để cải thiện chất lượng mã.

Tùy chọn tốt thứ hai là đầu tư cho một hoặc nhiều công cụ phân tích tĩnh cao cấp (như Coverity đã đề cập trước đó, hoặc KLOCwork). Vì các công cụ này thực hiện các phân tích sâu hơn nhiều so với xơ vải, ví dụ, tỷ lệ tín hiệu trên tạp âm tốt hơn nhiều.

Tôi xem xét sử dụng lint làm tùy chọn thứ ba, vì độ ồn cao. Áp dụng lint cho một dự án hiện có có thể là một nhiệm vụ khó khăn.

Nói chung, phân tích chương trình tĩnh đã tiến bộ rất nhiều trong những năm gần đây. Các công cụ phân tích tĩnh hiện tại có khả năng thực hiện các phân tích liên văn bản sâu, có thể tự động xác định ví dụ về các điều kiện trước và sau điều kiện. Điều này có thể là một trợ giúp tuyệt vời cho các đánh giá mã sau này là tốt.

Do tỷ lệ dương tính giả cao, bạn không nên sử dụng công cụ phân tích tĩnh (như lint hoặc FindBugs) cho mỗi lần biên dịch.

Thay vào đó, đây là một kiểm tra vệ sinh tốt để tham khảo ý kiến một khi bạn gặp lỗi và không thể tìm ra . Trong trường hợp đó, bạn có thể giải trí các kết quả dương tính giả và bạn có thể đã thu hẹp các nguồn có thể xảy ra lỗi. Ví dụ: nếu bạn tái tạo lỗi của mình mà không thực hiện một số mô-đun, bạn có thể bỏ qua những gì FindBugs nói với họ. Điều này đặc biệt hữu ích khi bạn đang xem một đoạn mã và nghĩ rằng nó nói một điều, trong khi trình biên dịch đọc nó theo nghĩa đen (chẳng hạn như trong Java khi bạn có một equalsphương thức lấy kiểu của lớp thay vì Object).

Bạn cũng có thể có các công cụ phân tích tĩnh là một phần của quy trình phát triển của mình: Khi nhà phát triển nhận được đánh giá mã, họ cũng nên chạy FindBugs trên đó. Nói tóm lại, nó hữu ích, nhưng bạn sẽ không sử dụng nó thường xuyên như trình biên dịch hoặc trình soạn thảo văn bản.