Làm thế nào để tránh những cạm bẫy của phân tích tĩnh

Tôi đang làm việc tại một công ty sẽ đạt điểm 11 trong bài kiểm tra Joel - ít nhất là trên giấy tờ.

Tuy nhiên, trên thực tế, không có gì hoạt động tốt như mong đợi, và dự án đã có mặt trên DEFCON 1 được nửa năm. Bây giờ, hầu hết các đồng nghiệp của tôi rất vui nếu họ có thể trở về nhà vào lúc 6 giờ tối - Chủ nhật.

Một trong những thực tiễn rõ ràng tốt khiến tôi không làm việc là sử dụng các công cụ phân tích tĩnh. Dự án vừa theo dõi gcc -Wall cảnh báo và một công cụ "C / C ++" độc quyền và rất đắt tiền .

Cảnh báo Gcc thường làm nhiều hơn là không chỉ ra các lỗi thực sự (nếu hầu hết thời gian không tấn công).

Tuy nhiên, các công cụ độc quyền liệt kê những thứ như phôi ẩn và kích thước của một chuỗi ký tự. Các diễn viên tiềm ẩn cũng được đưa vào danh sách đen trên stylebook của họ.

Thực tiễn tiêu chuẩn là mọi người bị ép để làm cho mọi cảnh báo im lặng. Lưu ý rằng điều này không loại trừ các cảnh báo chủ yếu là dương tính giả, đây không phải là vấn đề.

Kết quả là:

1. Mọi người thêm các kiểu phôi vào mỗi giá trị và cho mọi đối số ẩn các kiểu không khớp có vấn đề thực sự trong quy trình.
2. Mọi người giới thiệu bởi một lỗi hoặc sử dụng một tính năng ngôn ngữ có vấn đề khác. (Strlen thay vì sizeof, strncpy thay vì strcpy, v.v.)
3. Các cảnh báo im lặng.
4. Các báo cáo lỗi bắt đầu lăn vào.

Điểm chính là mã gốc đã hoạt động và được viết bởi những người chơi an toàn trong khả năng ngôn ngữ của họ trong khi các bản sửa lỗi thì không.

Bây giờ, tôi không thực sự nghĩ rằng công ty này có thể được cứu. Tuy nhiên, tôi muốn biết liệu có cách nào tốt hơn, tốt nhất là sử dụng các công cụ "pro" hay tôi chỉ nên tránh sử dụng chúng trong trường hợp tôi là người đưa ra quyết định trong tương lai.

Một giải pháp không cho rằng tất cả các lập trình viên đều là những thiên tài không thể sai lầm. Bởi vì, nếu họ là như vậy, thì không cần phải sử dụng các công cụ ở nơi đầu tiên.

Tuy nhiên, trên thực tế, không có gì hoạt động tốt như mong đợi, và dự án đã có mặt trên DEFCON 1 được nửa năm. Bây giờ, hầu hết các đồng nghiệp của tôi rất vui nếu họ có thể trở về nhà vào lúc 6 giờ tối - Chủ nhật.

Đây chắc chắn là một đoạn tốt của vấn đề của bạn. Một kỹ sư phần mềm không thể làm việc năng suất trong hơn 40 giờ / tuần. Nếu bạn vượt lên trên, bạn sẽ làm tổn hại nghiêm trọng đến khả năng làm việc của mình - đến mức mà thậm chí làm việc 80 giờ / tuần mang lại rất ít giá trị cho dự án, và đôi khi, các dự án thậm chí có thể thoái lui vì nhóm đưa ra nhiều lỗi hơn họ có thể sửa chữa. Nếu bạn đã làm 60 giờ / tuần hoặc hơn trong nửa năm, thì cả nhóm của bạn cần nghỉ ngơi tốt và quay lại vào lúc 40 giờ / tuần. Bạn không thể giải quyết bất cứ điều gì với lực lượng lao động hầu như không có khả năng làm hỏng bàn phím vì họ làm việc quá sức.

