Làm thế nào để bạn biết nếu phần mềm là tốt hay xấu dựa trên số liệu thực nghiệm?

Tôi hiện đang được yêu cầu xem xét một dự án đã hoàn thành phát triển cốt lõi năm tháng trước, nhưng vẫn có một mức độ khiếm khuyết cao. Những gì transpires là cho khoảng 10 lỗi được cố định, chúng tôi nâng ít nhất 4 và trong một số trường hợp 8 lỗi.

Tôi tin rằng thực hành mã hóa tại nhà cung cấp là kém và có thỏa thuận chung xung quanh điều này. Tuy nhiên, tôi tự hỏi nếu có một vấn đề cấu trúc với phần mềm? Mật độ khiếm khuyết là một biện pháp hữu ích, nhưng hơn nữa nếu phần mềm cốt lõi được viết sai, thì tất cả các nhà cung cấp đang làm là chuyển vấn đề về.

Trong cơ sở hạ tầng, nó được xác định rõ hơn nếu một cái gì đó được xây dựng kém, bạn có thể sử dụng các phép đo nào cho phần mềm bên cạnh các lỗi trên mỗi LỘC?

Sản phẩm đã trong giai đoạn sửa lỗi trong 4 tháng và vẫn chưa giải quyết đủ các lỗi nghiêm trọng. Chúng tôi không tiêm chức năng mới, chỉ sửa các vấn đề hồi quy.

Điều này cho thấy một vấn đề chất lượng phát triển, không được thỏa mãn. Tuy nhiên, nếu bản thân sản phẩm bị lỗi cơ bản, đó là một vấn đề khác. Mối quan tâm là cơ sở mã lõi đã được viết xấu và có tài liệu hạn chế, tất cả các nhà phát triển bên ngoài đang làm đang chuyển vấn đề từ A sang B. Một khi các nhóm phát triển nội bộ tiếp quản tôi lo ngại rằng họ sẽ phải viết lại mã về cơ bản có được chức năng.

Vì vậy, khi bạn chấp nhận một sản phẩm từ bên thứ ba và được yêu cầu hỗ trợ, bạn sẽ sử dụng tiêu chí chấp nhận nào để xác định tiêu chuẩn?

Bên cạnh việc nhà phát triển chính của chúng tôi thực hiện đánh giá mã ngang hàng trên mỗi bản phát hành, không chắc chắn có thể làm gì khác?

Bạn không.

Chất lượng phần mềm thực sự khó đo lường khách quan. Đủ cứng để không có giải pháp. Tôi đang kiềm chế câu trả lời này để tìm hiểu câu hỏi liệu có thể có một giải pháp nào không, nhưng chỉ cần chỉ ra lý do tại sao việc xác định một câu hỏi sẽ thực sự khó khăn.

Lý do theo nguyên trạng

Như Kilian Foth đã chỉ ra, nếu có một biện pháp đơn giản cho phần mềm "tốt", tất cả chúng ta sẽ sử dụng nó và mọi người sẽ yêu cầu nó.

Có những dự án trong đó các nhà quản lý quyết định thực thi các số liệu nhất định. Đôi khi nó làm việc, đôi khi nó không. Tôi không nhận thức được bất kỳ mối tương quan đáng kể. Đặc biệt là phần mềm hệ thống quan trọng (nghĩ máy bay, ô tô, v.v.) có rất nhiều yêu cầu về số liệu để "đảm bảo" chất lượng SW - Tôi không biết về bất kỳ nghiên cứu nào cho thấy những yêu cầu này thực sự dẫn đến chất lượng cao hơn và tôi có kinh nghiệm cá nhân đối với trái ngược

Lý luận bằng phản gián

Cũng được gợi ý bởi Kilian và nói chung là "mọi số liệu có thể và sẽ được phát".

Chơi một số liệu có nghĩa là gì? Đây là một trò chơi thú vị dành cho các nhà phát triển: bạn đảm bảo các giá trị số liệu trông thực sự tốt, trong khi thực hiện các công cụ thực sự tồi tệ.

Giả sử bạn đo khuyết điểm trên mỗi LỘC. Làm thế nào tôi sẽ chơi nó? Dễ dàng - chỉ cần thêm mã! Tạo mã ngu ngốc dẫn đến không hoạt động trên 100 dòng và đột nhiên bạn có ít lỗi hơn trên mỗi LỘC. Tốt nhất của tất cả: bạn thực sự giảm chất lượng phần mềm theo cách đó.

