Có thể đạt đến trạng thái lỗi không tuyệt đối cho phần mềm quy mô lớn không?


71

Tôi đang nói về 20-30 + triệu dòng mã, phần mềm ở quy mô và độ phức tạp của Autodesk Maya chẳng hạn.

Nếu bạn đóng băng sự phát triển miễn là nó cần, bạn thực sự có thể sửa tất cả các lỗi cho đến khi đơn giản không có một lỗi nào không, nếu điều đó có thể được xác minh bởi máy tính? Các đối số cho và chống lại sự tồn tại của một hệ thống không có lỗi là gì?

Bởi vì có một số ý kiến ​​cho rằng mọi sửa chữa bạn thực hiện đều tạo ra nhiều lỗi hơn, nhưng tôi không nghĩ đó là sự thật.

Theo các lỗi tôi có nghĩa là từ các lỗi chính tả đơn giản nhất trong UI, đến các lỗi phòng ngừa nghiêm trọng hơn không có cách giải quyết. Ví dụ, một hàm script cụ thể tính toán các quy tắc không chính xác. Ngoài ra ngay cả khi có cách giải quyết, vấn đề vẫn phải được khắc phục. Vì vậy, bạn có thể nói rằng bạn có thể thực hiện việc này một cách thủ công thay vì sử dụng chức năng được cung cấp nhưng chức năng đó vẫn phải được sửa.


11
"được nói bởi một vài lập trình viên hàng đầu" - họ không giống những lập trình viên hàng đầu đối với tôi. Họ có vẻ như tin tặc hàng đầu. Một trong những TRÁCH NHIỆM CHÍNH của một lập trình viên là hiểu mã của họ làm gì và nó ảnh hưởng đến toàn bộ hệ thống như thế nào. Đó là lý do tại sao chúng ta có TDD, các mẫu thiết kế, v.v. Nếu điều này không thể được thực hiện, hệ thống là rác - quá trình phát triển được thực hiện một cách hỗn loạn, hỗn loạn, vô kỷ luật, không khoa học.
Vector

51
Nếu bạn không biết rằng một lỗi tồn tại, nó vẫn là một lỗi?
Blrfl

5
@Blrf: Quan trọng hơn, Nếu người dùng cuối không biết có lỗi, nó có tồn tại không?
mattnz

40
Có hai cách để xây dựng một thiết kế phần mềm. Một cách là làm cho nó đơn giản đến mức rõ ràng là không có thiếu sót. Và cách khác là làm cho nó trở nên phức tạp đến mức không có thiếu sót rõ ràng nào. Lít
Andrew Lewis

5
Đó là, nhưng rất nhiều người không muốn niềm tin cơ bản của họ bị nghi ngờ.
Joan Venge

Câu trả lời:


92

Như Mikey đã đề cập, viết mã không có lỗi không phải là mục tiêu. Nếu đó là những gì bạn đang hướng tới, thì tôi có một số tin rất xấu cho bạn.

Điểm mấu chốt là bạn đang đánh giá rất thấp sự phức tạp của phần mềm.

Điều đầu tiên trước tiên - Bạn đang bỏ qua bức tranh lớn hơn về cách chương trình của bạn chạy. Nó không chạy một cách cô lập trên một hệ thống hoàn hảo. Ngay cả những chương trình cơ bản nhất của "Hello World" cũng chạy trên một hệ điều hành, và do đó, ngay cả những chương trình đơn giản nhất cũng dễ bị lỗi có thể tồn tại trong hệ điều hành.

Sự tồn tại của các thư viện làm cho điều này phức tạp hơn. Trong khi các hệ điều hành có xu hướng khá ổn định, các thư viện là một túi hỗn hợp khi nói đến sự ổn định. Một số là tuyệt vời. Những người khác ... không quá nhiều ... Nếu bạn muốn mã của mình không có lỗi 100%, thì bạn cũng cần phải đảm bảo rằng mọi thư viện bạn chạy đều hoàn toàn không có lỗi và nhiều lần điều này đơn giản là không thể bạn có thể không có mã nguồn

Sau đó, có chủ đề để suy nghĩ. Hầu hết các chương trình quy mô lớn sử dụng chủ đề ở khắp mọi nơi. Chúng tôi cố gắng cẩn thận và viết các chủ đề theo cách mà điều kiện cuộc đua và bế tắc không xảy ra, nhưng đơn giản là không thể kiểm tra mọi tổ hợp mã có thể. Để kiểm tra điều này một cách hiệu quả, bạn sẽ cần kiểm tra mọi thứ tự có thể của các lệnh đi qua CPU. Tôi chưa thực hiện phép toán này, nhưng tôi nghi ngờ rằng việc liệt kê tất cả các trò chơi Cờ vua có thể sẽ dễ dàng hơn.

Mọi thứ đi từ khó đến không thể khi chúng ta nhìn vào chính chiếc máy. CPU không hoàn hảo. RAM không hoàn hảo. Ổ cứng không hoàn hảo. Không có thành phần nào trong máy được thiết kế hoàn hảo - chúng được thiết kế để "đủ tốt". Ngay cả một chương trình hoàn hảo cuối cùng cũng sẽ thất bại do tiếng nấc của máy. Bạn không thể làm gì để ngăn chặn nó.

Tóm lại: Bạn có thể viết "Lỗi phần mềm miễn phí" không?

KHÔNG

Bất cứ ai nói với bạn khác là không biết gì.

Chỉ cần cố gắng viết phần mềm dễ hiểu và bảo trì. Một khi bạn đã làm điều đó, bạn có thể gọi nó là một ngày.


EDIT: Một số người nhận xét về một điểm tuyệt vời mà tôi đã hoàn toàn bỏ qua: trình biên dịch.

Trừ khi bạn đang viết trong assembly, hoàn toàn có khả năng trình biên dịch sẽ làm rối mã của bạn (ngay cả khi bạn chứng minh rằng mã của bạn là "hoàn hảo").

Danh sách các lỗi trong GCC, một trong những trình biên dịch được sử dụng phổ biến hơn: http://gcc.gnu.org/ormszilla/ormslist.cgi?product=gcc&component=c%2B%2B&resolution=---


8
Câu trả lời vẫn là "không", bởi vì sẽ luôn có "lỗi" khi một thứ gì đó hoạt động - không giống như khách hàng hoặc chủ sở hữu sản phẩm muốn nó hoạt động. Một số người trong chúng ta có thể gọi những yêu cầu tính năng này hoặc yêu cầu thay đổi hành vi hoặc thêm chức năng - nhưng với người đang bị làm phiền bởi một số "lỗi" mỗi ngày, điều khiến họ khó chịu là một lỗi. (Đó là một cách dài để nói rằng một số lỗi nằm trong mắt của kẻ si tình.) BUG MÃ MIỄN PHÍ là không thể. Nhằm mục đích cho mã đủ tốt để đáp ứng mục đích dự định của nó.
quick_now