Tuy nhiên, các công cụ độc quyền liệt kê những thứ như phôi ẩn và kích thước của một chuỗi ký tự. Các diễn viên tiềm ẩn cũng được đưa vào danh sách đen trên stylebook của họ.

Bạn thực sự cần phải bỏ hoàn toàn công cụ hoặc cấu hình lại / thay thế nó. Cảnh báo trên mỗi diễn viên ngầm là quá nhiều cho bất cứ ai để đối phó.

Tôi đang làm việc tại một công ty sẽ đạt điểm 11 trong bài kiểm tra Joel - ít nhất là trên giấy tờ.

Bài kiểm tra đó chỉ liên quan nhẹ đến các công ty phần mềm. Tôi không hiểu sự cường điệu về nó. Bạn có thể đạt điểm 12 và vẫn có lập trình viên 100% tào lao. Mọi người quan trọng hơn nhiều so với các công cụ.

Tuy nhiên, các công cụ độc quyền liệt kê những thứ như phôi ẩn và kích thước của một chuỗi ký tự. Các diễn viên tiềm ẩn cũng được đưa vào danh sách đen trên stylebook của họ. Thực tiễn tiêu chuẩn là mọi người bị ép để làm cho mọi cảnh báo im lặng. Lưu ý rằng điều này không loại trừ các cảnh báo chủ yếu là dương tính giả, đây không phải là vấn đề.

Đây là vấn đề lớn nhất với tất cả các máy phân tích tĩnh: quá nhiều dương tính giả. Cách duy nhất để xử lý việc này là tìm hiểu chi tiết tại sao công cụ được thiết lập để đưa ra cảnh báo cho một vấn đề nhất định. Chỉ sau đó, bạn mới có thể đưa ra các giả định đủ điều kiện về việc cảnh báo có sai hay không.

Đối với các kiểu cụ thể của các kiểu chữ ngầm, nó xuất hiện do một số lỗi rất phổ biến, tinh tế và nguy hiểm trong ngôn ngữ C, gây ra bởi hai quy tắc quảng cáo ngầm ẩn (moronic) trong C. Chúng được gọi chính thức là quy tắc quảng cáo số nguyên và các chuyển đổi số học thông thường . Tôi nghĩ rằng ít hơn một phần mười của tất cả các lập trình viên C chuyên nghiệp có thể giải thích hai quy tắc này làm gì và họ không làm gì. Tuy nhiên, các quy tắc này là cực kỳ cơ bản và được áp dụng hàng ngàn lần giữa các dòng trong bất kỳ chương trình C bình thường nào.

Tiêu chuẩn MISRA-C dành cả một chương để giải thích các quy tắc chuyển đổi ngầm ẩn nguy hiểm này và sau đó họ đã thêm nhiều quy tắc khá phức tạp để tránh các lỗi gây ra bởi chuyển đổi ngầm. Điều này có tác động khá lớn đến tất cả các máy phân tích tĩnh trên thị trường.

Tôi muốn giới thiệu bất kỳ lập trình viên C nào đọc chương MISRA-C đó, hoặc ít nhất là Google, hai quy tắc quảng cáo tôi đã đề cập và đọc càng nhiều về chúng càng tốt. Bạn chỉ có thể bỏ qua bộ phân tích tĩnh khi bạn biết mọi thứ cần biết về các quy tắc này.

Bây giờ, tôi không thực sự nghĩ rằng công ty này có thể được cứu. Tuy nhiên, tôi muốn biết liệu có cách nào tốt hơn, tốt nhất là sử dụng các công cụ "pro" hay tôi chỉ nên tránh sử dụng chúng hoàn toàn trong trường hợp tôi là người đưa ra quyết định trong tương lai.

Một giải pháp không cho rằng tất cả các lập trình viên đều là những thiên tài không thể sai lầm. Bởi vì, nếu họ là như vậy, thì không cần phải sử dụng các công cụ ở nơi đầu tiên.

