Làm thế nào để trở thành một lập trình viên không có lỗi? [đóng cửa]

Sếp của tôi đã luôn nói với tôi rằng một lập trình viên giỏi sẽ có thể đảm bảo rằng mã mà anh ta hoặc cô ta thay đổi là đáng tin cậy, chính xác và tự xác minh kỹ lưỡng; rằng bạn nên hoàn toàn hiểu tất cả các kết quả và tác động mà những thay đổi của bạn sẽ gây ra. Tôi đã cố gắng hết sức để trở thành loại lập trình viên này bằng cách thử nghiệm lại nhiều lần nhưng các lỗi vẫn còn đó.

Làm cách nào tôi có thể trở thành một lập trình viên không có lỗi và biết mọi ký tự trong mã của tôi sẽ gây ra và ảnh hưởng gì?

Đừng bao giờ viết mã.

Đó là cách duy nhất bạn có thể trở thành một lập trình viên không có lỗi.

Lỗi là không thể tránh khỏi bởi vì các lập trình viên là con người, tất cả những gì chúng ta có thể làm là cố gắng hết sức để ngăn chặn chúng, phản ứng nhanh khi xảy ra lỗi, học hỏi từ những sai lầm của chúng ta và cập nhật.

Không có lỗi là không thể đối với một chương trình không tầm thường.

Có thể đến rất gần, nhưng năng suất bị ảnh hưởng. Và nó chỉ đáng giá cho một số phần mềm rủi ro cao. Phần mềm tàu ​​con thoi đến với tâm trí của tôi. Nhưng năng suất của họ là một vài dòng một ngày. Tôi nghi ngờ ông chủ của bạn muốn điều đó.

Phần mềm này không có lỗi. Nó là hoàn hảo, hoàn hảo như con người đã đạt được. Hãy xem xét các số liệu thống kê này: ba phiên bản cuối cùng của chương trình - mỗi phiên bản dài 420.000 dòng - chỉ có một lỗi. 11 phiên bản cuối cùng của phần mềm này có tổng cộng 17 lỗi.

Hãy nâng cấp phần mềm để cho phép tàu con thoi điều hướng với Vệ tinh định vị toàn cầu, một thay đổi chỉ liên quan đến 1,5% chương trình, hoặc 6.366 dòng mã. Các thông số kỹ thuật cho một thay đổi đó chạy 2.500 trang, dày hơn một cuốn sách điện thoại. Các thông số kỹ thuật cho chương trình hiện tại điền 30 tập và chạy 40.000 trang.

"Lập trình viên không có lỗi" là một oxymoron, giống như một ca sĩ thầm lặng, nhưng hơn 60 năm lập trình đã tạo ra một số trí tuệ chắt lọc, sẽ giúp bạn trở thành một lập trình viên giỏi hơn, chẳng hạn như:

• Hãy khiêm tốn - bạn đang và sẽ phạm sai lầm. Nhiều lần.
• Hãy nhận thức đầy đủ về kích thước hạn chế của hộp sọ của bạn. Tiếp cận nhiệm vụ với sự khiêm tốn đầy đủ, và tránh các thủ thuật thông minh như bệnh dịch hạch. [Edsger Dijkstra]
• Chống nổ tổ hợp
• Loại bỏ trạng thái đột biến (bất cứ khi nào có thể). Vâng, học lập trình chức năng.
• Giảm số lượng đường dẫn mã có thể
• Hiểu (độ lớn) kích thước của không gian đầu vào và đầu ra (của các chức năng của bạn) và cố gắng giảm chúng để tiến gần hơn đến phạm vi kiểm tra 100%
• Luôn cho rằng mã của bạn không hoạt động - chứng minh bằng cách khác!

TDD

Quan điểm của TDD là bạn không viết một dòng mã nếu không có bài kiểm tra nào yêu cầu dòng mã đó. Và để đưa nó đến cực điểm, bạn luôn bắt đầu phát triển một tính năng mới bằng cách viết một bài kiểm tra chấp nhận. Ở đây tôi đã thấy rằng viết bài kiểm tra phong cách dưa chuột là lý tưởng.

Phương pháp TDD mang lại ít nhất hai lợi ích.

• Tất cả các mã được viết để giải quyết một tính năng cụ thể, do đó không có sản xuất thừa không cần thiết.
• Bất cứ khi nào bạn thay đổi một dòng mã hiện có, nếu bạn phá vỡ một tính năng, bạn sẽ được thông báo

Nó không chứng minh được lỗi không, vì điều đó là không thể (đã được chỉ ra bởi vô số câu trả lời khác). Nhưng sau khi học TDD và trở nên giỏi về nó (vâng, đó cũng là một kỹ năng cần thực hành), tôi có sự tự tin cao hơn nhiều về mã của mình vì nó đã được kiểm tra kỹ lưỡng. Và quan trọng hơn, tôi có thể thay đổi mã hiện tại mà tôi không hoàn toàn hiểu mà không lo bị hỏng chức năng.