6
Tôi sẽ tiến thêm một bước: mã có thể có các lỗi tiềm ẩn, ví dụ: bạn có thể có mã không đúng phạm vi kiểm tra đầu vào. Nếu đầu vào là vì một số lý do may mắn không bao giờ nằm ​​ngoài phạm vi, lỗi không bao giờ xuất hiện. Sau đó một ngày trong quá trình bảo trì hoặc thay đổi tính năng, đoạn mã đó được gọi từ một nơi khác mà thỉnh thoảng thực hiện nó với giá trị ngoài phạm vi. Lỗi bây giờ xuất hiện - nhưng nó đã có tất cả cùng. Bạn có thể có mức độ điên rồ trong tất cả những điều này - nhưng loại bỏ mọi khả năng sai lầm vẫn là không thể.
quick_now

11
@ JohnR.Strohm Tôi không chắc tại sao bạn nghĩ chương trình 'bộ điều biến dòng thông báo', một chương trình với 556 dòng mã, có bất cứ điều gì liên quan đến một câu hỏi liên quan đến hệ thống 20 triệu dòng lý thuyết. Ngoại trừ, có lẽ, để chứng minh rằng rất khó để chứng minh tính đúng đắn của chương trình nhỏ bé, sẽ khó hơn về mặt thiên văn để chứng minh tính đúng đắn của một chương trình lớn.
Eric King

9
Trong khi câu hỏi ban đầu không làm như vậy, tôi muốn chỉ ra rằng có một sự khác biệt rất lớn giữa 'về mặt lý thuyết' và 'thực tế là có thể'. Mặc dù cơ sở mã 20 triệu dòng không có lỗi về mặt lý thuyết là có thể, nhưng gần như chắc chắn đó là một điều không thể thực tế, trong thị trường ngày nay. Ai biết được những gì trong tương lai.
Eric King

4
@ JohnR.Strohm Bạn nên đọc kỹ tờ giấy hơn. Họ tự nói: It is important to note, however, that even all of these steps provide no guarantee of absolute security. It is tempting to believe that a formally specified and proved program should be absolutely correct, but there are several reasons why a proved program may not behave exactly as expected.- có nghĩa là, nó không thể được chứng minh là không có lỗi, nhưng đúng hơn, ít có khả năng có lỗi hơn. Thay vì như TDD.
Izkata

27

Về mặt toán học, MIGHT có thể viết phần mềm 'bugless' có độ phức tạp như vậy, tùy thuộc vào cách bạn xác định 'lỗi'. Chứng minh nó MIGHT cũng có thể về mặt toán học, bằng cách thiết kế một hệ thống thử nghiệm sẽ thực hiện mọi dòng mã theo mọi cách có thể - mọi trường hợp sử dụng có thể. Nhưng tôi không chắc chắn - nếu bạn đang xử lý một hệ thống thực hiện các phép tính phức tạp, bạn có thể gặp phải một 'vấn đề vô cực' ...

Thực tế mà nói, trong một hệ thống có quy mô và phạm vi mà bạn đang nói đến, đây là điều KHÔNG THỂ . Có thể mất 1000 năm để viết một hệ thống 'không có lỗi' như vậy và để viết một hệ thống để chứng minh rằng sẽ mất nhiều thời gian hơn theo cấp số nhân: bạn phải đưa ra mọi trường hợp sử dụng có thể và viết một hệ thống sẽ kiểm tra từng hệ thống một - và tôi không tin có cách xác định rằng bạn đã thực sự bao quát mọi trường hợp sử dụng trong một hệ thống có kích thước và phạm vi bạn đang nói về bất cứ điều gì tương tự như một khoảng thời gian hợp lý.

IMO câu hỏi của bạn hơi sai lầm: Mục tiêu của chúng tôi là các nhà phát triển không phải là viết phần mềm 'không có lỗi'. Mục tiêu của chúng tôi là viết phần mềm USABL, FLEXIBLE, EASILY MAINTAINABLE .

Có thể sử dụng: Hệ thống đáp ứng các yêu cầu thiết yếu mà nó được thiết kế cho. Có thể có lỗi - nhưng chúng sẽ nằm trong 'các trường hợp cạnh' - ngoại lệ, hoặc gây phiền nhiễu, không phải là lỗi làm tổn hại đến các nguyên tắc cơ bản của hệ thống - mạnh mẽ.

Có thể bảo trì: Lỗi có thể dễ dàng phân lập và sửa lỗi và KHÔNG tạo ra các lỗi mới.

Linh hoạt: Hệ thống của bạn dễ dàng thay đổi và mở rộng mà không cần thiết kế lại và thời gian chết đáng kể: Hầu hết các thay đổi chỉ cần thêm một lớp hoặc mô-đun mới phù hợp với các mẫu và khung đã được thiết kế tốt của bạn.

Thực hành thiết kế tốt, thực hành kiểm soát tốt, làm việc nhóm tốt, nhà phát triển có lương tâm - đó là công thức cho PHẦN MỀM TỐT . (không HOÀN HẢO - nhưng TỐT )


3
"Chứng minh MIGHT cũng có thể về mặt toán học, bằng cách thiết kế một hệ thống kiểm tra sẽ thực thi mọi dòng mã theo mọi cách có thể - mọi trường hợp sử dụng có thể.": Một chương trình như vậy không tồn tại nói chung (và điều này có thể được chứng minh!). Vì vậy, một thuật toán chung để chứng minh tính đúng đắn không tồn tại.
Giorgio

3
Sửa chữa: Phần mềm không có lỗi, HOÀN THÀNH VỚI BÀI TOÁN TOÁN TOÁN HÌNH THỨC, đã đạt được. Nó được thực hiện vào năm 1982. Google "bộ điều biến dòng tin nhắn".
John R. Strohm

6
@ JohnR.Strohm: Không đúng. Đây chỉ là một trích dẫn - có một số bài báo và một số nơi họ giải quyết các mối quan tâm tương tự: "Một câu hỏi thường được đưa ra là" Bạn đã xác minh người xác minh chưa? " Tất nhiên, nếu một cỗ máy từng trả lời câu hỏi "Bạn có bao giờ nói dối không?" thì câu trả lời sẽ không có nhiều thông tin hơn khi con người trả lời câu hỏi. "
Vector

