Phần mềm phức tạp nên thực hiện bao nhiêu?

Trọng tâm của câu hỏi này: Một số phần mềm thực hiện "công việc phụ" để tăng khả năng có kết quả "cuối cùng thành công / thỏa đáng", mặc dù có một hoặc nhiều lỗi nội bộ trong phần mềm, đòi hỏi thời gian thực hiện lâu hơn khi những lỗi đó xảy ra. Tất cả những điều này xảy ra mà không có kiến ​​thức của người dùng nếu kết quả thành công.

Định nghĩa phần mềm phức tạp:

• Chứa mã được viết bởi (đóng góp từ) hơn 10 nhà phát triển trong suốt vòng đời của nó và không được viết trong cùng khung thời gian
• Phụ thuộc vào hơn 10 thư viện bên ngoài, mỗi thư viện đều có cảnh báo
• Một tác vụ phần mềm thông thường (để tạo kết quả mà người dùng muốn) yêu cầu 10 tham số đầu vào trở lên, trong đó hầu hết chúng có giá trị mặc định nhưng có thể định cấu hình nếu người dùng cần điều khiển.
• Quan trọng nhất, phần mềm có độ phức tạp phù hợp liên quan đến nhiệm vụ đang được thực hiện, tức là không phức tạp không cần thiết .

Chỉnh sửa: Thế nào là phức tạp? Xin vui lòng xem Có một sự khác biệt lớn giữa Phức tạp và phức tạp . (đương dân trực tiêp)

Định nghĩa về sự dư thừa / mạnh mẽ trong câu hỏi này :
(Đã thêm tính mạnh mẽ dựa trên ý kiến)

• Nếu tác vụ phần mềm không thành công khi bộ tham số hiện tại được sử dụng, hãy thử các tham số khác nhau.
  • Rõ ràng, phải có kiến ​​thức bên trong rằng các tham số "khác nhau" đó sử dụng một đường dẫn mã khác nhau, có thể dẫn đến một kết quả khác (hy vọng tốt hơn).
  • Đôi khi những đường dẫn mã khác nhau này được chọn dựa trên sự quan sát của các thư viện bên ngoài.
• Cuối cùng, nếu tác vụ thực tế được thực hiện hơi khác so với thông số kỹ thuật của người dùng, người dùng sẽ nhận được báo cáo nêu chi tiết về sự khác biệt.
• Cuối cùng, giống như các tham số cấu hình 10 cộng, dự phòng và báo cáo cũng có thể định cấu hình.

Ví dụ về phần mềm như vậy:

• Di chuyển cơ sở dữ liệu
  • Cơ sở dữ liệu kinh doanh
  • Cơ sở dữ liệu kiểm soát nguồn, v.v.
• Chuyển đổi hàng loạt giữa tài liệu Word và tài liệu OpenOffice, PowerPoint và OpenOffice Draw, v.v.
• Tự động dịch toàn bộ trang web
• Phân tích tự động gói phần mềm, chẳng hạn như Doxygen, nhưng trong đó phân tích cần phải đáng tin cậy hơn (không chỉ là một công cụ tài liệu)
• Giao tiếp mạng, nơi các gói có thể bị mất và một số lần thử lại được mong đợi

Câu hỏi này ban đầu được lấy cảm hứng từ Làm thế nào để bạn đối phó với mã xấu cố ý?
nhưng bây giờ chỉ tập trung vào một trong những nguyên nhân gây phình to phần mềm. Câu hỏi này không giải quyết bất kỳ nguyên nhân nào khác của sự phình to phần mềm, chẳng hạn như bổ sung các tính năng mới.

Có thể liên quan:

• Làm thế nào để đối phó với các mã phức tạp trong các dự án (rất lớn)
• Làm thế nào để mọi người quản lý để viết và duy trì mã cực kỳ phức tạp và khó đọc?

Đây là một câu hỏi kinh doanh, không phải là một kỹ thuật.

Đôi khi tôi đang mã hóa với các nhà nghiên cứu hoặc trên một nguyên mẫu, vì vậy chúng tôi sẽ xây dựng một cái gì đó với độ bền rất thấp. Nếu nó bị hỏng, chúng tôi sửa nó. Không có điểm nào để đầu tư vào ma thuật bổ sung nếu chúng ta sẽ sớm vứt bỏ mã.