Nhưng TDD không giúp bạn tất cả các cách. Bạn không thể viết mã không có lỗi nếu bạn không hiểu kỹ kiến ​​trúc của hệ thống và những cạm bẫy của kiến ​​trúc đó. Ví dụ: nếu bạn đang viết một ứng dụng web xử lý đồng thời nhiều yêu cầu, bạn phải biết rằng bạn không thể chia sẻ dữ liệu có thể thay đổi giữa nhiều yêu cầu (không rơi vào bẫy người mới để lưu trữ dữ liệu có thể thay đổi để cải thiện hiệu suất).

Tôi tin rằng các nhóm phát triển giỏi TDD cung cấp mã với ít lỗi nhất.

Vấn đề là, lỗi là những thứ mà bạn không nhận ra. Trừ khi bạn có một số loại kiến ​​thức bách khoa về ngôn ngữ lập trình / trình biên dịch cũng như tất cả các môi trường mà ứng dụng của bạn sẽ chạy, bạn thực sự không thể mong đợi tạo ra mã không có lỗi 100%.

Bạn có thể giảm số lượng lỗi của mình thông qua rất nhiều thử nghiệm, nhưng cuối cùng có thể sẽ có một số trường hợp bên lề sẽ không được tính đến. Joel Spolsky đã viết một bài viết đặc biệt hay về sửa lỗi .

Có, không thể không bao giờ có lỗi trong mã của bạn nhưng không thể có ít lỗi hơn. Thái độ "Thật ngu ngốc, Bạn sẽ luôn có lỗi" chỉ là một cảnh sát để tránh làm giảm số lượng lỗi trong mã của bạn. Không ai hoàn hảo nhưng chúng ta có thể và nên phấn đấu để trở nên tốt hơn. Trong nỗ lực cải thiện của riêng tôi, tôi đã tìm thấy những điểm sau hữu ích.

• Điều này không dễ dàng. Bạn sẽ không cải thiện qua đêm. Vì vậy, đừng nản lòng và đừng bỏ cuộc.
• Viết ít hơn và viết thông minh hơn. Mã ít hơn thường là mã tốt hơn. Thật tự nhiên khi bạn muốn lập kế hoạch trước và cố gắng tạo ra các mẫu thiết kế tuyệt vời nhưng về lâu dài chỉ cần viết những gì bạn cần sẽ tiết kiệm thời gian và ngăn ngừa lỗi.
• Phức tạp là kẻ thù. Ít hơn không được tính nếu đó là một mớ hỗn độn phức tạp tối nghĩa. Code golf là niềm vui nhưng đó là địa ngục để hiểu và là một địa ngục tồi tệ hơn để gỡ lỗi. Bất cứ khi nào bạn viết mã phức tạp, bạn sẽ tự mở ra một thế giới có vấn đề. Giữ mọi thứ đơn giản và ngắn gọn.
• Phức tạp là chủ quan. Mã đã từng phức tạp trở nên đơn giản một khi bạn trở thành một lập trình viên giỏi hơn.
• Vấn đề kinh nghiệm. Một trong hai cách để trở thành một lập trình viên tốt hơn là thực hành. Thực hành KHÔNG phải là viết các chương trình mà bạn biết cách viết một cách dễ dàng, đó là viết các chương trình gây tổn thương đôi chút và khiến bạn phải suy nghĩ.
• Cách khác để tốt hơn là đọc. Có rất nhiều chủ đề khó trong lập trình để học nhưng bạn sẽ không bao giờ có thể học chúng nếu chỉ lập trình, bạn cần nghiên cứu chúng. Bạn cần phải đọc những thứ khó khăn. Những thứ như bảo mật và đồng thời là không thể, nó học chính xác từ việc chỉ viết mã trừ khi bạn muốn học bằng cách dọn dẹp thảm họa. Nếu bạn không tin tôi hãy nhìn vào các trang web vấn đề bảo mật hoành tráng như gawker đã có. Nếu họ dành thời gian để học cách bảo mật một cách chính xác và không chỉ tạo ra thứ gì đó hoạt động mà mớ hỗn độn đó sẽ không bao giờ xảy ra.
• Đọc blog. Có rất nhiều blog thú vị ngoài kia sẽ cung cấp cho bạn những cách mới và thú vị để xem và suy nghĩ về lập trình, điều này sẽ giúp bạn ...
• Tìm hiểu các chi tiết bẩn. Các chi tiết nhỏ về cách các phần tối nghĩa của ngôn ngữ và ứng dụng của bạn hoạt động là rất quan trọng. Họ có thể giữ bí mật giúp bạn tránh viết mã phức tạp hoặc có thể là những phần có lỗi riêng bạn cần tránh.
• Tìm hiểu cách người dùng nghĩ. Đôi khi người dùng của bạn tỏ ra điên rồ và sẽ làm việc với ứng dụng của bạn theo những cách bạn không hiểu và không thể dự đoán. Bạn cần phải đi vào đầu họ đủ để biết những điều lạ mà họ có thể thử và đảm bảo ứng dụng của bạn có thể xử lý nó.