1
Tôi có nghĩa là không có thuật toán chung sẽ làm việc cho bất kỳ chương trình đầu vào và bất kỳ đặc điểm kỹ thuật đầu vào. Bạn chỉ có thể xử lý các trường hợp cụ thể (ví dụ: ví dụ của bạn).
Giorgio

1
@Giorgio - vì vậy IMO, tuân theo các thực tiễn thiết kế tốt quan trọng hơn nhiều so với việc bạn liên quan đến tính chính xác toán học: thiết kế mã của bạn để đảm bảo rằng nó có thể được tích hợp tốt và tuân thủ những gì đã có - và đủ mạnh để dễ dàng xử lý các khiếm khuyết khi chúng đến với ánh sáng (mà họ sẽ).
Vector

27

Theo bài viết này, phần mềm trên tàu cho Tàu con thoi đã đến rất gần - ba phiên bản cuối cùng của chương trình dòng 420.000 chỉ có một lỗi. Phần mềm được duy trì bởi một nhóm gồm 260 người đàn ông và phụ nữ. Một số lượng lớn những người này là người xác minh, với mục đích duy nhất là tìm lỗi.

Việc 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 chỉ ảnh hưởng đến 1,5% chương trình, tương đương 6.366 dòng mã. Thông số kỹ thuật cho một thay đổi đó đã chạy 2.500 trang. Thông số kỹ thuật cho toàn bộ chương trình đã lấp đầy 30 tập và chạy 40.000 trang, hoặc trung bình mười dòng mã trên mỗi trang của thông số kỹ thuật.

Ngân sách không phải là vấn đề - ở mức 35 triệu đô la mỗi năm, họ có thể đủ khả năng để làm mọi việc đúng đắn.


25
Một lỗi được phát hiện mỗi. Ai biết có bao nhiêu lỗi không bị phát hiện? :)
Andres F.

8
Đó là "một lỗi" là một trường hợp đặc biệt. Shuttle ban đầu được thiết kế và phần mềm được chỉ định cho hai cánh tay robot. "Lỗi" là vẫn còn mã trong đó để hỗ trợ nhánh thứ hai.
John R. Strohm

4
+1 Ran không có lỗi cho 135 nhiệm vụ từ năm 1981 đến 2011
MarkJ

5
@MarkJ: có lẽ chúng ta sẽ không biết nếu Tàu con thoi thực sự không có lỗi. Mọi nhiệm vụ của Tàu con thoi đều được hàng trăm người theo dõi liên tục, theo dõi chặt chẽ và bất kỳ lỗi nào trong quá trình mã hóa sẽ được sửa chữa / ghi đè thủ công.
Lie Ryan

2
@LieRyan Điều này cho thấy một đặc tính tuyệt vời của các hệ thống mạnh mẽ - nếu chúng không thất bại thảm hại và luôn cho phép điều chỉnh thủ công, bạn có thể sử dụng các hệ thống dự phòng (chẳng hạn như các hệ thống tại trung tâm điều khiển) để thực hiện công việc thay thế. Tất nhiên, điều này chỉ có ý nghĩa nếu bạn có các hệ thống dư thừa như vậy, và nếu bạn thực sự có thể đảm bảo tính chính xác và nhất quán. Trên một ứng dụng kinh doanh thông thường, một sự cố thường sẽ thích hợp hơn khi hoạt động ở trạng thái không nhất quán - đó là sự khác biệt giữa một sự phiền toái và, nói rằng, gửi tiền cho kẻ sai. Hoặc nhận tiền mà không được gửi ...
Luaan

15

Về cơ bản, không nhưng bạn vẫn nên cố gắng hết sức. Tôi sẽ giải thích lý do tại sao (hoặc chỉ bỏ qua kết luận nếu bạn không đủ kiên nhẫn)

Xem xét một vấn đề tầm thường như việc thực hiện tìm kiếm nhị phân. Một triển khai rất phổ biến có một lỗi không bị phát hiện trong khoảng hai thập kỷ. Nếu hai mươi dòng mất hai mươi năm để không có lỗi được sử dụng rộng rãi và thậm chí được chứng minh là đúng, chúng ta có thể thực sự mong đợi một chương trình khổng lồ không có lỗi không?

Có bao nhiêu lỗi chúng ta có thể mong đợi một chương trình khổng lồ sẽ có? Một số tôi tìm thấy là "10 lỗi trên 1000 dòng" (Code Complete phiên bản 2, trang 517 - chỉ sử dụng một ví dụ, không trích dẫn bất kỳ dữ liệu nào) Điều đó mang lại cho chúng tôi khoảng 200 000 đến 300 000 lỗi trong phần mềm của bạn. May mắn thay, chúng tôi có cách để cải thiện chất lượng của chương trình. Kiểm thử đơn vị, đánh giá mã và kiểm tra thủ công thông thường được biết là làm giảm số lượng lỗi. Tuy nhiên, số lượng vẫn sẽ cao.

Nếu chúng ta có thể giải quyết 95% tất cả các lỗi sẽ là không thể tin được. Tuy nhiên, chúng tôi vẫn có 10 000 đến 15 000 lỗi trong phần mềm.

May mắn thay, vì phần mềm được sử dụng rộng rãi (và, do đó, các lỗi đã được thử nghiệm rộng rãi) sẽ được tìm thấy. Vì vậy, chúng ta sẽ dần dần nhận được ít lỗi hơn. Tuy nhiên, ít lỗi hơn cũng có nghĩa là những cái còn lại khó tìm hơn - vì vậy đừng mong đợi một đường cong tuyến tính trong sửa lỗi. Một vài lỗi cuối cùng sẽ được thực sự khó khăn để tìm thấy và có thể tránh bị phát hiện trong nhiều năm (giả sử họ đang bao giờ tìm thấy).

Bạn dường như cũng đang lầm tưởng rằng nếu phần mềm không thay đổi, sẽ không có lỗi mới nào xuất hiện. Nếu phần mềm phụ thuộc vào thư viện của bên thứ ba, các phiên bản mới có thể phá vỡ một số tính năng - giới thiệu các lỗi mới mặc dù mã của ứng dụng vẫn giống nhau. Các hệ điều hành mới cũng có thể phá vỡ một ứng dụng trước đây hoạt động hoàn hảo (xem Windows Vista để biết ví dụ phổ biến). Cũng xem xét các lỗi biên dịch, v.v.

