Bạn nghĩ gì là nguyên nhân chính của lỗi phần mềm (và cách giảm thiểu chúng) [đã đóng]

Tôi xác định khiếm khuyết là:

"một cái gì đó trong thiết kế ứng dụng hoặc mã ngăn nó hoạt động theo yêu cầu."

Tôi đang tìm kiếm ý tưởng về nguyên nhân của các khiếm khuyết, ví dụ như yếu tố con người, thiếu thử nghiệm, thiếu nguyên mẫu và các ý tưởng có thể để giảm thiểu những điều này.

Nguyên nhân chính của lỗi phần mềm là giải thích.

Giải thích khách hàng của một tính năng khác với giải thích thiết kế.

Giải thích thiết kế khác với giải thích lập trình viên.

Hầu hết các phương pháp đã phát minh ra cách để chống lại hiệu ứng này. Nhưng cuối cùng, chúng ta chỉ là con người và chúng ta không hoàn mỹ. Bên cạnh đó, thường có một áp lực thời gian và hầu hết các phép thuật phương pháp thường bị bỏ qua trong khi chịu áp lực.

Kiểm tra chỉ có thể phát hiện sớm các vấn đề. Nhưng ngay cả những người thử nghiệm cũng là con người và có thể kiểm tra 100%. Nếu bạn muốn phát hành trước khi vũ trụ kết thúc.

Tôi coi nguyên nhân chính của lỗi phần mềm là lập trình viên.

Không nói rằng chỉ để gây cười, nhưng bởi vì một trong những vấn đề lớn mà tôi quan sát được trong công việc của mình là thu thập các yêu cầu kém, cùng với sự hiểu biết kém về lĩnh vực vấn đề, gây ra các khiếm khuyết lớn và các vấn đề về khả năng sử dụng trong dự án.

Một phần trong đó xuất phát từ việc không sẵn sàng tìm hiểu / hiểu thuật ngữ của người dùng cuối, gây ra sự hiểu lầm.

Một phần trong số đó đến từ việc nói về công nghệ quá sớm trong quá trình cho những người không biết bạn đang nói về vấn đề gì hoặc tại sao nó lại quan trọng.

Ví dụ điển hình nhất là khi tôi tình cờ nghe thấy một trong những lập trình viên cố gắng tìm hiểu các câu hỏi / câu trả lời sẽ diễn ra trong bao lâu ... Tôi biết anh ta đang cố gắng tìm ra trường kích thước nào sẽ được sử dụng trong cơ sở dữ liệu, nhưng bộ phận yêu cầu điều này không có sương mù tại sao điều đó quan trọng - hoặc không gian đó được tính. Đối với chúng tôi điều đó có vẻ hiển nhiên, nhưng với họ đó là một sự mặc khải thực sự.

Nguyên nhân chính của lỗi là quản lý tồi ;)

Nghiêm túc mà nói, một nhà phát triển làm việc trong điều kiện tốt, không được yêu cầu làm việc quá sức, cắt giảm chất lượng, có công cụ phù hợp, điều kiện làm việc yên tĩnh, v.v sẽ tạo ra ít lỗi hơn so với người làm việc dưới áp lực cứng.

Ngoài ra quản lý thuê các nhà phát triển xấu cũng giúp tăng số lượng lỗi.

Quản lý kém .

(từ chối trách nhiệm: Tôi phải thuê và quản lý nhà phát triển)

Tôi không thấy bất kỳ nguyên nhân chính nào - nhưng một nguyên nhân chưa được đề cập là việc ghép không chủ ý với mã khác . Viết mã có tác dụng phụ vô hình, phá vỡ các lớp trừu tượng, đưa ra các giả định về dữ liệu (các biến không, hằng không và không có đầu vào từ người dùng là an toàn), giải quyết những điều mà nó không cần phải quan tâm chính nó với, và như vậy.

Hầu hết các thực tiễn phát triển mà tôi nghiên cứu sôi sục để giảm bớt N, bởi vì sự phức tạp của một chương trình ít nhất O(N^2)và có thể O(k^N). Xác định Nlà một bài tập cho người đọc, nhưng tôi đang nghĩ về những thứ như sự phức tạp theo chu kỳ ở đây. Đóng gói logic và dữ liệu có tác dụng giảm N bằng cách ngăn chặn vấn đề.

Sự bất lực để nghĩ về mọi thứ.

Chưa hoàn thiện

Khoảng cách truyền thông. Trong bộ sưu tập yêu cầu. Trong lịch trình. Trong tài liệu thiết kế. Trong đặc tả chức năng. Trong mã (khoảng cách giữa những gì lập trình viên muốn và những gì anh ta nói với trình biên dịch).

Nghi thức xã giao. Đó là xã hội không thể chấp nhận để gọi một người không có khả năng.

Lao vào mọi thứ mà không hiểu đầy đủ về chúng. Bắt đầu viết mã mà không hiểu đầy đủ các yêu cầu chức năng hoặc kiến ​​trúc kỹ thuật.

Lập trình nên gần như tự động, chỉ cần viết ra những điều hiển nhiên và đã được thực hiện trong tâm trí. Trong thực tế, tôi thấy rất nhiều lỗi trong mã để cố gắng xử lý chính xác những gì mã phải làm. Tôi đã phạm tội về điều này nhiều lần.