Thiếu sót về công cụ bị lạm dụng, các định nghĩa được kéo dài đến mức tối đa, những cách hoàn toàn mới được phát minh .. về cơ bản, các nhà phát triển là những người thực sự thông minh và nếu bạn chỉ có một nhà phát triển trong nhóm của mình có các số liệu chơi vui vẻ, thì số liệu của bạn sẽ bị nghi ngờ.

Điều này không có nghĩa là các số liệu luôn xấu - nhưng thái độ của nhóm đối với các số liệu này là rất quan trọng. Đặc biệt, điều này ngụ ý rằng nó sẽ không hoạt động tốt cho bất kỳ mối quan hệ nhà thầu phụ / nhà cung cấp bên thứ 3 nào.

Suy luận sai mục tiêu

Những gì bạn muốn đo là chất lượng phần mềm. Những gì bạn làm đo lường là một hoặc nhiều số liệu.

Có một khoảng cách giữa những gì bạn đo lường và những gì bạn tin rằng nó sẽ cho bạn biết. Khoảng cách này là rất lớn thậm chí.

Nó xảy ra mọi lúc trong tất cả các loại hình kinh doanh xung quanh chúng ta. Bạn đã bao giờ thấy các quyết định dựa trên KPI (chỉ số hiệu suất chính) chưa? Đó chỉ là cùng một vấn đề - bạn muốn một công ty làm tốt, nhưng bạn đo lường một cái gì đó khác.

Lý luận bằng định lượng

Số liệu có thể được đo. Đó là lý do duy nhất chúng tôi đối phó với họ cả. Tuy nhiên, chất lượng phần mềm mở rộng vượt ra ngoài các thực thể có thể đo lường này và có rất nhiều thứ rất khó để định lượng: Mã nguồn có thể đọc được như thế nào? Làm thế nào mở rộng là thiết kế của bạn? Làm thế nào là khó khăn cho các thành viên nhóm mới để được lên tàu? Vân vân.

Đánh giá chất lượng phần mềm chỉ bằng các số liệu và nhắm mắt làm ngơ với các phần chất lượng mà bạn không thể định lượng chắc chắn sẽ không hoạt động tốt.

biên tập:

Tóm lược

Hãy để tôi chỉ ra rằng trên đây là tất cả về đánh giá khách quan xem phần mềm là tốt hay xấu dựa trên số liệu. Điều này có nghĩa, nó không nói bất cứ điều gì về việc và khi nào bạn nên áp dụng số liệu.

Trong thực tế, đây là một hàm ý đơn hướng: số liệu xấu ngụ ý mã xấu. Đơn hướng có nghĩa là mã xấu không đảm bảo số liệu xấu, cũng như số liệu tốt đảm bảo mã tốt. Mặt khác, điều này tự nó có nghĩa là bạn có thể áp dụng các số liệu để đánh giá một phần mềm - khi bạn giữ ý nghĩa này trong tâm trí.

Bạn đo phần mềm A, và các số liệu hóa ra thực sự tồi tệ. Sau đó, bạn có thể chắc chắn rằng chất lượng của mã là xấu. Bạn đo phần mềm B và các số liệu đều ổn, sau đó bạn không biết gì về chất lượng mã. Đừng dại dột nghĩ "metrics good = code good" khi nó thực sự chỉ là "code good => metrics good".

Về bản chất, bạn có thể sử dụng các số liệu để tìm các vấn đề về chất lượng, nhưng bản thân nó không phải là chất lượng.

Có, bạn có thể nói mã có vấn đề về chất lượng bằng cách xem số liệu ở một mức độ nào đó.

Cụ thể hơn, chạy một công cụ phân tích phức tạp trên cơ sở mã và bạn sẽ có ý tưởng về việc mã tốt hay xấu.

Ví dụ, bạn có thể chạy màn hình nguồn .

Điều này sẽ cho bạn biết mức độ phức tạp của mã. Tôi có thể nói với bạn mọi hệ thống có vấn đề mà tôi đã trải qua đều có những con số xấu. Độ phức tạp trên 10 đến 100 giây của các phương thức vượt quá giới hạn chấp nhận được. Những con số khủng khiếp. Sự phức tạp khủng khiếp, làm tổ, độ sâu, v.v ... Điều này sẽ dẫn đến rất nhiều vấn đề, tỷ lệ khuyết tật cao liên tục, khó thực hiện thay đổi, mà không phá vỡ một cái gì khác, v.v.