Không có cách dễ dàng xung quanh nó. Vấn đề thực sự không phải là công cụ, mà là ngôn ngữ C tối nghĩa. Nó có vẻ là một ngôn ngữ dễ dàng trong nháy mắt, nhưng có rất nhiều cơ chế phi logic và kỳ lạ đang diễn ra giữa các dòng. Và cũng có hàng trăm trường hợp hành vi không xác định / không xác định / impl.specific trong ngôn ngữ. Hầu hết trong số họ bạn phải học và tránh.

Vì vậy, bạn phải trở thành một lập trình viên C kỳ cựu, hiểu tất cả những cảnh báo khó hiểu này, hoặc bạn phải ở trong một nhóm có ít nhất một người như vậy. Các công ty chỉ thuê một nhóm lập trình viên cơ sở không có cựu chiến binh trong nhóm không nên sử dụng các công cụ này, họ cũng không nên làm việc với sự phát triển phần mềm toàn vẹn cao.

Không rõ liệu bạn đang hỏi làm thế nào để khắc phục vấn đề, hoặc làm thế nào bạn có thể tránh nó ngay từ đầu. Tôi giả sử sau này.

Có vẻ như bạn đã dựa vào phân tích tĩnh như là phương tiện chính để phát hiện và tránh lỗi. Có lẽ bạn nên tập trung hơn vào các bài kiểm tra đơn vị và các công cụ động ... chẳng hạn như trình kiểm tra bộ nhớ.

Đó là một ý tưởng tồi khi dựa vào một công cụ tạo ra nhiều dương tính giả, đặc biệt là nếu bạn không thể triệt tiêu những dương tính giả đó. Nó khuyến khích các lập trình viên mệt mỏi / làm việc quá sức (hoặc lười biếng) thực hiện "sửa lỗi" để làm cho các cảnh báo biến mất. Nếu bạn không thể chọn lọc triệt để các thông báo sai (ví dụ như với các bình luận) hoặc điều chỉnh quy tắc, thì bạn cần một công cụ tốt hơn. Hoặc ít nhất, bạn chỉ nên sử dụng nó một cách tiết kiệm.

Có vẻ như bạn có vấn đề với những người bất cẩn và / hoặc mắc lỗi do làm việc quá sức. Có lẽ bạn nên dành nhiều thời gian / nỗ lực hơn trong đánh giá mã. Điều này trực tiếp giải quyết quan sát của bạn rằng lập trình viên không phải là thiên tài.

Cuối cùng, có vẻ như bạn có thể đã phải chịu đựng thời hạn không thực tế, người nghèo cung cấp lại và / hoặc yêu cầu thay đổi. Đây là một vấn đề quản lý, và phải được giải quyết ở cấp độ đó ... nếu không, có nguy cơ thất bại dự án cao và thiệt hại lâu dài đối với năng suất và tinh thần của nhân viên.

Ngoài câu trả lời tuyệt vời của user29079, tôi muốn thêm một lần thiếu ngôn ngữ C làm tăng thêm vấn đề. Tôi đã không nhận thức được sự thiếu hụt này cho đến khi tôi chuyển sang Java.

Mục đích của một cảnh báo là mang đến sự chú ý của người viết và những người đọc mã tương lai về thực tế rằng có một điều gì đó đáng nghi đang xảy ra. Điều đó, như là một khái niệm, là hoàn toàn tốt: bạn càng kích hoạt nhiều cảnh báo, bạn càng phát hiện ra nhiều thứ tanh.

Điều gì là sai lầm chết người , là quan niệm rằng mọi thứ tanh cá nhỏ phải được sửa chữa bằng mọi giá, bằng cách thay đổi mã . Đó là nguyên nhân gây ra vấn đề mà OP đang mô tả: các nỗ lực đã được khắc phục để nhanh chóng đưa ra các cảnh báo bằng cách thay đổi mã đang hoạt động tốt.

