Là một phần của đánh giá tất cả các mô tả công việc, công ty của tôi đã quyết định đưa vào đây như một đầu ra quan trọng:

phát triển trang web hoàn thành đúng thời hạn, trong phạm vi đặc điểm kỹ thuật và không có lỗi

Do các thông số kỹ thuật thay đổi thường xuyên, không có quá trình kiểm soát thay đổi chính thức và môi trường, chúng ta sẽ nói, một chút không thể đoán trước, KPI này thực tế và hợp lý như thế nào?

"Lỗi miễn phí" là quá chủ quan . "Yêu cầu tính năng chưa hoàn thành" của một người là "Lỗi" của một người khác. Một cái gì đó như "Nếu đáp ứng đáng kể thông số kỹ thuật thiết kế" sẽ phù hợp hơn. Tôi chưa bao giờ thực sự thấy những gì bạn mô tả trong một mô tả công việc. Tôi đã thấy nó cho công việc hợp đồng , nhưng không phải cho nhân viên.

Tôi sẽ có một vị trí đối lập với hầu hết các câu trả lời và nói rằng nó hoàn toàn hợp lý và thực tế.

Tất cả sự phát triển sẽ được hoàn thành đúng hạn? Tất nhiên là không, không phải lúc nào cũng vậy.

Tất cả sự phát triển sẽ được hoàn thành trong đặc điểm kỹ thuật? Bạn muốn hy vọng như vậy, nhưng đôi khi điều đó đơn giản là không thể và bạn sẽ phải đánh dấu sự sai lệch khỏi một thông số không thể hoặc tự mâu thuẫn.

Và tất cả sự phát triển sẽ không có lỗi? Không bao giờ .

Nhưng đó là những gì KPI dành cho. Đó là thứ có thể đo lường được và qua đó bạn có thể theo dõi hiệu suất và tiến độ.

Nếu thông số kỹ thuật thay đổi thường xuyên, không có quy trình kiểm soát thay đổi chính thức và môi trường không thể đoán trước, thì sẽ là một thách thức để giữ con số này gần với "không có lỗi". Nhưng thách thức đó là công việc của bạn và đó là công việc mà bạn hy vọng sẽ làm khá tốt - và thậm chí tốt hơn vào năm tới, khi bạn có nhiều thực hành hơn trong việc quản lý hương vị hỗn loạn đặc biệt của công ty bạn.

Câu hỏi truy cập: KPI nào bạn sẽ đề xuất cho một lập trình viên? Đó là một khó khăn. Rất nhiều điều chúng tôi làm là khó đo lường.

Nếu đó là một mô tả công việc, thì tôi sẽ không lo lắng quá nhiều về nó vì làm việc với mã không có lỗi là một phần của công việc của một lập trình viên điển hình (ngay cả khi chúng ta không bao giờ có thể đạt được nó).

Tuy nhiên, với tư cách là một KPI, nó quá xa vời, nhưng đừng đổ lỗi cho người đã đề xuất nó nếu họ không phải là lập trình viên. Chỉ cần giải thích rằng tuyên bố đó đặt ra một mục tiêu có thể là không mong muốn cho tổ chức. Đó là, "không có lỗi" là một tiêu chuẩn cực kỳ cao đối với phần mềm sẽ tốn rất nhiều tiền để thực sự cung cấp. Giải thích rằng một dự án phần mềm chạy tốt đòi hỏi phải đưa ra quyết định về việc mỗi lỗi có đáng để dành thời gian cho nhà phát triển có giá trị hay không.

Đây là một ví dụ làm cho điểm độc đáo.
Một lập trình viên phát hiện ra rằng phần mềm của chúng tôi có lỗi "năm 3000" và sẽ ngừng hoạt động sau ngày 31 tháng 12 năm 1999. Sẽ mất 6-8 tháng để khắc phục sự cố. Dựa trên KPI được khuyến khích đảm nhận dự án này mặc dù không có giá trị thực sự cho công ty.

Được rồi, vì vậy, ví dụ đó là một chút cực đoan, nhưng trong bất kỳ dự án phần mềm nào, sẽ có hàng tá lỗi nhỏ được phát hiện ra rằng tương tự không tạo ROI cần thiết để sửa chúng. Thay vào đó, nếu KPI được dự định ngụ ý rằng lập trình viên không bao giờ đưa ra lỗi ở vị trí đầu tiên, thì có vẻ hợp lý khi BẤT K staff nhân viên nào được giữ theo tiêu chuẩn không bao giờ phạm sai lầm trong việc thực hiện công việc của họ?

Không

Không chỉ là không phù hợp, nó là lố bịch

Việc kiểm tra chỉ có thể chứng minh sự tồn tại của lỗi chứ không phải sự vắng mặt của chúng, vì vậy mọi chương trình được viết theo cam kết này sẽ phải bao gồm một bằng chứng nghiêm ngặt về tính đúng đắn ... và phạm vi kiểm tra 100%

"Hãy coi chừng các lỗi trong đoạn mã trên; tôi chỉ chứng minh nó đúng, không thử nó." - D. Knuth

Tất nhiên, đó là công việc của mỗi lập trình viên và trách nhiệm, viết mã không có lỗi. Đó là một kỳ vọng hoàn toàn hợp lý. Làm thế nào bạn có thể trở thành một lập trình viên chuyên nghiệp nếu bạn phát hành mã không hoạt động? Làm thế nào bạn có thể coi mình là một lập trình viên chuyên nghiệp nếu bạn phát hành mã mà bạn không biết làm việc?