Cá nhân tôi nghĩ rằng việc phấn đấu để lập trình không có lỗi dường như tốn kém hơn (cả về thời gian và tiền bạc). Để đạt được lỗi không, hoặc thậm chí lỗi gần như bằng không, bạn cần phải kiểm tra kỹ lưỡng các nhà phát triển. Điều này có nghĩa là kiểm tra hồi quy mọi thứ trước khi gửi bất kỳ mã nào để xem xét bản vá. Mô hình này không tấn công tôi là hiệu quả chi phí. Tốt hơn hết là bạn nên nhờ các nhà phát triển tiến hành kiểm tra chuyên sâu và để thử nghiệm chuyên sâu cho nhóm QA. Đây là lý do tại sao:

• Các nhà phát triển hút thử nghiệm. Đó là sự thật và bạn biết điều đó. (Tôi là một nhà phát triển!) Một nhóm QA giỏi sẽ luôn tìm thấy các trường hợp cạnh mà các nhà phát triển không bao giờ nghĩ tới.
• Các nhà phát triển giỏi về mã hóa. Hãy để họ quay lại với những gì họ nổi trội (và thường là những gì họ thích làm hơn nữa.)
• Nhóm QA có thể tìm thấy các lỗi liên quan đến nhiều nhiệm vụ của nhà phát triển trong một lần.

Chấp nhận rằng khi bạn viết mã, sẽ có lỗi đăng nhập vào nó. Đó là lý do tại sao bạn có quy trình QA và đó là một phần của việc trở thành nhà phát triển. Tất nhiên, điều này không có nghĩa là bạn gửi thứ gì đó ngay khi bạn viết dấu chấm phẩy cuối cùng. Bạn vẫn cần đảm bảo chất lượng trong công việc, nhưng bạn có thể làm quá sức.

Bạn có thể đặt tên cho bao nhiêu ngành nghề luôn hoàn thành nhiệm vụ ngay lần đầu tiên mà không cần đánh giá và / hoặc kiểm tra?

Không có lỗi? Có vẻ như bạn cần Lisp (đi theo con đường hoài nghi và tránh video âm nhạc).