Đồng thời, chúng tôi không muốn mã của mình phát ra hàng trăm cảnh báo mỗi khi chúng tôi biên dịch, bởi vì các cảnh báo khá sớm trở nên vô nghĩa và không ai chú ý đến các cảnh báo mới nữa.

Vì vậy, đây dường như là một trường hợp của các mục tiêu mâu thuẫn; một mâu thuẫn.

Một giải pháp rất tốt cho tình trạng khó khăn dường như không thể này là có thể loại bỏ có chọn lọc một cảnh báo nhất định trên một tuyên bố, để chúng ta có thể ngăn chặn chính xác ở đó chúng ta muốn chỉ ra rằng chúng ta thực sự biết những gì chúng ta đang làm, mà không cần biết phải thay đổi bất kỳ mã.

Java có một giải pháp tốt cho vấn đề này, với @SuppressWarnings( "" )chú thích. Nếu bạn đang thực hiện một cái gọi là chuyển đổi không được kiểm soát trong java, trình biên dịch sẽ đưa ra cảnh báo để làm cho bạn chú ý, bạn kiểm tra nó, bạn xác định rằng đây là một trong những trường hợp bạn biết bạn đang làm gì, Vì vậy, bạn đi trước tuyên bố vi phạm với một @SuppressWarnings( "unchecked" )chú thích chỉ ảnh hưởng đến tuyên bố ngay sau tuyên bố đó và bạn tiếp tục cuộc sống của mình.

Vì vậy, cảnh báo biến mất, mã vẫn không thay đổi và chú thích triệt tiêu đứng đó, được tô màu xanh lục bằng cách tô sáng cú pháp, để ghi lại thực tế rằng một chuyển đổi iffy đang diễn ra, nhưng tác giả hứa là tốt. (*) Mọi người đều vui vẻ.

Trong java, bạn thậm chí có thể tiền tố các tham số riêng lẻ cho các hàm với @SuppressWarnings(), để vô hiệu hóa một cảnh báo cụ thể chỉ có thể được đưa ra trên tham số cụ thể đó.

Tuy nhiên, theo như tôi biết, C không bao giờ hỗ trợ bất kỳ cơ chế tiêu chuẩn nào để loại bỏ có chọn lọc các cảnh báo đối với các tuyên bố và một số trình biên dịch thực hiện các cơ chế độc quyền của riêng họ đã làm như vậy một cách sắc sảo, ví dụ như các #pragma warning (nnn:N)chỉ thị của Microsoft C. là bạn cần hai dòng lệnh để vừa loại bỏ cảnh báo cho một câu lệnh và để cảnh báo đó được kích hoạt cho các câu lệnh tiếp theo. Do đó, các lập trình viên C rất khó có thể từ bỏ thói quen ngăn chặn cảnh báo trên cơ sở tuyên bố cá nhân, ngay cả khi họ biết rằng cảnh báo cụ thể về tuyên bố cụ thể này là ổn.

(*) ai đó có thể lập luận rằng nếu bạn cho phép điều này, thì mọi lập trình viên trong nhà sẽ ngăn chặn các cảnh báo mà không cho họ bất kỳ suy nghĩ nào; Câu trả lời cho điều này là bạn có thể làm mọi thứ có thể để giúp các lập trình viên thực hiện công việc của họ tốt hơn, nhưng bạn không thể làm gì nếu họ chủ động quyết định phá hoại bạn.

Tôi đã nói (không biết chi tiết) rằng công ty của bạn đã mắc nhiều lỗi nghiêm trọng hơn và đây chỉ là triệu chứng: không xác định đúng miền của phần mềm được sản xuất, để quản lý nhóm đúng cách và xác định mục tiêu hợp lý.