Không rõ liệu các công cụ bằng chứng mã có thể thực sự giải quyết vấn đề của phần mềm lỗi hay không. Chắc chắn không thể giải quyết vấn đề tạm dừng cho bất kỳ chương trình nào, nhưng có thể chứng minh rằng một chương trình hoạt động như được chỉ định ... Nhưng sau đó thì sao? Có lẽ chương trình bằng chứng có một lỗi. Có lẽ bản thân đặc tả có lỗi.

Vì vậy, rõ ràng, chúng ta có thể giảm đáng kể số lượng lỗi, nhưng thực sự không chắc chúng ta sẽ trở về không.

Bởi vì có một số ý kiến ​​cho rằng mọi sửa chữa bạn thực hiện đều tạo ra nhiều lỗi hơn, nhưng tôi không nghĩ đó là sự thật.

(nhấn mạnh thêm)

Bạn nói đúng. Phát biểu này là sai. Đây là một ví dụ:

int main() {
    int x[10];
    x[10] = 8; //Buffer overflow here
    return 0;
}

Bây giờ, hãy sửa lỗi này:

int main() {
    int x[11];
    x[10] = 8; //No buffer overflow here
    return 0;
}

Xem? Chúng tôi đã sửa một lỗi và giới thiệu không có lỗi mới.

Tuy nhiên, điều chắc chắn là mỗi khi bạn sửa một lỗi bạn có nguy cơ tạo ra một lỗi mới, mặc dù rủi ro này có thể được giảm thiểu (ví dụ như với thử nghiệm đơn vị).

Hãy nói rằng cứ 100 lỗi mà tôi sửa, tôi vô tình giới thiệu một lỗi mới. Vì vậy, nếu tôi sửa 10 000 lỗi, tôi giới thiệu 100 lỗi mới. Và nếu tôi sửa những lỗi mới đó, tôi sẽ giới thiệu một lỗi. Nhưng cái gì cơ? Chương trình hiện có ít hơn 9 999 lỗi, vì vậy có lẽ nó tốt hơn so với trước đây (giả sử lỗi mới không tệ hơn 10 000 lần so với các lỗi trước đó).

Ngoài ra, sửa một lỗi có thể làm lộ ra những cái mới. Nhưng những lỗi đó cũng có thể được sửa. Nếu bạn làm đúng, cuối cùng phần mềm sẽ ở trạng thái tốt hơn so với khởi động.

Tôi đã già bởi một vài lập trình viên hàng đầu rằng tốt hơn hết là đừng sửa nhiều lỗi vì khái niệm tôi đã đề cập trong OP.

Hành vi này là bất cẩn. Nếu có một lỗi và bạn có thể sửa nó. Làm đi. Tất nhiên bạn nên cố gắng hết sức để ngăn chặn việc thêm những cái mới nhưng nếu tôi giới thiệu một lỗi nhỏ cho mỗi 10 lỗi nghiêm trọng tôi sửa, đó không phải là lý do hợp lệ để ngừng sửa lỗi. Trong thực tế, đó là một lý do tốt để tiếp tục sửa lỗi .

Vì vậy, ít lỗi bạn sửa, ít lỗi sẽ quay trở lại với bạn trong tương lai

Càng sửa ít lỗi, càng nhiều lỗi sẽ tồn tại trong phần mềm của bạn, gây khó chịu cho người dùng của bạn. Thật vậy, họ sẽ không "quay lại với bạn trong tương lai". Họ sẽ không quay lại vì họ không bao giờ rời đi ngay từ đầu. Khái niệm "quay trở lại" có liên quan đến hồi quy. Một lần nữa, có thể giảm nguy cơ hồi quy.

Một số lỗi không thể sửa được vì chúng được sử dụng rộng rãi đến mức mọi người bắt đầu phụ thuộc vào chúng và sửa lỗi sẽ phá vỡ chương trình cho những người dùng đó. Nó xảy ra. Tuy nhiên, họ thực sự có thể được coi là lỗi trong trường hợp đó?

Tâm lý "sửa lỗi, tạo lỗi" có thể liên quan đến Quái vật khủng khiếp đó - mã không thể đọc được và không thể nhận ra rằng chỉ cần chạm vào nó sẽ tạo ra lỗi. Nếu bạn có một quái vật trong cơ sở mã của mình, trước tiên bạn có thể cần hủy bỏ quái vật đó trước khi hoàn thành mọi việc.

Cuối cùng, nếu bạn là một lập trình viên tồi tệ, có nguy cơ bất cứ điều gì bạn chạm vào đều tạo ra các lỗi mới. Điều này rõ ràng sẽ làm cho các lập trình viên cao cấp lo lắng. Tuy nhiên, nói "Đừng làm gì cả. Đừng chạm vào bất cứ thứ gì. Thậm chí đừng thở." có lẽ không phải là cách đúng đắn để tạo ra một môi trường làm việc lành mạnh. Giáo dục là tốt hơn.

Phần kết luận:

  • Phần mềm tiếp tục nhận được vô số tính năng mới nhưng không có sửa lỗi chắc chắn sẽ bị hút.
  • Phần mềm có số lượng tính năng mới vừa phải nhưng đã sửa lỗi có cơ hội sử dụng tốt hơn.
  • Những người cố gắng có ít lỗi có (trung bình) ít lỗi hơn những người không quan tâm.
  • Thật không hợp lý khi mong đợi một chương trình cuối cùng sẽ không có lỗi.
  • Lập trình viên cao cấp không nhất thiết phải có năng lực.
  • Sửa lỗi của bạn.
  • Áp dụng các phương pháp cải thiện chất lượng phần mềm của bạn.

+1: Bản thân tôi đang tìm kiếm ví dụ tìm kiếm nhị phân, đã bị đánh bại;) Nếu 20 dòng mã được thảo luận và lưu hành rộng rãi có lỗi trong 20 năm, bạn cần bao nhiêu thời gian cho một cơ sở mã 20 triệu mà hầu hết vài chục người bận rộn sẽ nhìn vào?
Scrwtp

Cảm ơn. Tôi tự hỏi nếu lỗi tìm kiếm nhị phân (mà tôi chưa bao giờ nghe thấy trước đây) có liên quan đến việc mọi người sao chép nhiều mã mà không suy nghĩ nhiều không? Ngoài ra nếu chúng ta có nhiều lỗi này thậm chí có thể liệt kê, có thể các công cụ và thực tiễn chúng ta đang sử dụng không tối ưu?
Joan Venge