Rất khó để đạt được mã không có lỗi trong các môi trường mã hóa chính (Java, C #, PHP, v.v.). Tôi sẽ tập trung vào việc sản xuất mã được kiểm tra và đánh giá ngang hàng trong các lần lặp được kiểm soát ngắn.

Giữ mã đơn giản như bạn có thể sẽ giúp bạn tránh lỗi.

Đảm bảo rằng bạn đang sử dụng các công cụ phân tích mã (như FindBugs , PMD , v.v.) - kết hợp với các cảnh báo trình biên dịch nghiêm ngặt - sẽ tiết lộ tất cả các loại vấn đề với mã của bạn. Hãy lưu ý những gì họ đang nói với bạn, thực sự nỗ lực để hiểu bản chất của lỗi là gì, và sau đó thực hiện các bước để thay đổi thành ngữ lập trình của bạn để cảm thấy không tự nhiên khi viết mã theo cách giới thiệu lại lỗi đó.

Tất cả "Không mã nào cả." câu trả lời là hoàn toàn thiếu điểm. Ngoài ra, ông chủ của bạn dường như không phải là một kẻ ngốc!

Tôi không thể nhớ lại tần suất tôi đã thấy các lập trình viên đơn giản là không biết mã của họ làm gì. Philosohpy phát triển duy nhất của họ dường như là thử nghiệm và lỗi (và thường cũng sao chép / dán / sửa đổi). Mặc dù bản dùng thử và lỗi là một cách hợp lệ để giải quyết một số vấn đề, nhưng bạn thường có thể phân tích miền vấn đề và sau đó áp dụng một giải pháp rất cụ thể dựa trên hiểu biết của bạn về các công cụ bạn sử dụng và với một chút kỷ luật và siêng năng bạn sẽ không chỉ giải quyết vấn đề mà còn hầu hết các trường hợp góc (lỗi tiềm ẩn) trước khi bạn triển khai lần đầu tiên. Bạn có thể đảm bảo rằng mã là không có lỗi? Dĩ nhiên là không. Nhưng với mỗi lỗi bạn gặp phải hoặc đọc về bạn, bạn có thể thêm nó vào những điều bạn có thể muốn nghĩ về lần tới khi bạn viết / thay đổi điều gì đó. Nếu bạn làm điều này, do đó bạn sẽ có được nhiều kinh nghiệm về cách viết mã gần như không có lỗi. - Có rất nhiều tài nguyên có sẵn về cách trở thành một lập trình viên tốt hơn có thể giúp bạn trên hành trình ...

Cá nhân, tôi sẽ không bao giờ cam kết mã nơi tôi không thể giải thích từng dòng. Mỗi dòng có một lý do để ở đó, nếu không nó nên được gỡ bỏ. Tất nhiên đôi khi bạn sẽ đưa ra các giả định về hoạt động bên trong của các phương thức bạn gọi, nếu không bạn sẽ cần phải biết logic bên trong của toàn bộ khung.

Sếp của bạn hoàn toàn đúng khi nói rằng bạn nên hiểu kết quả và tác động của mã bạn viết trên hệ thống hiện có. Lỗi sẽ xảy ra? Phải, tất nhiên. Nhưng những lỗi này sẽ là do sự hiểu biết chưa đầy đủ của bạn về hệ thống / công cụ bạn làm việc và với mỗi lần sửa lỗi, bạn sẽ có phạm vi bảo hiểm tốt hơn.

Như các ý kiến ​​khác đã chỉ ra một cách chính xác, không có phần mềm không tầm thường mà không có lỗi.

Nếu bạn muốn kiểm tra phần mềm luôn luôn ghi nhớ, các kiểm tra đó chỉ có thể chứng minh sự hiện diện của các lỗi chứ không phải sự vắng mặt của chúng.

Tùy thuộc vào miền công việc của bạn, bạn có thể thử xác minh chính thức phần mềm của mình. Sử dụng các phương thức chính thức, bạn có thể trở nên khá chắc chắn rằng phần mềm của bạn đáp ứng chính xác đặc điểm kỹ thuật.

Điều đó không có nghĩa là phần mềm chính xác làm những gì bạn muốn. Viết một đặc điểm kỹ thuật hoàn chỉnh là trong hầu hết các trường hợp cũng không thể. Về cơ bản, nó chuyển nơi xảy ra lỗi từ khi thực hiện sang đặc tả.

Vì vậy, tùy thuộc vào định nghĩa của bạn về "lỗi", bạn có thể thử xác minh chính thức hoặc chỉ cần cố gắng tìm nhiều lỗi nhất có thể trong phần mềm của mình.

Không viết bất cứ điều gì phức tạp hơn "Xin chào thế giới!" hoặc nếu bạn nói với tất cả mọi người không bao giờ sử dụng nó.

Hỏi sếp của bạn về một số ví dụ về điều này được gọi là mã không có lỗi.

Tôi đồng ý với những người khác. Đây là cách tôi sẽ tiếp cận vấn đề

• Nhận một người kiểm tra. Xem thử nghiệm Joel để biết lý do tại sao.
• Sử dụng thư viện rộng rãi; có lẽ đã được gỡ lỗi tốt hơn. Tôi là một fan hâm mộ lớn của CPAN cho Perl.

Bạn có thể phấn đấu để trở thành một lập trình viên không lỗi. Tôi cố gắng trở thành một lập trình viên không có lỗi mỗi khi tôi viết mã. Tuy nhiên, tôi không

• tham gia nhiều kỹ thuật kiểm tra (khác ATDD)
• tạo xác minh chính thức của phần mềm của chúng tôi
• có một nhóm QA riêng
• phân tích cứng trên từng thay đổi được thực hiện cho cơ sở mã
• sử dụng một ngôn ngữ dựa nhiều hơn vào sự an toàn và thận trọng

Tôi không làm những việc này vì chúng rất tốn kém cho phần mềm tôi viết. Nếu tôi làm những điều này có lẽ tôi sẽ tiến xa hơn tới các lỗi không, nhưng nó sẽ không có ý nghĩa kinh doanh.

Tôi tạo các công cụ nội bộ mà một phần lớn cơ sở hạ tầng của chúng tôi sử dụng. Tiêu chuẩn của tôi để thử nghiệm và mã hóa là cao. Tuy nhiên, có một sự cân bằng. Tôi không mong đợi không có lỗi vì tôi không thể khiến mọi người bỏ thời gian đó vào một công việc. Mọi thứ có thể khác nếu tôi tạo phần mềm để điều khiển máy X-Ray, động cơ phản lực, v.v. Không có cuộc sống nào xảy ra nếu phần mềm của tôi bị hỏng, vì vậy chúng tôi không tham gia vào mức độ đảm bảo đó.

Tôi sẽ phù hợp với mức độ đảm bảo với mục đích sử dụng của phần mềm. Nếu bạn đang viết mã mà tàu con thoi của NASA sẽ sử dụng có thể không dung sai lỗi là hợp lý. Bạn chỉ cần thêm một loạt các thực hành bổ sung và rất tốn kém.

Tôi nghĩ rằng bước đầu tiên tốt để trở thành một lập trình viên "không có lỗi" là thay đổi thái độ của bạn đối với các lỗi. Thay vì nói những điều "chúng xảy ra", "hãy kiểm tra QA và người kiểm tra tốt hơn" hoặc "nhà phát triển không thử nghiệm", hãy nói:

Lỗi không được chấp nhận và tôi sẽ làm mọi thứ trong khả năng của mình để loại bỏ chúng.

Một khi điều này trở thành thái độ của bạn, các lỗi sẽ giảm nhanh chóng. Trong tìm kiếm của bạn để tìm cách loại bỏ lỗi, bạn sẽ bắt gặp sự phát triển dựa trên thử nghiệm. Bạn sẽ tìm thấy nhiều sách, bài đăng trên blog và mọi người cung cấp lời khuyên miễn phí về các kỹ thuật tốt hơn. Bạn sẽ thấy tầm quan trọng của việc cải thiện kỹ năng của mình thông qua thực hành (như mã hóa katas, hoặc thử những điều mới ở nhà). Bạn sẽ bắt đầu thực hiện công việc tốt hơn vì bạn sẽ bắt đầu làm việc với nghề của mình ở nhà. Và, hy vọng, một khi bạn thấy rằng nó là tốt để viết phần mềm tốt, niềm đam mê của mình cho nghề của bạn sẽ phát triển.

Theo một nghĩa nào đó, ông chủ của bạn là đúng. Có thể viết phần mềm tiếp cận các lỗi không.

Nhưng vấn đề là chi phí để viết các chương trình không có lỗi (gần như) là rất cao . Bạn cần làm những việc như:

• Sử dụng thông số kỹ thuật chính thức của các yêu cầu của bạn. Chính thức, như sử dụng Z hoặc VDM hoặc một số ký hiệu âm thanh toán học khác.

• Sử dụng các kỹ thuật chứng minh định lý để chính thức chứng minh rằng chương trình của bạn thực hiện các đặc tả.

• Tạo các bộ kiểm tra đơn vị, hồi quy và hệ thống mở rộng và khai thác để kiểm tra mọi cách tìm lỗi. (Và điều này là không đủ trong chính nó.)

• Có nhiều người xem xét các yêu cầu (chính thức và không chính thức), phần mềm (và bằng chứng). thử nghiệm, và triển khai.

Điều cực kỳ khó xảy ra là sếp của bạn sẵn sàng trả tiền cho tất cả những điều này ... hoặc đưa ra thời gian cần thiết để làm tất cả.

Tôi đã đạt được trạng thái "không lỗi". Tôi nói với người dùng của mình đó là một tính năng chưa được ghi lại hoặc họ đang yêu cầu một tính năng mới và do đó nó là một tính năng nâng cao. Nếu cả hai điều này không được chấp nhận, tôi chỉ nói với họ rằng họ không hiểu yêu cầu của họ. Như vậy, không có lỗi. Lập trình viên là hoàn hảo.

Đây là các bước để tạo ra một chương trình miễn phí lỗi:

1. Không bao giờ bắt đầu mã hóa trừ khi bạn có THÔNG SỐ KỸ THUẬT UNAMBIGUOUS cho chức năng của mình.
2. KHÔNG KIỂM TRA hoặc nếu bạn KHÔNG LIÊN QUAN ĐẾN KIỂM TRA để bắt lỗi trong phần mềm.
3. Áp dụng tất cả FEEDBACK từ các lỗi được phát hiện trong quá trình thử nghiệm, đánh giá và sản xuất cho một quy trình và các nhà phát triển đã chèn lỗi vào vị trí đầu tiên. Loại bỏ tất cả các thành phần bị lỗi hoàn toàn ngay khi tìm thấy lỗi. Cập nhật danh sách kiểm tra của bạn và đào tạo lại các nhà phát triển của bạn để họ không mắc lỗi như vậy một lần nữa.

Kiểm tra chỉ có thể chứng minh rằng bạn có lỗi, nhưng thường không có ích để chứng minh khác. Về thông tin phản hồi - nếu bạn có máy tạo tiền xu tạo ra tiền và trung bình cứ sau 10 giây lại có một khiếm khuyết. Bạn có thể lấy đồng tiền đó, làm phẳng nó và đưa vào máy một lần nữa. đồng xu làm ra rằng trống tái chế sẽ không tốt bằng, nhưng có thể chấp nhận được. mỗi 100 xu sẽ phải được đóng dấu lại 2 lần và cứ thế. Nó sẽ dễ dàng hơn để sửa chữa máy?

Thật không may, mọi người không phải là máy móc. Để làm cho lập trình viên giỏi, không có khiếm khuyết, bạn phải đầu tư rất nhiều thời gian, đào tạo và lặp đi lặp lại trên mọi khiếm khuyết được thực hiện. Các nhà phát triển cần được đào tạo về các phương pháp xác minh chính thức thường khó học và áp dụng vào thực tế. Kinh tế học phát triển phần mềm cũng đang làm việc chống lại nó - bạn có đầu tư 2 năm để đào tạo một lập trình viên có thể tạo ra ít khuyết điểm hơn chỉ để thấy anh ta nhảy sang một nhà tuyển dụng khác không? Bạn có thể mua máy tạo ra những đồng tiền hoàn hảo hoặc thuê thêm 10 con khỉ mã để tạo ra nhiều thử nghiệm với cùng chi phí. Bạn có thể cảm nhận quá trình đầy đủ này là "cỗ máy", tài sản của bạn - đầu tư vào đào tạo mở rộng các nhà phát triển xuất sắc không thành công.

Bạn sẽ sớm học được cách phát triển phần mềm có chất lượng chấp nhận được, nhưng có lẽ bạn sẽ không bao giờ là người không có lỗi vì lý do đơn giản là không có thị trường cho nhà phát triển tạo mã hoàn hảo vì nó chậm.

Chương trình phòng thủ: http://en.wikipedia.org/wiki/Defensive_programming

Nếu ai đó tuân theo các quy ước của lập trình một cách phòng thủ, thì những thay đổi sẽ dễ dàng theo dõi. Kết hợp điều này với các báo cáo lỗi nghiêm ngặt trong quá trình phát triển và tài liệu vững chắc, như với doxygen, và bạn sẽ có thể biết chính xác tất cả các mã của bạn đang làm gì và khắc phục mọi lỗi phát sinh, rất hiệu quả.

Đây có thể là kết quả của sự hiểu lầm một phương pháp tốt , và không chỉ là bệnh xương khớp chung chung?

Ý tôi là có thể ông chủ của bạn đã nghe nói về "phương pháp không khuyết tật" (xem phần số 5), và không bận tâm hiểu điều đó có nghĩa là gì?
Tất nhiên, việc quản lý trì hoãn việc phát triển các tính năng mới là bất tiện, có lợi cho các lỗi mà bạn không nên đưa vào ...
Và tất nhiên, điều đó đe dọa đến phần thưởng của anh ấy, vì vậy tất nhiên bạn sẽ không nhận được vì "lập trình viên giỏi không có lỗi "...

Sẽ tốt để tạo ra lỗi, miễn là bạn có thể tìm thấy chúng và sửa chúng (tất nhiên là trong lý do).

Một trong những khái niệm cơ bản của kiểm thử phần mềm là bạn KHÔNG BAO GIỜ chắc chắn rằng chương trình này là hoàn hảo. Bạn có thể xác nhận nó mãi mãi, nhưng điều đó không bao giờ chứng minh rằng chương trình đã hoàn thành bởi vì nó nhanh chóng trở nên không khả thi để thậm chí kiểm tra tất cả các kết hợp đầu vào / biến.

Sếp của bạn có vẻ như là một trong những người "không hiểu gì về lập trình, vì nó chỉ cần gõ"

Nếu chúng tôi giả định các nhà phần mềm lớn biết cách để có được các nhà phát triển xuất sắc hàng đầu (như trong lập trình viên không có lỗi ), chúng tôi có thể khấu trừ rằng phần mềm của Microsoft phải không có lỗi. Tuy nhiên, chúng ta biết rằng đó là xa sự thật.

Việc phát triển phần mềm của họ và khi họ đạt đến một mức độ lỗi ưu tiên thấp nhất định, họ chỉ cần phát hành sản phẩm và giải quyết những lỗi đó sau.

Trừ khi bạn đang phát triển một thứ gì đó phức tạp hơn một máy tính đơn giản, không thể tránh được các lỗi cùng nhau. Địa ngục thậm chí NASA cũng có sự dư thừa trên các phương tiện và lỗi của họ. Mặc dù họ có nhiều thử nghiệm nghiêm ngặt để tránh những thất bại thảm hại. Nhưng dù sao họ thậm chí có lỗi trong phần mềm của họ.

Lỗi là không thể tránh khỏi giống như bản chất của con người là sai lầm.

Không có lỗi cũng giống như có một hệ thống an toàn 100%. Nếu một hệ thống được bảo mật 100% thì chắc chắn nó không còn hữu ích nữa (có lẽ nó nằm bên trong hàng tấn bê tông và hoàn toàn không được kết nối với bên ngoài. Không có dây hay không dây. Vì vậy, không có hệ thống nào an toàn tuyệt đối , không có hệ thống không có lỗi phức tạp.

Tôi chỉ thấy câu trả lời về việc chúng ta là con người và dễ mắc sai lầm, điều này rất đúng ... nhưng tôi thấy câu hỏi của bạn từ một quan điểm khác.

Tôi nghĩ bạn có thể viết các chương trình không có lỗi, nhưng đó là những chương trình mà bạn đã viết 10 hoặc 12 lần. Lần thứ 13 bạn viết cùng một chương trình từ đầu, bạn đã biết cách thực hiện: bạn biết vấn đề, bạn biết các kỹ thuật, bạn biết các thư viện, ngôn ngữ ... bạn thấy nó trong tâm trí của bạn. Tất cả các mô hình là ở đó, ở tất cả các cấp.

Điều này xảy ra với tôi với các chương trình rất đơn giản vì tôi dạy lập trình. Họ đơn giản đối với tôi, nhưng khó khăn cho các sinh viên. Và tôi không nói về các giải pháp cho các vấn đề tôi đã làm nhiều lần trong bảng đen. Tất nhiên tôi biết những điều đó. Ý tôi là ~ 300 chương trình giải quyết một cái gì đó bằng cách sử dụng các khái niệm mà tôi biết rất rõ (các khái niệm tôi dạy). Tôi viết các chương trình này mà không có kế hoạch và chúng chỉ hoạt động, và tôi cảm thấy tôi biết tất cả các chi tiết, tôi không cần TDD chút nào. Tôi nhận được một vài hoặc ba lỗi biên dịch (chủ yếu là lỗi chính tả và những thứ khác như thế) và đó là lỗi đó. Tôi có thể làm điều này cho các chương trình nhỏ, và tôi cũng tin rằng một số người có thể làm điều đó cho các chương trình phức tạp hơn. Tôi nghĩ những người như Linus Torvalds hay Daniel J. Bernstein có đầu óc minh mẫn như vậy, họ là người thân nhất mà bạn có thể đến với một lập trình viên không có lỗi. nếu bạnhiểu những điều sâu sắc tôi nghĩ bạn có thể làm điều đó. Tôi chỉ có thể làm điều này cho các chương trình đơn giản, như tôi đã nói.

Tôi tin rằng nếu bạn luôn cố gắng thực hiện các chương trình vượt xa trình độ của bạn (tôi đã dành nhiều năm để làm điều đó), bạn sẽ bị nhầm lẫn và mắc lỗi. Những sai lầm lớn như những lỗi mà bạn đột nhiên nhận ra rằng giải pháp của bạn không thể hoạt động, khi cuối cùng bạn đã hiểu được vấn đề và phải thực hiện các thay đổi phức tạp đến mức chúng có thể ngăn bạn giải quyết vấn đề của bạn hoặc làm cho mã trở nên tồi tệ. TDD là cho trường hợp này, tôi tin. Bạn biết rằng bạn không khắc phục được vấn đề mà bạn đang giải quyết và do đó đặt các bài kiểm tra ở mọi nơi để đảm bảo rằng bạn có một cơ sở vững chắc. TDD không giải quyết tầm nhìn 10.000 feet, mặc dù. Bạn có thể đi bộ trong vòng tròn với mã hoàn toàn sạch mọi lúc.

Tuy nhiên, nếu bạn cố gắng làm một cái gì đó mới nhưng chỉ ở trên mức của bạn, bạn có thể làm cho chương trình của bạn hoàn hảo hoặc gần như hoàn hảo. Tôi nghĩ thật khó để biết chương trình nào trong "biên giới tri thức" của bạn, nhưng trên lý thuyết đó là cách tốt nhất để học. Tôi viết lại chương trình từ đầu rất nhiều, thực sự. Một số người làm, nhưng bạn cần rất nhiều thời gian và sự kiên nhẫn vì lần thứ ba bạn lặp lại một chương trình không tầm thường, bạn không cảm thấy phấn khích như lần đầu tiên.

Vì vậy, lời khuyên của tôi là: đừng nghĩ rằng bạn hiểu điều gì đó cho đến khi bạn có thể viết một chương trình không có lỗi chỉ vì điều đó. Và sau đó cố gắng kết hợp hai trong số những khái niệm mà bạn biết sâu vào cùng một chương trình. Tôi gần như chắc chắn rằng bạn sẽ có được nó ngay lần đầu tiên. Một trong những cách tốt nhất là viết lại phần mềm không tầm thường, lần đầu tiên phải mất rất nhiều nỗ lực (tôi đang làm điều này với các ứng dụng Android). Mỗi khi tôi bắt đầu lại, tôi thay đổi một cái gì đó hoặc thêm vào một thứ gì đó, chỉ để thêm một chút niềm vui, và tôi có thể nói với bạn rằng tôi ngày càng tốt hơn và tốt hơn ... có thể không có lỗi nhưng thực sự tự hào.

lỗi imho và các tạo phẩm thuật toán đột ngột, lầy lội phải xuất hiện trong quá trình mã hóa: chúng truyền cảm hứng và thúc đẩy sự phát triển của mã.
tuy nhiên, có thể (thường là sau một số thử nghiệm) để kiểm tra mọi biến có thể được sử dụng trước khi khai báo, để xử lý mọi lỗi bất cứ khi nào nó xuất hiện - để làm cho chương trình không có lỗi ... cho đến khi bạn nhận được yêu cầu về một tính năng được xem xét không thể khi bạn đang thảo luận về kiến ​​trúc chương trình;)

Có thể suy nghĩ nhiều hơn về bản chất của các lỗi mà bạn nhận được. Nếu các lỗi nói chung là quá nhỏ, thì việc tập trung vào kiểm tra tốt hơn và đọc một chút bằng chứng mã sẽ giúp ích.

Tuy nhiên, nếu các lỗi có xu hướng là do các quyết định lập trình dưới mức tối ưu, thì có lẽ cần phải nỗ lực nhiều hơn vào thiết kế tốt hơn. Trong trường hợp này, tôi nghĩ rằng có thể quá phụ thuộc vào thử nghiệm để nâng cao chất lượng phần mềm, bởi vì việc áp dụng một bản vá cho mã thiếu có thể chỉ khiến việc bảo trì trong tương lai trở nên phức tạp hơn. Một mặt bạn nhận được ít lỗi hơn khi bạn tìm và sửa chúng, nhưng mặt khác, bạn chuẩn bị nền tảng cho các lỗi trong tương lai.

Một cách để đánh giá xem bạn có vấn đề với sự giám sát hoặc vấn đề với thiết kế có thể là xem xét cần bao nhiêu nỗ lực để sửa lỗi. Nếu các bản sửa lỗi có xu hướng lớn hoặc bạn cảm thấy rằng bạn không hiểu rõ về chúng, điều đó chỉ ra con số về thiết kế mã có thể được cải thiện.

Rằng tôi nghĩ rằng có một loại hương vị tốt về mã, mà bạn có thể phát triển bằng thực tiễn và xem xét, và đọc về những người có vấn đề tương tự.

Cuối cùng, thật vô ích khi hy vọng không có lỗi gì cả, nhưng sẽ không có hại gì khi cố gắng giảm số lượng lỗi của bạn trừ khi bạn đã có nó ở mức độ thấp, và sau đó nó trở thành sự đánh đổi giữa thời gian của bạn và thời gian của bất cứ ai tìm thấy lỗi mà bạn không bắt được.

Nếu tôi muốn nói là: "không có lỗi trong khi viết mã" -> đó là một mục tiêu tốt nhưng khá bất khả thi.

Nhưng nếu bạn có nghĩa là: "không có lỗi trên mã được gửi" -> điều đó là có thể và tôi đã làm việc trong những môi trường như vậy.

Tất cả những gì bạn cần là: chất lượng mã cực kỳ cao và phạm vi kiểm tra gần 100% (kiểm tra đơn vị + kiểm tra chấp nhận + kiểm tra tích hợp).

Theo tôi cuốn sách tốt nhất để học đó là: GOOS . Nhưng tất nhiên một cuốn sách là không đủ. Bạn cần phải đi đến một số nhóm người dùng và thảo luận về điều này. Các khóa học, hội nghị, vv Chất lượng không có lỗi là không dễ dàng.

Trước hết bạn cần một ông chủ thực sự quan tâm đến chất lượng cao và sẵn sàng trả tiền cho nó.

Giải pháp của lập trình viên:

• Dừng lập trình.
• Xây dựng một máy tính cơ khí.
• Thay thế nó cứ sau 5 năm để mặc cơ khí không phát huy tác dụng.

Giải pháp của người dùng:

• Ngừng sử dụng máy tính.
• Làm mọi thứ bằng tay.
• Luôn có người thứ hai kiểm tra lại kết quả.

Tôi đồng ý rằng để trở thành một lập trình viên không có lỗi, bạn chỉ đơn giản là không thể lập trình / mã. Đó là một phần trong cuộc sống của mỗi lập trình viên để gặp phải và phát triển lỗi. Không một nhà phát triển dày dạn nào có thể nói, thật lòng, họ chưa bao giờ gặp phải một lỗi nào trong mã của họ.

Cặp với một kỹ sư khác. Viết một bài kiểm tra thất bại. Có tất cả các nhân vật bạn nhập là cần thiết để vượt qua bài kiểm tra thất bại. Tái cấu trúc mã của bạn để làm cho nó đơn giản hơn. Viết một bài kiểm tra thất bại khác, và cứ thế tiếp tục.