Nếu phần mềm mà nhóm của bạn đang viết là thứ gì đó quan trọng mà cuộc sống của con người phụ thuộc vào, thì các công cụ phân tích tĩnh rất quan trọng và hữu ích. Vì "chi phí" của một lỗi, được đo bằng tiền (bỏ qua mức độ hoài nghi của nó) cao, có những công cụ đặc biệt cần thiết cho công việc. Có các hướng dẫn cho cả C và C ++ để sử dụng các tính năng ngôn ngữ một cách an toàn (đọc những gì cần tránh và cách xa để tránh nó).
Tuy nhiên, trong tình huống như vậy có nhân viên làm việc vào Chủ nhật là một ý tưởng rất tồi, hơn nữa từ bối cảnh bạn đã cung cấp, tôi ngoại suy rằng công việc cẩu thả không phải là không thường xuyên. Vì vậy, nếu đây là trường hợp, vấn đề là rất rấtlớn, và quản lý của bạn đang cố gắng giải quyết nó bằng cách sử dụng các công cụ "tốt hơn". Thật không may, đó không phải là cách mọi thứ hoạt động. Nếu tôi thậm chí gần chính xác, tôi sẽ đi xa như đề xuất rằng bạn bắt đầu tìm kiếm một công việc khác. Phần mềm quan trọng thực hiện nhiệm vụ xấu là điều có thể ám ảnh bạn và hủy hoại danh tiếng chuyên nghiệp của bạn, chưa kể đến triển vọng kiện cáo.

Mặt khác, nếu nhóm của bạn viết một thứ gì đó ít quan trọng hơn, các công cụ 'phân tích tĩnh' với tỷ lệ dương tính giả cao sẽ chỉ làm bạn chậm lại và, như bạn đã lưu ý, mọi người thường phản ứng với điều này bằng cách tìm kiếm tối đa cục bộ về hiệu quả của họ, trong trường hợp này bằng cách đơn giản là gian lận theo cách của họ xung quanh các cảnh báo, thay vì cố gắng khắc phục lý do cơ bản. Vì vậy, trong tình huống của bạn, sử dụng các công cụ này thực sự có thể làm giảm chất lượng của mã nguồn và nói chung chúng nên tránh.

Nếu bạn cần quản lý một nhóm phần mềm đang viết một số mã C hoặc C ++, trước tiên tôi muốn xác định mục tiêu chính của dự án là gì. Nếu việc viết mã không có lỗi là vô cùng quan trọng (ví dụ: ứng dụng xã hội siêu tuyệt vời mới dành cho iOS và Android không phù hợp với điều này), thì hãy sử dụng phân tích tĩnh, thậm chí có thể đi xa như thông số kỹ thuật chính thức và xác minh chính thức. Nhưng nếu đây là trường hợp, việc chọn lập trình viên giỏi và để họ làm việc trong môi trường lành mạnh với khối lượng công việc phù hợp và 40 giờ một tuần thích hợp là điều quan trọng hơn nhiều.

Mọi người không thể làm việc có trách nhiệm nếu họ bị đối xử như nô lệ (và ai đó chiếm kỳ nghỉ của tôi chính xác là thế này) và các lập trình viên giỏi sẽ đơn giản từ chối làm việc này một cách thường xuyên, trừ khi họ không biết gì hơn (và nếu họ tốt, rất có thể họ làm).

Điểm mấu chốt: Hình các mục tiêu của bạn, sau đó xác định các công cụ và quy trình bạn sử dụng, đừng để các công cụ có sẵn xác định quy trình (ergo các mục tiêu) vì quản lý (xấu) có thể muốn ép buộc bạn.

Như đã nêu trong câu trả lời của k.steff, các công cụ phân tích tĩnh cho 'C' rất hữu ích nếu bạn đang xây dựng phần mềm trong tình huống nguy cấp (phần mềm máy bay) và chúng phải được sử dụng từ ngày đầu tiên (không phải sau nhiều tháng phát triển khi xảy ra lỗi không thể tái tạo ).