1
@JoanVenge Tôi đã trích dẫn ví dụ đó để cho thấy những lỗi khó tìm có thể tìm thấy như thế nào. Trong trường hợp này bản sao dán thực sự là đúng điều cần làm vì nó đã được chứng minh là đúng và thực hiện bằng văn bản từ đầu rất có thể sẽ có nhiều lỗi. Các công cụ và thực tiễn mà chúng ta - như một ngành công nghiệp nói chung - đang sử dụng chắc chắn là không tối ưu. Thực hành tốt nhất là dễ bỏ qua và thói quen xấu là dễ dàng để giữ. Cuối cùng, bọ sẽ luôn tồn tại vì con người không hoàn hảo. Nhưng chúng ta có thể giảm số lượng lỗi bằng cách cố gắng hết sức và nhấn mạnh vào giáo dục chất lượng cao.
luiscubal

7
Tôi nghĩ rằng lỗi trong mã tìm kiếm nhị phân cho thấy mức độ phức tạp của câu hỏi này. Các lỗi cơ bản trong tìm kiếm là một tràn số nguyên tiềm năng trong một bổ sung. Những "lỗi" như vậy rất phổ biến bởi vì hầu hết dân gian đều dựa vào một giả định ngầm (và đôi khi không chính xác) rằng các đầu vào sẽ không đủ lớn để gây ra tràn. Nó thực sự là một lỗi hay chỉ là một hợp đồng giao diện tài liệu kém? Lần cuối cùng mà phạm vi của bạn đã kiểm tra các triệu hồi trong một bổ sung số nguyên hoặc kiểm tra tràn sau khi thực tế là khi nào?
Charles E. Grant

4
Máy chủ mẫu của bạn để làm nổi bật một quan sát khá rõ ràng về ngôn ngữ lập trình và chất lượng công cụ. Một trình biên dịch chất lượng sản xuất cho một ngôn ngữ mạnh mẽ đã từ chối biên dịch ví dụ đầu tiên của bạn, thay vào đó là một lỗi biên dịch nghiêm trọng. Việc biên dịch một thứ gớm ghiếc như vậy thậm chí còn cho bạn biết mọi thứ bạn cần biết về chất lượng của các công cụ đó và tính khả thi của việc sử dụng chúng để cung cấp phần mềm không có lỗi.
John R. Strohm

12

Những lý do không viết chương trình không có lỗi chủ yếu là kinh tế.

những phương pháp toán học để chứng minh sự đúng đắn của một chương trình. Trong một khóa học Khoa học Máy tính chất lượng cao, họ sẽ được đề cập. Có những ngôn ngữ lập trình được phát minh đặc biệt cho mục đích này. Về lý thuyết, lập trình không có lỗi có thể.

Vâng, có phần cứng không hoàn hảo đôi khi có thể thay đổi một chút giá trị bởi vì một neutrino được bắn ra từ một siêu tân tinh xa xôi hàng triệu năm trước đã tình cờ tấn công bộ xử lý của bạn đúng nơi. Được rồi, mọi lý thuyết đều có giả định và trừu tượng của nó. Nhưng giả sử rằng bộ xử lý hoạt động như quảng cáo, có các công cụ toán học để đảm bảo chương trình cũng hoạt động chính xác.

Một số câu trả lời được bình chọn cao trong chủ đề này là sai lệch. Ví dụ, định lý không hoàn chỉnh và vấn đề tạm dừng của Gôdel chỉ ngụ ý rằng bạn không thể có một công cụ tự động quyết định tính đúng đắn hoặc không chính xác của bất kỳ chương trình nào . Nhưng chúng tôi không muốn quyết định tính đúng đắn của bất kỳ chương trình nào , chúng tôi chỉ muốn một bằng chứng về tính đúng đắn của một chương trình cụ thể .

(Tương tự, chỉ vì bạn không thể viết chương trình để tự động quyết định sự thật của bất kỳ định lý toán học nào , điều đó không có nghĩa là bạn không thể chứng minh một định lý toán học cụ thể .)

Vấn đề, thay vào đó, là:

Mặc dù về lý thuyết có thể viết một chương trình không có lỗi, nhưng làm như vậy sẽ rất tốn kém . Viết một mã với một bằng chứng về tính chính xác của nó phức tạp hơn là chỉ ném một cái gì đó vào tường để xem nếu nó dính vào. Ngay cả khi "nhìn thấy nếu nó dính" được thực hiện bằng các bài kiểm tra đơn vị; và nhiều lập trình viên thậm chí không bận tâm làm điều đó. Hầu hết các lập trình viên thậm chí sẽ không biết làm thế nào để làm điều đó, điều đó có nghĩa là với tư cách là một công ty, bạn sẽ phải thuê những người đắt tiền hơn.

Xem xét tất cả các chi phí, một khách hàng thông thường hài lòng hơn với một phần mềm giá rẻ hoạt động tốt 99% thời gian (và 99,9% thời gian sau khi cài đặt các bản cập nhật bổ sung) so với phần mềm đắt hơn gấp ngàn lần, hoạt động tốt hơn 100% thời gian. Ngoài ra, khách hàng muốn có phần mềm này ngay bây giờ , và không phải trong mười hoặc hai mươi năm nữa.

Do đó, mọi người cố tình sản xuất phần mềm có một số lỗi, cố gắng đạt được sự kết hợp tối ưu trong đó các lỗi không quá thường xuyên và không quá nghiêm trọng, và việc sản xuất đủ nhanh và đủ rẻ. Sự kết hợp mang lại lợi nhuận cao nhất trong cuộc sống thực. (Đôi khi, điều đó có nghĩa là phát hành một phần mềm đầy lỗi trước khi đối thủ của bạn phát hành bất cứ điều gì và chỉ phát hành phiên bản 2.0 tốt hơn khi đối thủ của bạn sẵn sàng phát hành phiên bản đàng hoàng đầu tiên của họ.)

Nếu bạn đóng băng sự phát triển miễn là nó cần, bạn thực sự có thể sửa tất cả các lỗi cho đến khi đơn giản không có một lỗi nào không, nếu điều đó có thể được xác minh bởi máy tính?

Về mặt toán học, bạn có thể. Về kinh tế, tại sao mọi người sẽ làm điều đó? Nó có nghĩa là chi tiêu có lẽ hai mươi năm và một vài triệu đô la. Trong khi đó, khách hàng sẽ muốn các tính năng mới và các ứng dụng đóng băng của bạn không thể cung cấp chúng. Vì vậy, trong thời gian phiên bản hoàn hảo của bạn đã sẵn sàng, thị trường đã bị các đối thủ cạnh tranh chiếm lĩnh.