Một điều nữa là khuyết điểm. Theo thời gian hệ thống sẽ ổn định. Các khiếm khuyết mới lý tưởng nên có xu hướng về 0 hoặc làm phẳng đến một số thấp, điều đó có nghĩa là các khiếm khuyết mới và hiện tại sẽ giảm theo thời gian.

Cốt truyện sẽ trông giống như thế này:

Khiếm khuyết theo thời gian

Nếu chúng không đổi hoặc tăng thì phần mềm không tốt. Chỉ 4 tháng của bạn, vì vậy tôi sẽ cho nó thêm một vài tháng đến một năm. Sau 6 tháng đến một năm, nếu bạn có một dòng khiếm khuyết liên tục, thì đó là chất lượng kém. Nhóm của bạn đã phát triển một quả bóng bùn khác .

Tiếp theo kiểm tra. Bạn có chúng không? Nếu không thì chất lượng kém hơn, nhiều lỗi hơn, nhiều hơn. Nếu bạn có chúng, các số liệu như độ bao phủ của mã là tốt để có ý tưởng về số lượng mã được bảo hiểm, nhưng nó sẽ không đo lường được chất lượng . Tôi đã thấy số lượng bảo hiểm mã tuyệt vời nhưng các thử nghiệm thực tế là tào lao. Họ không kiểm tra bất kỳ hành vi hoặc chức năng nào của hệ thống. Các nhà phát triển chỉ viết chúng để cải thiện số liệu cho quản lý. Vì vậy, bạn phải có bài kiểm tra và họ phải giỏi. Bản thân các số liệu bảo hiểm mã không phải là một chỉ số về chất lượng.

Mã đánh giá, bạn đang thực hiện chúng? Nếu không, kém chất lượng. Điều này đặc biệt quan trọng với các nhà phát triển cơ sở. Nếu bạn thực hiện nhanh nhẹn, chỉ cần thêm một tác vụ đánh giá mã vào câu chuyện của bạn được gọi là "xem lại mã". Nếu quản lý muốn theo dõi số lượng, bạn sẽ cần một công cụ theo dõi các đánh giá như Crucible . Tôi nghĩ rằng các số liệu hoặc số liệu đánh giá mã không quan trọng ở đây ngoài việc chúng phải là một phần trong quy trình của bạn. Không phải mọi kiểm tra cần phải xem xét. Nhưng, đánh giá có thể giúp đảm bảo mọi người không phát minh lại bánh xe hoặc viết mã mà người khác không thể hiểu và / hoặc duy trì.

Cuối cùng, bạn sẽ phải đánh giá mã, không có số liệu nào có thể giúp vượt trội hơn. Mọi dự án mã có vấn đề đều có những phẩm chất sau:

• Cấu trúc dữ liệu kém. Mọi thứ là một chuỗi hoặc XML được truyền đi khắp mọi nơi và được phân tích cú pháp ở mọi nơi, các đối tượng thần hoặc các cấu trúc dữ liệu chung hoặc phức tạp không cần thiết, không có mô hình miền.
• Thiếu tổ chức hoặc cấu trúc, bất kỳ dự án không tầm thường nào cũng cần có một số phân chia hoặc phân lớp tách biệt logic. Hãy xem ở đây ... Nếu bạn không thấy kiểu tổ chức hoặc tách biệt này (pha trộn logic ở mọi nơi) thì hệ thống sẽ khó bảo trì và hiểu hơn.
• Quá trừu tượng. Đôi khi điều ngược lại là đúng, hệ thống được trừu tượng hóa quá mức. Nếu tất cả mọi thứ là một lớp giao diện và lớp trừu tượng hoặc bạn phải điều hướng qua một tấn các lớp loại "trình bao bọc", chất lượng sẽ rất tệ vì các nhà phát triển mới sẽ không thể điều hướng qua sự phình to của đối tượng.
• Khó hiểu mã. Nếu một nhà phát triển dày dạn kinh nghiệm của bạn và nếu bạn đang xem mã khó hiểu, nó sẽ có vấn đề về chất lượng. Số liệu cá nhân của tôi là nếu tôi đang xem mã và nó khó theo dõi hoặc khiến tôi cảm thấy ngớ ngẩn, hoặc tôi cảm thấy mình đang lãng phí rất nhiều chu kỳ não để tìm ra logic, thì đó là mã xấu. Nếu các nhà phát triển dày dạn có một thời gian khó theo dõi, thì hãy tưởng tượng nó sẽ như thế nào đối với các nhà phát triển mới hơn. Họ sẽ giới thiệu vấn đề.