Nếu bạn thuê một họa sĩ, bạn mong đợi anh ta sẽ làm tốt công việc của mình. Bạn mong đợi kết quả công việc của mình không có lỗi. Nếu có lỗi, bạn mong anh ấy chịu trách nhiệm về những lỗi đó và sửa chúng miễn phí. Hơn nữa, nếu các lỗi làm bạn mất tiền, bạn mong đợi anh ta bồi hoàn cho bạn. Tại sao bạn có những kỳ vọng này? Bởi vì họa sĩ là một chuyên gia.

Các lập trình viên thích đổ lỗi cho những người khác về lỗi của họ. "Chương trình của tôi có lỗi vì yêu cầu hoặc vì lịch trình hoặc vì Mặt trăng ở nhà thứ 8" Nhưng thực sự không có ai để đổ lỗi. Nếu chương trình của bạn có lỗi, bạn đặt chúng ở đó.

Nghề nghiệp của chúng tôi sẽ không bao giờ là một nghề cho đến khi các lập trình viên nhận ra rằng sự cố dừng lại với họ. Rằng họ chịu trách nhiệm về chất lượng của các chương trình của họ.

Bạn có biết tại sao các công ty tạo ra các bộ phận QA Phần mềm không? Bởi vì các lập trình viên không làm việc của họ! Các lập trình viên đã phát hành rất nhiều chuyện tào lao đến nỗi các công ty phải thành lập các bộ phận hoàn toàn mới để kiểm tra chúng.

Danh sách lỗi dài bao nhiêu? Nó là chuyên nghiệp để có hàng ngàn lỗi trong cơ sở dữ liệu lỗi? Rõ ràng là không. Đó là sự phản ánh của hành vi xấu, kỷ luật kém, và, thẳng thắn, thiếu trung thực.

Chúng tôi sẽ không bao giờ là một nghề cho đến khi chúng tôi nhận ra rằng đó là công việc của chúng tôi để đảm bảo rằng QA không tìm thấy gì.

Đáng buồn thay, điều này nghe có vẻ như là một cách để họ "bao gồm tất cả các cơ sở", và rõ ràng là không được khuyến khích và có khả năng chỉ gây ra sự vỡ mộng trong các nhà phát triển.

Tuy nhiên, đã nói rằng, điều này thực sự chỉ quan trọng khi bạn thấy những gì họ làm với văn bản đó trong thời gian xem xét. Vì vậy, đừng phản ứng thái quá quá nhanh - vẫn có thể có sự tỉnh táo ở cuối đường hầm.

"Không có lỗi" như trong "hoàn hảo?" Như trong "được viết bởi Thiên Chúa và các thiên thần, không phải con người?" (chúng ta đang nói ở đây về logic chương trình và có thể lỗi logic phần cứng)

Tôi không thể nói một cách trung thực về ngay cả một dòng mã mà nó không có lỗi. Đó là bởi vì con người chúng ta, tốt, chúng ta không thể chứng minh không có giả thuyết tiêu cực!

Điều tốt nhất tôi có thể nói là xác suất xảy ra lỗi là một số trong khoảng từ 0 đến 1. Tôi đạt được con số đó bằng các nguyên tắc kiểm tra và phát triển phần mềm được xác định rõ hoặc không rõ ràng hoặc không hiểu rõ; bởi một số lượng các dòng phần mềm nguồn trong câu hỏi; bởi sự hiểu biết về việc ứng cử viên của tôi tốt hay kém, mutt nghèo, áp dụng những nguyên tắc đó trong việc tạo ra những dòng mã đó; và nhiều hơn nữa.

Và tôi có thể diễn đạt sự hiểu biết đó chỉ như một xác suất. Vì vậy, thuật ngữ "không có lỗi" có nghĩa là gần như không có gì.

Nếu tôi thấy quảng cáo cho một kỹ sư phần mềm sản xuất mã "không có lỗi" tôi sẽ áp dụng ngay hoặc tôi sẽ chạy ngay: công ty đã không nghĩ nhiều về cách phát triển, kiểm tra và cung cấp phần mềm của mình . Vì vậy, nó sẽ là một cơ hội tuyệt vời hoặc một cơn ác mộng bất tận.

Mặc dù vậy, trong bất kỳ phần mềm nào, tôi có thể dễ dàng - và phải - nói rằng tôi mong đợi mã không có lỗi nằm ngoài công cụ logic, lờ mờ, logic này: mã biên dịch và liên kết mà không có lỗi hoặc cảnh báo; đó là "html hợp lệ" hoặc "css hợp lệ"; JavaScript (giả sử) tạo ra không có thông báo lỗi không giải thích được hoặc lỗi trình duyệt. Phần đó tôi có thể đo trực tiếp và đánh dấu màu đen và trắng trên biểu đồ.

Phần đó dễ như ăn bánh. Bất cứ ai cũng có thể làm điều đó .

Xin chào, chúc may mắn trong tìm kiếm của bạn :-)

Tôi có ngu ngốc không, hay "lỗi" không có nghĩa là "thông điệp trình biên dịch gây tử vong lên tới mã không thể biên dịch được"?

Theo định nghĩa đó, đó là một yêu cầu rất hợp lý ...