Nhưng nếu người dùng hệ thống của bạn cần nó mạnh mẽ, bạn nên xây dựng nó theo cách đó. Và bạn nên làm cho nó trở nên mạnh mẽ theo những cách mà bạn và họ cần để tối đa hóa thành công lâu dài, trong khi bỏ qua các loại dư thừa / mạnh mẽ mà họ không cần.

Nói chung, tôi bắt đầu thô và sau đó thêm mạnh mẽ theo thời gian. Tôi thường xuyên đặt câu hỏi như phần này của quy trình lập kế hoạch bình thường. Tôi thường làm việc theo phong cách Lập trình cực đoan, nơi chúng tôi tạo ra một danh sách dài các tính năng mong muốn và tôi cũng đặt các tính năng mạnh mẽ ở đó. Ví dụ: "Hệ thống tồn tại sự thất bại của bất kỳ hộp nào", được trộn lẫn với những thứ như "Người dùng có thể tham gia bằng thông tin đăng nhập Facebook". Bất cứ ai đi lên trước, tôi xây dựng trước.

Phần mềm phức tạp thường là dư thừa như bạn có thể biết, nhưng rõ ràng không phải vì đó là cách tốt nhất để làm mà vì các nhà phát triển có xu hướng "giải quyết" mã hiện tại thay vì cố gắng hiểu chi tiết cách thức hoạt động của phần mềm.

Tuy nhiên, nếu bạn hỏi tôi mức độ dư thừa sẽ được chấp nhận, tôi sẽ không nói gì. Sự dư thừa là một trong nhiều tác dụng phụ của sự phức tạp, là kiến ​​trúc của sự đơn giản. Có thể cho rằng, sự đơn giản nên ngồi ở ghế sau nếu thời gian có tầm quan trọng lớn hơn, mặc dù tôi nhấn mạnh rằng những người cho rằng thời gian là điều cốt yếu hiếm khi là những người thực sự quan tâm trong việc phát triển phần mềm. Thông thường, người quản lý dự án của bạn sẽ kích thích bạn hoàn thành công việc càng sớm càng tốt để bạn có thể quay lại với các vấn đề cấp bách hơn, tuy nhiên, nhiệm vụ của bạn là lập trình viên phải biết khi nào công việc được hoàn thành. Tôi nghĩ rằng công việc không được thực hiện cho đến khi bạn tích hợp thành công vào chương trình như ý muốn. Có lẽ chương trình rất phức tạp,

Tuy nhiên, cần phải nói rằng khi làm như vậy, bạn có thể phải tạo mã dự phòng. Nếu dự án đã quá dư thừa, thực tế có thể đơn giản hơn để tiếp tục mô hình giả sử tất nhiên ông chủ của bạn không có một vài tuần để giết cho phép bạn tái cấu trúc toàn bộ dự án.

Chỉnh sửa: Trong phần tái hiện câu hỏi, tôi sẽ thêm một chút về sự mạnh mẽ. Theo tôi, việc kiểm tra tham số chỉ nên được thực hiện nếu A) bạn chấp nhận một định dạng rất cụ thể như giá trị ngày dưới dạng chuỗi hoặc B) các tham số khác nhau có khả năng có thể xung đột với nhau hoặc loại trừ lẫn nhau.

Với A), các yêu cầu mà tham số khớp với một định dạng cụ thể thường rất quan trọng đối với sự cần thiết của phương thức (chẳng hạn như chuyển đổi thành ngày từ một chuỗi). Về mặt kỹ thuật, nó vẫn có thể xảy ra trong chương trình của bạn mà không cần thiết nhưng tôi rất khuyến khích bạn loại bỏ các khả năng này và chỉ chấp nhận các tham số mà bạn biết đại diện cho loại dữ liệu bạn đang tìm kiếm (Chấp nhận một ngày thay vì một chuỗi nếu điểm không phải là để chuyển đổi chẳng hạn. Nếu việc chuyển đổi cũng phải được thực hiện, hãy sử dụng một phương thức tiện ích để chuyển đổi chuỗi trước khi chuyển nó sang phương thức).

Đối với B), các tham số loại trừ lẫn nhau đại diện cho một cấu trúc xấu. Phải có hai lớp, một lớp xử lý một trường hợp và một lớp khác xử lý nó theo một cách khác. Tất cả các hoạt động phổ biến có thể được thực hiện trong một lớp cơ sở duy nhất để tránh dư thừa.