Lời khuyên của tôi sẽ là chạy một phân tích phức tạp về mã. Đừng chia sẻ kết quả, thay vào đó hãy theo dõi kết quả để thực hiện một số điều tra độc lập (xem mã) và đưa ra quyết định về sức khỏe tổng thể của cơ sở mã. Từ đó, hình thành một kế hoạch hành động và thử khắc phục một số khu vực phức tạp của mã.

Điều đáng buồn với các số liệu là cuối cùng bạn có thể cải thiện các giá trị kết quả của số liệu của mình, nhưng không phải là chất lượng dự định được đo lường bởi chúng ...

Trong Visual Studio, có một cài đặt để xử lý các cảnh báo của trình biên dịch là lỗi. Bây giờ một số người không hiểu các cảnh báo và để có được mã được biên dịch, sẽ sử dụng các thủ thuật đơn giản (như cảnh báo vô hiệu hóa cảnh báo hoặc thêm từ khóa ọnew vào một chức năng / thuộc tính ẩn một thành viên không ảo của một cơ sở lớp học).

Nếu bạn có quyền truy cập vào mã nguồn, bạn có thể chạy phân tích mã tĩnh. Đối với các dự án .Net, bạn có thể sử dụng, ví dụ FxCop hoặc ReSharper InspectCode. Khi được sử dụng bởi nhóm phát triển một cách chính xác, các công cụ sẽ giúp cải thiện chất lượng. Nhưng tất nhiên, một số "sửa lỗi" để loại bỏ các cảnh báo mà không hiểu chúng là có thể.

Bạn có thể xem xét các bài kiểm tra tự động / UnitTests: mức độ bao phủ của mã tốt như thế nào? Nhưng riêng phạm vi bảo hiểm sẽ không cho bạn biết nếu các thử nghiệm thực sự kiểm tra mã hoặc chỉ thực hiện một lần.

Phấn đấu cho chất lượng cao là một thái độ, có thể được hỗ trợ bởi nhiều công cụ và số liệu của họ, nhưng số liệu mà không có thái độ của các nhà phát triển không giúp ích được gì.

Một điều bạn nên xem xét ngoài việc thu thập một số liệu như tiêm khiếm khuyết là tìm ra nguồn gốc của các khiếm khuyết. Thường thì nó có liên quan đến đặc điểm kỹ thuật.

Về cơ bản, là một lỗi trong đặc tả kỹ thuật, một sự mơ hồ trong việc speization, để cho bộ cấy quyết định hoặc đó là một lỗi trong việc thực hiện.

Một cách tiếp cận chất lượng hơn là hỏi phần mềm có hữu ích không? Nếu bạn đủ chăm chỉ, bạn có thể tìm thấy lỗi trong bất kỳ phần mềm nào. Tuy nhiên, nếu nó hoạt động đủ tốt để kiếm tiền, thì nó có thể không quá tệ.

Dưới cùng, không có cách nào để biết.

Đối với câu hỏi ban đầu (trước câu trả lời triết học): Sản phẩm phải làm là gì và nó có làm được không? Đo bằng số lượng khuyết tật / mật độ là không đủ. Tôi không thể biết đây là thư viện hay ứng dụng, cơ sở mã lớn như thế nào, miền có vấn đề lớn đến mức nào cũng như mức độ nghiêm trọng của lỗi. Ví dụ: không xử lý một trong 123 định dạng đầu vào có thể là một lỗi nhỏ hoặc một trình chặn hiển thị, tùy thuộc vào tầm quan trọng của định dạng không được xử lý đúng cách. Và tốt hơn là không có gì là một tiêu chuẩn cao.

Giả định tôi đưa ra cho câu hỏi này: Có sự khác biệt giữa Mã và Phần mềm. Tôi định nghĩa phần mềm là những gì khách hàng / người dùng sử dụng để giải quyết vấn đề, trong khi mã là vật liệu xây dựng của phần mềm.

Phần mềm chỉ có thể được đo lường một cách chủ quan. Đó là, số liệu quan trọng đối với phần mềm là liệu mọi người có sử dụng nó để giải quyết vấn đề hay không. Số liệu này phụ thuộc vào hành vi của người khác, do đó nó chủ quan. Lưu ý: Đối với một số vấn đề, một phần mềm có thể khá hữu ích và do đó được coi là chất lượng cao (Excel để tính toán), nhưng không phải là phần mềm chất lượng cho một vấn đề khác (Excel để phát tệp MP3).

