it-swarm-vi.com

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

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 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ì?

168
Elaine

Đừ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 vì 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.

365
wildpeaks

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 xuất hiện trong đầu 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.

124
CodesInChaos

"Lập trình viên không 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, 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]
  • Chiến đấu 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 để đến gần hơn với 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!
98
Maglob

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 dưa chuột kiểm tra phong cách 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.

25
Pete

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 .

19
user7007

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 thì 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 hoàn toàn đ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ó.
17
AmaDaden

Không có lỗi? Nghe 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 tạo 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ất có thể sẽ giúp bạn tránh lỗi.

Đảm bảo rằng bạn đang sử dụng công cụ phân tích mã (chẳng hạn như FindBugs , PMD và v.v.) - kết hợp với 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 đó.

8
Gary Rowe

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 Edge 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ọ Excel tạ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?

8
Sebastien Martin

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.

8
Patrick Klug

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.

7
FabianB

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.

6
JeffO

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.
5
Brian Carlton

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 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.

5
dietbuddha

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 thứ mới ở nhà). Bạn sẽ bắt đầu làm 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ó có thể viết phần mềm tốt , niềm đam mê của bạn cho nghề của bạn sẽ phát triển.

4
Darren

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í khi thực hiện viết (gần như) các chương trình không có lỗi là cực kỳ 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 bộ đơn vị, hồi quy và bộ kiểm tra hệ thống và khai thác rộng rãi để kiểm tra mọi cách phát hiện lỗi. (Và điều này là không đủ trong chính nó.)

  • nhiề mọi 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ả.

2
Stephen 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 chính họ. Như vậy, không có lỗi. Lập trình viên là hoàn hảo.

1
angryITguy

Đây là các bước để tạo 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 kiểm tra, đá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. Hủy 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 thì có một khiếm khuyết. Bạn có thể lấy đồng xu đó, 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 toàn diện 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 được đền đáp.

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.

1
Alexei Polkhanov

Nếu chúng ta giả sử nhà phần mềm lớn biết làm thế nào để 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ừ 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 số 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 chúng 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ọ cũng 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.

0
Robert Koritnik

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ả.

0
Jason McCarrell

Đây có thể là kết quả của sự hiểu lầm a tốt phương pháp luận, 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 tiề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 cho make lỗi, miễn là bạn có thể find them và fix chúng (dĩ nhiên là trong lý do) .

0
AviD

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õ"

0
SpacePrez