Lý luận kinh tế là OK. Chúng ta sống trong một thế giới nơi tiền bạc và thời gian quan trọng. Nhưng chỉ vì chúng ta không làm điều gì đó vì lý do kinh tế, chúng ta không nên nói những điều vô nghĩa về cách điều đó không thể được thực hiện ngay cả trên lý thuyết. Ai biết được ... có thể trong một vài năm nữa, chúng ta sẽ có một số ngôn ngữ và công cụ lập trình mới có thể làm cho tính chính xác trở nên dễ dàng .


Cảm ơn, mặc dù tôi ước hầu hết các phần mềm hoạt động 99% thời gian, nhưng hầu hết các phần mềm lớn mà tôi sử dụng như phần mềm trong OP, đều rất có lỗi. Nhưng tôi nghĩ độc quyền, và mua đối thủ cạnh tranh cũng là yếu tố này. Nhưng tôi thấy quan điểm của bạn.
Joan Venge

1
"Đắt tiền" là tương đối. So sánh chi phí tìm và sửa các lỗi với chi phí, ví dụ như một máy xạ trị giết chết một số bệnh nhân và đánh lừa một số người khác. (Google "Therac 25".)
John R. Strohm

6

Không.

David Hilbert đã đề xuất vấn đề thứ hai của ông về toán học vào năm 1900, về cơ bản yêu cầu thế giới chứng minh rằng số học hoạt động như dự định. Sau đó, ông đã đạo diễn " Entscheidungspropet ", trong đó hỏi một số điều tương tự về mặt logic. " Định lý bất toàn đầu tiên " của Kurt_Gödel đã chứng minh vào năm 1931 rằng không có lý thuyết nào về số học cơ bản có thể phù hợp và hoàn chỉnh. Đại diện của Entscheidungspropet của Alan Turing là " vấn đề tạm dừng " đã chuyển vấn đề đi thẳng vào trọng tâm của câu hỏi này, nơi ông đã chứng minh rằng không thể chứng minh liệu một chương trình sẽ chạy đến hoàn thành hay không. Cho rằng không an toàn, cũng không thể chứng minh liệu một chương trình có lỗi hay không.

Không ai trong số đó giải phóng các lập trình viên thực hành trong số chúng ta khỏi phấn đấu không có lỗi. Nó chỉ có nghĩa là chúng ta không thể thành công nói chung.


9
Tính không ổn định chỉ áp dụng chung - có những chương trình mà bạn có thể chứng minh không đúng hoặc không chính xác. Nhưng đối với một chương trình cụ thể nhất định, tính chính xác (hoặc thường xuyên hơn: tính không chính xác) thường có thể được chứng minh. Điều này giả sử bạn có một đặc tả ngôn ngữ chính thức và một trình biên dịch có thể chứng minh chính xác - cái sau không tồn tại đối với bất kỳ ngôn ngữ lập trình cấp cao nào, mặc dù CompCert đã đóng.
Daniel

+1 để trích dẫn nền tảng lý thuyết có liên quan. Tôi vẫn chưa biết rằng "Entscheidungspropet" được gọi giống như tiếng Anh như tiếng Đức!
Peopleware

5
Đồng ý với Daniel. Thách thức là về một trường hợp duy nhất; các vấn đề tạm dừng giải quyết với tất cả các trường hợp có thể. Tạm int main() { return 0; } dừng và không có lỗi.
MSalters

1
Vấn đề dừng lại không nói rằng không thể chứng minh liệu một chương trình sẽ chạy đến khi hoàn thành hay không; nó nói rằng có những chương trình mà không thể chứng minh được. Các chương trình hàng ngày thông thường không có trong lớp này. "Mặc dù bằng chứng của Turing cho thấy rằng không thể có phương pháp hay thuật toán chung nào để xác định liệu các thuật toán có dừng lại hay không, các trường hợp riêng lẻ của vấn đề đó rất có thể dễ bị tấn công. và trên thực tế, các nhà khoa học máy tính thường làm điều đó như một phần của bằng chứng chính xác. "
endolith

6

Errare humanum est

Ngay cả khi bạn viết mã bằng một ngôn ngữ chính thức, như phương pháp B , bạn có thể sử dụng để chứng minh một cách toán học rằng các yêu cầu được đáp ứng,

Ngay cả khi bạn sử dụng ngôn ngữ đặc tả chính thức,

Luôn có một bước con người bao gồm việc trích xuất nhu cầu của người dùng từ một hoặc nhiều bộ não sang máy tính.

Bước này của con người dễ bị lỗi và sâu nằm trong quả táo.


1
Nó vẫn là một lỗi khi một chương trình làm những gì được yêu cầu, thay vì những gì đã được dự định?
MSalters

Tôi nghĩ đó là ..
Joan Venge

4
@MSalters - Tất nhiên rồi. Không phải từ quan điểm hợp đồng, nhưng cuối cùng khách hàng vẫn chưa giải quyết được vấn đề của mình. Bạn sẽ bay trong một chiếc máy bay có máy tính làm những gì được hỏi nhưng không có ý định gì?
mouviciel

3

Một tỷ lệ hợp lý của các "lỗi" mà tôi gặp phải có thể được mô tả đúng hơn là sự không phù hợp giữa thiết kế hệ thống và kỳ vọng của khách hàng.

Bây giờ, cho dù chúng ta gọi những lỗi này hay không là học thuật, nhưng thực tế vẫn còn rất nhiều công việc bảo trì phát sinh do kết quả trực tiếp của giao tiếp không hoàn hảo và thay đổi kỳ vọng của khách hàng.

Ngay cả khi một hệ thống về mặt kỹ thuật, có thể "chính xác" theo nghĩa là đáp ứng một thông số kỹ thuật, (tuy nhiên không thể thực hiện được đối với phần mềm thương mại trong thế giới thực), thì bạn vẫn sẽ gặp vấn đề về việc khớp chức năng của phần mềm với khách hàng của bạn thay đổi và kỳ vọng được xác định kém.

Nói ngắn gọn:

Không.


+1 Một nhà phát triển và khách hàng có thể có nhiều quan điểm khác nhau về những gì định nghĩa một 'lỗi'.
GrandmasterB

Nhưng nếu nhà phát triển cũng là người dùng thì sao? Tôi thường tìm thấy phần mềm tốt nhất từ ​​những người đó về khả năng sử dụng vì họ biết chính xác cách thức hoạt động của một thứ gì đó, v.v.
Joan Venge

2