Mã có thể (thường) được đo bằng các số liệu thực nghiệm . Nhưng việc giải thích không phải là 'có / không' đối với chất lượng, hoặc thậm chí thực sự ở thang điểm '0 đến N'. Số liệu đo theo tiêu chuẩn. Vì vậy, các số liệu có thể tìm thấy các lĩnh vực quan tâm được xác định theo tiêu chuẩn, nhưng sự vắng mặt của các lĩnh vực quan tâm không phải là bằng chứng cho thấy đây là mã chất lượng. Ví dụ: số liệu hữu ích: Nó có biên dịch không? Không -> Không chất lượng. Có -> ???. Nó có vượt qua bài kiểm tra đơn vị không? Không? Có lẽ? (bởi vì, có phải là Mã chất lượng kiểm tra đơn vị không?), Có -> ???.

Vì vậy, giống như Bằng chứng không đầy đủ của Godel cho thấy các tiên đề của toán học (nghĩa là tồn tại các phát biểu toán học không thể được chứng minh là đúng hay sai đối với bất kỳ tập tiên đề hữu hạn nào), tôi không nghĩ chúng ta thực sự có thể trả lời 'là chất lượng này mã? cho mỗi đoạn mã Theo trực giác, có lẽ có một ánh xạ trong đó giữa các số liệu phần mềm để trả lời các tiên đề chất lượng và toán học để trả lời có thể chứng minh đúng hoặc sai.

Một cách khác để đưa ra lập luận này, là bước vào ngôn ngữ tự nhiên. William Shakespeare, Lewis Carroll và Mark Twain đều là những nhà văn thành công và được nhiều người yêu mến vì chất lượng bài viết của họ. Tuy nhiên, tiêu chuẩn ngữ pháp, từ vựng, phong cách hoặc giọng nói nào chúng ta có thể áp dụng sẽ luôn đánh giá chúng cao hơn so với học sinh lớp 12 ngẫu nhiên? Và, trong khi có thể tạo ra một số biện pháp tổng hợp cho ba người đó, làm thế nào để đánh giá Sách John (KJV), JRR Tolkien, Homer, Cervantes, v.v? Sau đó ném vào Burroughs, Faulkner, Hemingway, Sylvia Plath, v.v. Số liệu sẽ không hoạt động.

Tôi sẽ đo lường điều này bằng cách kiểm tra (và tìm kiếm độ lệch trong) quá trình của họ.

Tôi sẽ tìm kiếm bằng chứng về một quy trình để cung cấp kiểm soát nguồn trung tâm, hệ thống xây dựng trung tâm và một quy trình đảm bảo mã được kiểm tra trước khi tích hợp vào chi nhánh được phát hành.

Tôi cũng sẽ tìm kiếm bằng chứng về cách họ đã sửa đổi các quy trình của họ để đáp ứng với các tình huống mà các khiếm khuyết đã qua trong quá trình phát hành của họ.

Nếu họ không thể vượt qua mức kiểm toán này, thì bạn không thể mong đợi họ cung cấp các bản phát hành đáng tin cậy nhất quán.

Nếu họ vượt qua cuộc kiểm toán này và liên tục cải tiến quy trình thì tính nhất quán của sản phẩm có thể sẽ được cải thiện theo thời gian.

Nếu điều này không khắc phục được thì có khả năng họ gặp vấn đề về kiến ​​trúc mã khiến việc mở rộng và kiểm tra cơ sở mã hiện tại của họ có vấn đề, trong trường hợp đó không có tùy chọn tốt.

Nếu bạn đang tìm kiếm các phép đo hoàn toàn tự động, thì tôi khuyên bạn nên những người này: Nhóm cải tiến phần mềm

Về cơ bản, đây là tổng hợp các số liệu khác nhau có thể được trích xuất tự động từ mã nguồn (như, phạm vi kiểm tra đơn vị, kích thước chức năng, vướng víu lớp, trùng lặp, LỘC, v.v.). Những giá trị này sau đó được chuyển đổi thành xếp hạng 1-5 sao.

Họ cũng có một cuốn sách hay mô tả tất cả các số liệu của họ trong thực tế đáng để đọc: 'Xây dựng phần mềm bảo trì' .