Lỗi có thể tránh được với các tiêu chuẩn mã hóa [đã đóng]

Tôi đang tìm kiếm số liệu thống kê (hoặc ước tính) sao lưu tuyên bố rằng các tiêu chuẩn mã hóa giúp giảm lỗi. Số cứng sẽ rất tốt, mặc dù tôi không có nhiều tìm kiếm. Tôi thậm chí đã xem xét theo dõi lỗi cho các dự án nguồn mở khác nhau, nhưng đã không thành công khi tìm thấy những gì tôi cần. Có ai ở ngoài đó biết bất cứ nơi nào tôi có thể tìm thấy điều này? Hoặc có ai trong số các bạn đóng góp cho bất kỳ dự án nguồn mở nào có lỗi có thể tránh được với các tiêu chuẩn mã hóa tốt hơn không?

Các tiêu chuẩn mã hóa của riêng họ không làm giảm lỗi. Các tiêu chuẩn mã hóa như là một phần của quy trình phát triển phần mềm âm thanh giúp giảm lỗi.

Dưới đây là hai bài báo nghiên cứu tác động thống kê của quy trình kỹ thuật phần mềm âm thanh đối với việc giảm lỗi mà bạn có thể sử dụng làm điểm khởi đầu:

• Danh sách 10 phần mềm giảm thiểu khiếm khuyết phần mềm , khảo sát các cải tiến trong công nghệ phần mềm dựa trên kinh nghiệm từ năm 1987
• Phân tích quan trọng về quy trình dữ liệu PSP , nghiên cứu các số liệu thống kê được thu thập từ Quy trình phần mềm cá nhân và tác động của PSP đối với các nguyên nhân phổ biến gây ra lỗi phần mềm

Mã hóa "tiêu chuẩn" ... Có rất nhiều lĩnh vực phát triển có thể được tiêu chuẩn hóa. Có phải chúng ta đang nói về các quy ước mã hóa, như các tiêu chuẩn đặt tên, v.v.? Hay chúng ta đang nói về một cái gì đó sâu sắc hơn, như TDD / BDD, CI, v.v.?

Tôi có thể nói với bạn rằng việc tuân thủ phương pháp "thử nghiệm đầu tiên", với CI thực thi vượt qua các thử nghiệm và bảo hiểm mã tốt, sẽ làm giảm số lượng lỗi được tìm thấy bởi khách hàng. Kiểm tra tự động, cả bởi nhà phát triển và QA, cũng là một cách tương đối "rẻ" để tìm lỗi vì chúng thường có thời gian phản hồi rất ngắn. Bạn có thể biết rằng bạn đã không viết những gì bạn nghĩ bạn đã viết bằng cách chạy các bài kiểm tra đơn vị trị giá khoảng 45 giây. Một vài giờ thử nghiệm tích hợp sẽ tìm thấy những nơi cắm các thứ lại với nhau không theo kế hoạch, và thử nghiệm UI tự động từ đầu đến cuối có thể nhanh chóng phát hiện ra các lỗi chức năng trong phần mềm ở mức rất cao.

Họ cũng ngăn chặn hồi quy. Bạn đã tìm thấy một lỗi. Bạn viết một bài kiểm tra sẽ chứng minh rằng hành vi đó không còn xảy ra nữa, bạn viết mã cho đến khi bài kiểm tra vượt qua và bây giờ bạn có một bài kiểm tra rằng từ thời điểm này trở đi sẽ đảm bảo rằng lỗi không bao giờ là vấn đề nữa. Theo kinh nghiệm của tôi, đây là một nguồn chính của các lỗi mới; sửa một thứ sẽ phá vỡ thứ khác và thử nghiệm sửa lỗi dành cho nhà phát triển của bạn có thể không bao gồm tình huống khác hiện đã bị hỏng. Những thứ phá vỡ được sử dụng để làm việc là một lá cờ đỏ LỚN cho khách hàng của bạn.

Cuối cùng, cấu trúc thử nghiệm tự động mà bạn xây dựng như một phần của phương pháp này sẽ rất dễ dàng cung cấp cho bạn một môi trường nơi bạn có thể phát hành bản dựng mới của phần mềm theo nghĩa đen trong một khoảnh khắc. "Này, lỗi mà bạn vừa sửa đã gây ra một số vấn đề đau đầu thực sự; khi nào bạn sẽ sẵn sàng trong phiên bản mới?" nhấp vào "Ồ, trong khoảng 5 phút khi máy chủ xây dựng hoàn tất xuất bản nó lên trang tải xuống".

Theo như các quy ước mã hóa cơ bản, như tiêu chuẩn hóa các tên biến, v.v., tôi đã thấy hầu hết những điều đó ít hữu ích và khó chịu hơn. Đó là những loại tiêu chuẩn "tuyệt vời, vì có rất nhiều lựa chọn". Những gì bạn cảm nhận là sự khác biệt giữa một định danh PascalCase và camelCase có thể không phải là những gì người khác nghĩ. Dấu gạch dưới hàng đầu, giới hạn độ dài tên (hoặc yêu cầu mà tên phương thức / trường kể một câu chuyện); khác với các quy ước được thi hành bởi trình biên dịch hoặc thường thấy trong mã thư viện dành riêng cho ngôn ngữ, IDE hiện đại có thể cho bạn biết mọi thứ bạn cần biết về một biến hoặc hàm bao gồm cả việc bạn nên hay không nên sử dụng cụ thể hoàn cảnh. Ngoài ra, chạy kiểm tra quy ước mã thường sẽ trả về các vấn đề với mã bạn không thể hoặc không ' không muốn thay đổi, như thư viện của bên thứ ba đã sử dụng một bộ tiêu chuẩn khác hoặc mã xen kẽ có thể tuân thủ các tiêu chuẩn đặt tên API thay vì các tiêu chuẩn của ngôn ngữ mẹ đẻ của bạn. Cuối cùng, bạn thêm cruft vào mã của mình để báo cho công cụ của bạn bỏ qua cruft trong mã của bạn.

Mỗi lỗ hổng SQL tiêm là một khiếm khuyết có thể được ngăn chặn bằng một tiêu chuẩn mã hóa. Số liệu thống kê về các lỗ hổng tiêm SQL là, AFAIK, có sẵn.

Mọi lỗ hổng tràn bộ đệm có thể đã được ngăn chặn bằng một tiêu chuẩn mã hóa. Thống kê về những người có lẽ cũng có sẵn.