Nếu bạn có một đặc điểm kỹ thuật đủ chặt chẽ và hạn chế, bạn có thể chứng minh chương trình không có lỗi, nhưng chỉ dựa trên các giả định không thể chứng minh về hoạt động chính xác của mọi thứ khác trong hệ thống. Điều này cho thấy rằng không có cách nào để chứng minh rằng các thông số kỹ thuật sẽ được coi là chính xác bởi bất kỳ ai đặt ra vấn đề ban đầu, hoặc bởi bất cứ ai đang sử dụng dịch vụ.


1

Tôi tìm thấy phần No Shore của Jim Shore, một bài đọc rất hữu ích về chủ đề này. Dạng ngắn: Không thể phát triển mà không tạo ra lỗi - nhưng chúng ta có thể làm việc theo cách mà chúng ta phát hiện ra chúng càng sớm càng tốt.

Trong quá trình sản xuất mã. Ví dụ: bằng cách viết và chạy Kiểm tra đơn vị thường xuyên trong quá trình phát triển, chúng tôi liên tục đảm bảo mã thực hiện những gì nó phải làm. Ngoài ra, rất hữu ích khi viết lại mã hiện có theo cách mà nó thể hiện rõ nhất hành vi hệ thống dự định.

Tuy nhiên, trong trường hợp của bạn, bạn đang nói về một cơ sở mã đã tồn tại với hàng triệu dòng mã. Nếu bạn muốn nhận được một lỗi hệ thống miễn phí như vậy, trước hết bạn phải biết "lỗi là gì" đối với hệ thống này. Bạn có thể viết các bộ bài kiểm tra hậu hoc đảm bảo chức năng của hệ thống (nếu chưa có). Mạng của các thử nghiệm đó có thể đóng vai trò là định nghĩa gần đúng cho hành vi hệ thống chính xác. Nhưng bạn càng có nhiều mã, càng có nhiều nỗ lực tham gia vào các bài tập như vậy. Do đó, hầu hết các công ty đều thỏa hiệp: họ sống với người không hoàn hảo, làm việc với danh sách lỗi và bảo trì để loại bỏ những lỗi khó chịu nhất ra khỏi hệ thống.


1

Về việc xác minh bằng phần máy tính.

Có hai cách để xác minh chương trình bằng máy tính. Một là thử nghiệm, hai là sử dụng hệ thống bằng chứng.

Ngay khi kiểm tra toàn diện là không thể, kiểm tra trở nên không thể cho thấy rằng một chương trình không có lỗi, chỉ là nó có một số lỗi. (Và bạn có vấn đề phải chứng minh rằng bản thân các bài kiểm tra của bạn không kiểm tra sự hiện diện của lỗi).

Để sử dụng hệ thống bằng chứng, bạn bắt đầu từ các yêu cầu chính thức (và bản thân chúng có thể có lỗi, hy vọng ngôn ngữ được sử dụng cho các yêu cầu sẽ phù hợp hơn để thuyết phục bản thân rằng không có lỗi ở đó so với ngôn ngữ lập trình) và xây dựng / chứng minh với sự trợ giúp của các hệ thống bằng chứng rằng chương trình không có lỗi (và có câu hỏi về lỗi trong các hệ thống chứng minh, nhưng chúng đã tự chứng minh là đúng). Trạng thái hiện tại là một trình biên dịch cho tập hợp con C (và tập hợp con không mang tính học thuật, "CompCert hỗ trợ tất cả tập hợp con MISRA-C 2004 của C, cộng với nhiều tính năng bị MISRA loại trừ").


Để trích dẫn Donald Knuth (từ bộ nhớ): Bạn có thể chứng minh rằng chương trình không có lỗi, nhưng điều đó không có nghĩa là nó không có lỗi :-)
gnasher729

1

Không, bởi vì môi trường máy tính và phần mềm mà ứng dụng chạy trên sẽ tiếp tục thay đổi ngay cả khi mã bị đóng băng. Hệ điều hành tiếp tục phát triển với các bản vá và sửa lỗi, cũng như các thiết bị và trình điều khiển. Ngay khi bạn nghĩ rằng bạn đã đạt đến điểm không có lỗi đã biết, AMD hoặc nVidia sẽ phát hành bản cập nhật trình điều khiển video có tác động đến cách bạn tương tác với hệ thống con video. Bây giờ ứng dụng của bạn có khiếm khuyết về thị giác (như nhấp nháy, nhấp nháy hoặc giảm tốc độ khung hình) cho các khách hàng có thẻ video hoặc cấu hình nhất định (SLI? LOL).

Ngoài phần cứng và hệ điều hành, cũng có một số sản phẩm phần mềm trung gian bên dưới hầu hết các ứng dụng quan trọng cũng sẽ phát triển ngoài tầm kiểm soát của bạn và giống như khi bạn nhận được mã của mình ở trạng thái không khuyết tật, các lớp bên dưới bạn sẽ bị EOL'ed.

Công nghệ phát triển, cũng như doanh nghiệp thúc đẩy công nghệ và ý tưởng về "giải phóng" mã là không thể hoặc không khả thi. Doanh nghiệp yêu cầu một bộ tính năng mới sẽ không đáp ứng tốt với "chúng tôi đã khóa mã trong khi chúng tôi đuổi theo tất cả các lỗi đã biết và không ai báo cáo lỗi phần mềm hợp lệ trong X tháng". Ngay cả khi doanh nghiệp mua dòng đó, sau X tháng họ sẽ hỏi các tính năng mới sẽ ra sao và câu trả lời không thể là "chúng tôi đã quyết định gia hạn đóng băng vì Oracle chỉ phát hành bản vá và chúng tôi cần thêm X tháng nữa để chứng nhận rằng ".

Không, đến một lúc nào đó, doanh nghiệp sẽ tìm kiếm một nhóm phát triển linh hoạt hơn, hỗ trợ nhu cầu tiến lên với tốc độ của công nghệ. Đây là vấn đề cơ bản mà các nhóm phát triển hiện đại phải đối mặt.


0

Có nhưng bạn sẽ không bao giờ biết chắc chắn. Càng nhìn bạn càng thấy khó. Hệ thống càng nặng được sử dụng và các trường hợp cạnh được sử dụng càng nhiều, bạn sẽ càng thấy một sự không phù hợp khác với mục đích hoặc đặc điểm kỹ thuật ban đầu. Điều này ngụ ý một lỗi không phải là một điều chính xác và thường sẽ phụ thuộc vào diễn giải, về mức độ xấu của một số cá nhân đánh giá sự bất thường nhận thức.

Đó là một điều mờ nhạt. Vài hệ thống được chỉ định xuống đến bit cuối cùng. Nếu một hệ thống hoạt động tốt và người dùng không có khiếu nại (họ không bị lỗi gì) và họ hoàn toàn thích nghi với nó, bạn cũng có thể gọi nó là không có lỗi.