Errare humanum est

Lịch trình áp lực chắc chắn là một nguồn mạnh mẽ.

Các nhà phát triển vội vã không dành thời gian để xác định đầy đủ các yêu cầu hoặc hiểu đầy đủ ý định đằng sau các yêu cầu hoặc điều tra đầy đủ các giải pháp thay thế để tìm giải pháp tốt nhất hoặc suy nghĩ đầy đủ về tất cả các trường hợp cạnh và tương tác của các thay đổi họ đang thực hiện hoặc phát triển một bộ đầy đủ các trường hợp thử nghiệm hoặc thực hiện đầy đủ tất cả các thử nghiệm đơn vị hoặc thực hiện thử nghiệm tích hợp đầy đủ hoặc xem xét đầy đủ các phụ thuộc nền tảng hoặc kiểm tra đầy đủ trình cài đặt hoặc ghi lại đầy đủ những gì chúng đã làm để nhà phát triển tiếp theo có thể hiểu ....

Một điều khác cần được đề cập là không có bài kiểm tra bên ngoài. Khi nhà phát triển viết các bài kiểm tra và chạy chúng, anh ta chỉ kiểm tra diễn giải của mình chứ không phải yêu cầu thực tế. Mặc dù kiểm tra đơn vị được viết bởi các nhà phát triển là hữu ích để bắt một số lỗi, hầu hết các lỗi sẽ vượt qua các kiểm tra này nhưng không phải là những gì người dùng muốn hoặc cần. Bất kỳ phần mềm nào không được kiểm tra bởi người khác không phải nhà phát triển đều không được kiểm tra (Và tôi không có nghĩa là chỉ chạy thử nghiệm của nhà phát triển).

Đó là vì công nghệ phần mềm vốn đã phức tạp. Bài tiểu luận "Không có viên đạn bạc" thảo luận về điều này.

Trớ trêu thay, nhiều câu trả lời khác ở đây lại liên quan đến các chủ đề "vô tình phức tạp", theo ngôn ngữ của bài tiểu luận đó, trong khi thực tế hầu hết những gì các nhà phát triển phần mềm làm là "về cơ bản là phức tạp", do đó, về bản chất nó tạo ra phần mềm rất khó, phần mềm sẽ có lỗi và công việc của chúng tôi là xử lý nó.

Việc không hiểu phần mềm như một mạng lưới các máy trạng thái, các nguyên tắc làm cơ sở cho hoạt động của chúng (trạng thái, quyết tâm và chuyển đổi của chúng) và các tương tác của các máy trạng thái.

Viết mã mà thất bại âm thầm so với mã báo cáo tất cả các lỗi.

Thiếu kiểm tra những thứ "không thể xảy ra" hoặc không có khả năng xảy ra là một vấn đề lớn. Đôi khi sự hoàn hảo là kẻ thù của điều tốt. Nếu nó không xứng đáng với một hệ thống phân cấp ngoại lệ được suy nghĩ kỹ, một số xử lý nhanh và bẩn luôn tốt hơn không có gì. Tôi là một người rất lớnfan hâm mộ của thất bại nhanh chóng, của khẳng định và để lại khẳng định có tác động không đáng kể đến hiệu suất trong các bản dựng phát hành. Ngay cả trong các tập lệnh một lần nhanh và bẩn, nơi tôi kiểm soát tất cả dữ liệu đầu vào, tôi vẫn xử lý một số lỗi nhanh / bẩn, thường chỉ với một chức năng tương đương với xác nhận nhưng luôn luôn tồn tại. Nguyên tắc nhỏ của tôi là, nếu nó không có khả năng xảy ra hoặc bạn nghĩ điều đó không thể xảy ra, thì không cần phải thất bại một cách duyên dáng với thông báo lỗi thân thiện với người dùng, nhưng ít nhất nó sẽ thất bại nhanh chóng với thông báo lỗi cung cấp cho một lập trình viên một số gợi ý về những gì đã sai.

Chỉnh sửa: Một chiến thuật hữu ích có liên quan là sử dụng các xác nhận làm công cụ gỡ lỗi chính và để chúng ở đó sau khi phiên gỡ lỗi kết thúc. Từ thời điểm đó, cơ sở mã của bạn sẽ có một số kiểm tra trạng thái tích hợp sẵn khiến cho các lỗi liên quan rất khó xảy ra lần nữa. Điều này đặc biệt hữu ích cho mã mà khó có thể bỏ qua.

Nguyên nhân chính của lỗi phần mềm là viết mã.

Viết ít mã hơn và bạn sẽ có ít lỗi hơn ;-)

Ở một cấp, quản lý. Nhưng đó không chỉ là PHB. Đó là sự quản lý của chính mã, có thể hoặc không thể là sự phản ánh của quản lý doanh nghiệp.

Những người tham gia trong toàn bộ "vòng đời" cần được đầu tư đầy đủ vào chất lượng và tạo ra một sản phẩm không chết . Phần mềm chính nó có sự hứa hẹn của không bao giờ phá vỡ, được trừu tượng tin cậy thích hợp. Vấn đề chỉ là liệu các nhà xây dựng phần mềm có quan tâm đến việc có hoạt động hoàn hảo đó hay không.