Trong các tình huống trong đó số lượng tham số cho một phương thức đạt hơn 10, tôi bắt đầu xem xét một tệp thuộc tính chứa tất cả các tham số này rất có thể sẽ không thay đổi thường xuyên. Nếu chúng thay đổi, bạn có thể lưu mặc định trong tệp thuộc tính và thêm phương thức "setPropertyName ()" cho phép bạn ghi đè mặc định khi chạy.

Phần mềm nên được tha thứ cho lỗi của người dùng và hoàn toàn không dung nạp lỗi của lập trình viên.

Có nghĩa là, phần mềm phải rất mạnh mẽ và cho phép phục hồi trơn tru cho những thứ như lỗi đầu vào của người dùng và lỗi cấu hình hệ thống. Ít nhất là một thông báo lỗi thân thiện nêu rõ lỗi xảy ra ở đâu (hộp nhập, tệp cấu hình, đối số dòng lệnh, v.v.) và ràng buộc nào đã bị vi phạm ("phải nhỏ hơn X ký tự", "các tùy chọn hợp lệ là [X , Y, Z] ", v.v ...) Để tăng cường độ mạnh mẽ, phần mềm có thể đề xuất một giải pháp thay thế hoặc sử dụng mặc định hợp lý (nhưng phải luôn chỉ ra rằng nó không sử dụng chính xác những gì người dùng chỉ định).

Tôi không thể nghĩ ra nhiều tình huống thử lại tự động với các mặc định khác nhau, nhưng có một số (tự động thử lại để thiết lập liên kết liên lạc có vẻ hợp lý). Tôi đồng ý với @William rằng mức độ 'dư thừa' này là một quyết định kinh doanh.

Mặt khác, không nên có sự mạnh mẽ về thời gian chạy đối với lỗi lập trình viên. Nếu có các điều kiện trước cho các tham số của hàm, chúng cần được kiểm tra bằng các xác nhận, không phải kiểm tra thời gian chạy. Đó là một tiểu thú cưng khổng lồ của tôi để xem kiểm tra và báo cáo lỗi sai dự phòng trên cùng một hoặc ba cấp độ trong ngăn xếp cuộc gọi:

 int A(int x)
 {
   if (x==0) return -1
   ...
 }
 int B(int x)
 {
   if (x==0) return -1
   err = A(x)
   if (err) return err;
   ...
 }
 // and so on and so on....

Đây chỉ là sự phức tạp không cần thiết bổ sung. Bạn không nên dành thời gian để tìm ra cách một chức năng sẽ xử lý một lỗi được đưa ra bằng cách sử dụng sai một chức năng khác. Nếu đây là loại 'sự mạnh mẽ' mà bạn đang đề cập - bạn không cần nó. Thay thế nó bằng khẳng định và kiểm tra tích hợp kỹ lưỡng.

Đó là một điều yêu cầu.

Có một yêu cầu cho sự mạnh mẽ?

"Khi liên kết truyền thông không thành công, các gói lỗi sẽ bị loại bỏ" "Khi liên kết tiếp tục hoạt động, không có giao dịch nào được xử lý hai lần"

nên có trường hợp sử dụng để phục hồi lỗi (nếu không thì làm sao bạn biết nó sẽ xảy ra như thế nào?)

Để nó cho các lập trình viên phát minh ra sự mạnh mẽ khi họ đi (nếu cần) sẽ dẫn đến các hệ thống "ma thuật".

Tất cả các hệ thống phép thuật trở thành ma thuật tào lao theo thời gian. Sửa lỗi trong nền che giấu sự xuất hiện của các lỗi, do đó các lỗi sẽ không được sửa chữa, do đó hệ thống cuối cùng sẽ xuống cấp đến trạng thái entropy lớn hơn; và chạy như crap, vì nó luôn luôn sửa lỗi. Bạn phải có một giới hạn để ngăn hệ thống đi vào trạng thái xuống cấp vĩnh viễn.

Một số hoạt động có thể đảm bảo một cách tiếp cận "thử lại", đặc biệt nếu chúng phụ thuộc vào các tài nguyên bên ngoài như cơ sở dữ liệu. Ví dụ: nếu cơ sở dữ liệu không thể được kết nối hoặc truy vấn không thành công, thao tác có thể được thử lại một số lần nhất định trước khi bỏ và ném lỗi lên mức cao hơn. Tuy nhiên, trong một số logic, thử cùng một thứ nhiều lần thường là một triệu chứng của mã xấu và suy nghĩ ma thuật che giấu các vấn đề thực sự.