-2

Có thể liên tục cung cấp phần mềm không có lỗi, được cung cấp đủ kỷ luật và văn hóa nhóm được chia sẻ. .

Nhưng làm điều này, bạn thường không đặt ra để xây dựng một hệ thống 20 MLOC. Nếu viết mã không có lỗi không phải là mục tiêu của bạn, thì cũng không nên xây dựng một hệ thống MLOC.

Lý luận của riêng tôi là như sau:

Một số người có nhu cầu thực hiện. Một số người (có thể giống nhau, có thể là một người khác) có ngân sách để đáp ứng nhu cầu thông qua phần mềm viết. Tất cả những người này mong đợi nhận được một số lợi ích cho tiền của họ.

Người có ngân sách sẽ trả cho một số người (có thể giống nhau, có thể khác nhau) được gọi là lập trình viên , để những lập trình viên này sẽ biến một số lượng thời gian đã thỏa thuận thành phần mềm đáp ứng nhu cầu.

Do đó, những lập trình viên này làm việc trong việc chuyển đổi tiền của người khác thành phần mềm đáp ứng nhu cầu. Trách nhiệm của họ là đưa số tiền này vào sử dụng tốt.

Điều này có ý nghĩa sau đây liên quan đến câu hỏi của bạn:

  • Có một lỗi trong phần mềm, bạn sẽ sửa nó chứ? Bạn cần một lập trình viên để sửa lỗi và lập trình viên sẽ tốn tiền. Một lập trình viên không thể quyết định có nên chi tiền để làm việc đó hay không. Đó là vai trò của người nắm giữ ngân sách.
  • Tôi có thể xây dựng một phần mềm 20MLOC từ đầu mà không để lại các lỗi không trộn được không? Chà, đặt ra để xây dựng một 20MLOC cần có ý định chi một số tiền rất lớn. Điều này là ngu ngốc về tài chính. Và nó không được xây dựng trong một ngày. Nhưng phần mềm là cho nhu cầu ngày nay, không phải ngày mai. Sẽ có một nỗ lực sai lầm trong việc phát triển song song bằng cách thuê rất nhiều lập trình viên. Nhưng sau đó, tỷ lệ cược là bạn sẽ không có được một nền văn hóa chia sẻ và các lỗi sẽ xảy ra, lãng phí và trì hoãn sẽ xảy ra, và tiền sẽ hết để sửa chúng. Tôi chưa thấy hệ thống không có lỗi nào ở kích thước này. (Tôi đã thấy các hệ thống không có lỗi và các hệ thống 20MLOC, nhưng chúng không giống nhau)
  • Tôi chịu trách nhiệm duy trì một hệ thống 20MLOC mà tôi không viết. Tôi có thể đạt được các lỗi không? Điều này không phụ thuộc vào các lập trình viên. Họ không thể quyết định sửa lỗi vì đó không phải là tiền của họ. Có đủ ROI để sửa các lỗi còn lại không? Chà, hệ thống này đã xuất hiện được một thời gian và người dùng đã quen với nó và sử dụng các tiện ích của hệ thống để tạo lợi thế cho công việc hàng ngày của họ. Nếu bạn sửa lỗi theo nguyên tắc, người có tiền có thể phải trả tiền để phát triển lại một số tính năng không xác định đã biến mất khỏi hệ thống, khiến chi phí thậm chí còn nhiều hơn.

Đó là tất cả về tiền bạc, và đúng như vậy.


-2

Đúng.

Nhưng như bạn biết, nó đòi hỏi quá nhiều nỗ lực để có giá trị.

Trước khi tôi có thể bảo vệ câu trả lời của mình, trước tiên chúng ta phải xác định lỗi là gì:

  • Một lỗi là một hành vi trái với đặc điểm kỹ thuật.
  • Tuy nhiên, trục trặc trong đặc điểm kỹ thuật (ví dụ luật số 0 của robot) không được tính là lỗi phần mềm.
  • Các tính năng bổ sung không được tính là lỗi, trừ khi bị cấm theo thông số kỹ thuật.
  • Vì lý do tranh luận, mâu thuẫn trong đặc tả cũng không được tính là lỗi phần mềm.

Bây giờ, như bạn hy vọng đã biết, các kiến ​​trúc phần mềm tốt là mô-đun, sao cho mỗi mô-đun có thể được kiểm tra đơn vị (hoặc kiểm tra thủ công hoặc bất cứ điều gì) riêng lẻ. Thông qua kỷ luật và kiểm tra cẩn thận, có thể viết các mô-đun riêng lẻ không có lỗi trong đó.

"Nhưng đợi đã!" Tôi nghe bạn phản đối, "Điều gì xảy ra nếu một hành vi bất ngờ (nhưng dù sao cũng đúng) của một mô-đun gây ra lỗi trong một mô-đun khác?" Sau đó, lỗi là trong mô-đun thứ hai. Các mô-đun không có lỗi có thể được coi là API và API, như bạn biết, yêu cầu một số lưu ý để được sử dụng chính xác.

Viết mã chống đạn đòi hỏi kiến ​​thức sâu rộng về các trường hợp cạnh và logic dòng chảy từ phía nhà phát triển và hầu hết các nhà phát triển phần mềm đều không đủ thông minh để học hoặc đơn giản là không quan tâm. Hoặc thường xuyên hơn, họ đang ở thời hạn.

"Nhưng hãy cho tôi một chỗ đứng, và tôi sẽ chuyển thế giới." - Archimedes


Nó đòi hỏi nỗ lực, nhưng trả lại.
Laurent LA RIZZA

1
Nếu bạn bỏ các lỗi đặc tả ra khỏi phương trình, toàn bộ phần mềm của bạn sẽ trở nên vô dụng: Thông số kỹ thuật chỉ là công cụ để ghi lại nhu cầu của người dùng theo cách tương đối chính thức, nhưng cuối cùng, đó là người dùng cần được thỏa mãn, không phải là đặc tả. Và việc tạo ra các đặc tả là một phần của sự phát triển phần mềm như viết mã. Rốt cuộc, một thông số chính thức hoàn chỉnh sẽ mô tả hành vi của hệ thống giống như mã cuối cùng, thông số kỹ thuật này không thực thi hiệu quả.
cmaster
Khi sử dụng trang web của chúng tôi, bạn xác nhận rằng bạn đã đọc và hiểu Chính sách cookieChính sách bảo mật của chúng tôi.
Licensed under cc by-sa 3.0 with attribution required.