Sử dụng các loại công cụ này trong quá trình phát triển thường là dấu hiệu của những lựa chọn thiết kế tồi trong quá trình này.

Trong phần mềm không quan trọng, các loại công cụ này rất hữu ích để:
quản lý hiệu quả, làm cho chúng cảm thấy hữu ích (chúng tôi đã làm một cái gì đó, chúng tôi đã chi rất nhiều tiền để sửa phần mềm). Nó cung cấp cho họ các hành động dễ thực hiện trong các báo cáo powerpoint của họ).
-Giữ các nhà phát triển 'độc hại' bận rộn. Hãy để họ định cấu hình công cụ và phân tích kết quả của công cụ để bạn có thể có thời gian sửa các lỗi khó chịu của họ.
-viết quy tắc mã hóa. Trong trường hợp đó, nó phải được sử dụng từ ngày đầu tiên. Nhưng một công cụ xem xét mã tốt có thể là sự lựa chọn tốt hơn.

Vì vậy, ý kiến ​​của tôi là bạn phải tránh các loại công cụ đắt tiền, tốn thời gian này hoặc sử dụng chúng để giữ cho những người 'độc hại' bận rộn.

Tôi đang làm việc tại một công ty sẽ đạt điểm 11 trong bài kiểm tra Joel - ít nhất là trên giấy tờ.

Xác nhận bằng thử nghiệm Joel không phải là thước đo thực hành tốt; Vô hiệu bởi Joel Test là một biện pháp thực hành xấu / thiếu. Nói cách khác, nó có thể được xem là cần thiết, nhưng không đủ.

Bây giờ, hầu hết các đồng nghiệp của tôi rất vui nếu họ có thể trở về nhà vào lúc 6 giờ tối - Chủ nhật.

Có vẻ như bạn có một vấn đề quản lý. Làm thêm giờ có hệ thống không phải là một giải pháp để hoàn thành công việc; nếu bất cứ điều gì, nó là một giải pháp để làm cho mọi thứ trông giống như họ đang làm việc và tích lũy nợ kỹ thuật.

Bây giờ, tôi không thực sự nghĩ rằng công ty này có thể được cứu. Tuy nhiên, tôi muốn biết liệu có cách nào tốt hơn, tốt nhất là sử dụng các công cụ "pro" hay tôi chỉ nên tránh sử dụng chúng hoàn toàn trong trường hợp tôi là người đưa ra quyết định trong tương lai.

Vâng, có một cách để sử dụng phân tích mã tĩnh một cách lành mạnh.

Họ có thể, và thường cung cấp rất nhiều giá trị. Bạn chỉ cần nhớ rằng, (như cảnh báo trình biên dịch), một công cụ phân tích tĩnh có thể (nhiều nhất) cung cấp gợi ý về một cái gì đó sai - không phải là báo cáo lỗi và không có gì chắc chắn.

Có vẻ như các nhà hoạch định quyết định của bạn nhầm lẫn các cờ phân tích tĩnh với các lỗi ứng dụng.

Các diễn viên tiềm ẩn cũng được đưa vào danh sách đen trên stylebook của họ.

Điều này có vẻ như một vấn đề năng lực quản lý, không phải là một vấn đề phân tích tĩnh.

Kết quả là:

Mọi người thêm các kiểu phôi vào mỗi giá trị và cho mọi đối số ẩn các kiểu không khớp có vấn đề thực sự trong quy trình.

Mọi người giới thiệu bởi một lỗi hoặc sử dụng một tính năng ngôn ngữ có vấn đề khác. (Strlen thay vì sizeof, strncpy thay vì strcpy, v.v.)

Các cảnh báo im lặng.

Các báo cáo lỗi bắt đầu lăn vào.

Tất cả đây là những cách để làm cho các báo cáo định kỳ trông tốt, không phải là cách để khắc phục các vấn đề trong mã (có vẻ như bạn lại gặp vấn đề về năng lực quản lý).