Các nguyên nhân dẫn đến một phần mềm bị quá tải là gì? [đóng cửa]

Hôm nay tôi quyết định thực hiện cài đặt sạch cho trình điều khiển Creative Sound Blaster, vì chúng luôn tự bắt đầu bị trục trặc sau một thời gian. Và điều đó có nghĩa là tôi phải trải qua toàn bộ quy trình dọn dẹp. Và tôi đã mất gần 2 giờ ..

Và thành thật mà nói, tôi không thể thấy một lý do tại sao?! Và mặc dù Creative, IMHO, là người chiến thắng vị trí số 1 tuyệt đối để sản xuất phần mềm chất lượng kém không bao giờ hoạt động, vấn đề phình to không chỉ dành riêng cho họ.

PC với trình điều khiển máy ảnh kỹ thuật số Canon sẽ có khoảng 10 mục Canon được kết nối với tất cả các loại kết nối. Visual Studio cũng là một ví dụ điển hình, có khoảng 50 mục nhập để cài đặt đầy đủ và việc sửa chữa điều đó chỉ có thể với việc hoàn thành. Và một khi nó thậm chí đã phá hỏng toàn bộ cài đặt hệ điều hành khi tôi nâng cấp từ VS2k8 lên VS2k8SP1 hoặc một cái gì đó. Vì hóa ra 5 GB dung lượng trống là không đủ cho bản vá 300Mb ...

Vì vậy, đây thực sự có vẻ là một vấn đề phổ biến. Hầu như mọi ứng dụng hiện nay thường chứa các trình giải nén, nhiều "bạn bè" gián điệp được cài đặt, trình điều khiển thường có dung lượng khoảng 600Mb cho mọi thứ, kể cả máy in, v.v.

Nhưng tại sao? Có phải là lỗi của nhà phát triển? Các ứng dụng như thế là cơn ác mộng để hỗ trợ, ngày nay chúng không bao giờ hoạt động 100% và hầu hết tất cả người dùng mà tôi biết đều rất tiêu cực về tất cả những gì họ có được khi cài đặt trình điều khiển bắt buộc cho ổ USB / Máy in / Máy ảnh / Thẻ âm thanh / Trình duyệt.

Có vẻ như NSIS từ Nullsoft là hệ thống thiết lập sạch duy nhất không bị cồng kềnh, từ những gì tôi biết, ví dụ, cài đặt Firefox. Sạch sẽ, khá nhiều cài đặt dựa trên xcopy mà không có bất kỳ vấn đề.

Vậy tại sao mọi người không sử dụng các thiết lập và ứng dụng đơn giản không được root trên 30 lớp kết nối? Có phải vì các nhà phát triển lười biếng? Sử dụng các công cụ codegen? Có phải vì các tập đoàn buộc các ứng dụng nặng như một thứ mà người dùng sẽ yêu thích? Nguyên nhân là gì, và có một phần mềm hy vọng sẽ trở lại cơ bản một ngày nào đó? Các bước để tránh viết phình khi bạn bắt đầu ứng dụng mới từ đầu là gì?

Tôi đoán là có rất nhiều tính năng mà ai đó nghĩ là một ý tưởng tốt. Tuy nhiên, nếu nhiều người có những ý tưởng riêng biệt được kết hợp vào một ứng dụng thì đây là cách nó có thể trở nên phức tạp. Tôi sẽ không đổ lỗi cho nhà phát triển trong trường hợp các sản phẩm của công ty lớn, nơi cần có người quản lý sản phẩm chịu trách nhiệm về những gì có trong sản phẩm và cách tối ưu hóa nó từ nhiều khía cạnh khác nhau.

Một khía cạnh khác của vấn đề này là nợ kỹ thuật có khả năng không được quản lý tốt trong hầu hết các trường hợp vì nó không được coi là một khoản đầu tư lớn về thời gian. Tôi nghi ngờ các tính năng mới và sửa lỗi có ý nghĩa hơn so với tái cấu trúc hoặc các nhiệm vụ nợ khác có vẻ như có ít giá trị kinh doanh ngay lập tức. Bao lâu thì một nhóm các nhà phát triển sẽ có một vài tuần để dọn sạch mã kế thừa nếu cơ sở mã khá cũ? Tôi đoán sẽ không thường xuyên.

Để trích dẫn Joel trong Chiến lược thư IV: Bloatware và huyền thoại 80/20 :

[...] Có rất nhiều lý do tuyệt vời cho bloatware. Đối với một người, nếu các lập trình viên không phải lo lắng về mã của họ lớn như thế nào, họ có thể gửi nó sớm hơn. [...] Nếu nhà cung cấp phần mềm của bạn dừng lại, trước khi giao hàng và dành hai tháng để giảm mã xuống để làm cho nó nhỏ hơn 50%, lợi ích ròng đối với bạn sẽ không thể chấp nhận được. [...] Nhưng sự mất mát đối với bạn khi chờ thêm hai tháng cho phiên bản mới là có thể cảm nhận được và sự mất mát đối với công ty phần mềm phải từ bỏ hai tháng bán hàng thậm chí còn tồi tệ hơn.

Rất nhiều nhà phát triển phần mềm bị quyến rũ bởi quy tắc "80/20" cũ. Nó dường như có rất nhiều ý nghĩa: 80% mọi người sử dụng 20% ​​các tính năng. Vì vậy, bạn thuyết phục bản thân rằng bạn chỉ cần thực hiện 20% các tính năng và bạn vẫn có thể bán được 80% số lượng bản sao.

Thật không may, nó không bao giờ giống nhau 20%. Mỗi người sử dụng một bộ tính năng khác nhau . [...]

Khi bạn bắt đầu tiếp thị sản phẩm "lite" của mình và bạn nói với mọi người, "này, nó chỉ có 1 MB", họ có xu hướng rất vui, sau đó họ hỏi bạn rằng nó có tính năng quan trọng của họ không , và nó không, vì vậy họ không mua sản phẩm của bạn.

Một phần lớn của nó là để làm với sự phụ thuộc của một sản phẩm. Hệ điều hành của bạn có rất nhiều thư viện tiêu chuẩn cho mọi thứ. Tuy nhiên, các thư viện tiêu chuẩn này có các phiên bản khác nhau trong suốt quá trình phát triển của HĐH và bất kỳ trình cài đặt chung nào cũng không thể cho rằng phiên bản cụ thể mà nó được xây dựng sẽ thực sự có mặt trên HĐH.

Do đó, trình cài đặt đầy đủ sẽ cần bao gồm phiên bản chính xác của mọi phụ thuộc để đảm bảo rằng mọi thứ chắc chắn sẽ hoạt động sau khi cài đặt, bất kể trạng thái ban đầu của mỗi phụ thuộc trên máy tính đích. Đây có thể là một sự phình to đáng kể đối với một số loại ứng dụng nhất định, ví dụ như các ứng dụng dựa trên .NET cần được triển khai cho các hệ thống Windows XP.

Cho đến gần đây, một hệ thống trình cài đặt mà tôi đã làm việc cần cài đặt mọi phiên bản .NET trước đó để có thể triển khai phiên bản mới nhất, do đó, có nghĩa là bất kỳ ứng dụng .NET 3.5 nào cũng yêu cầu cài đặt nhị phân cho .NET 1, 2, 2.5 và 3 TRÊN TOP 3.5. Trong trường hợp này, chỉ có trình cài đặt là cồng kềnh.

Một cách giải quyết khác là trình cài đặt web, chỉ tải xuống các thành phần thực sự không có trên hệ thống đích - và đây có thể là một lợi ích khổng lồ / kích thước khổng lồ. Tất nhiên, nó giới hạn cài đặt của bạn vào các hệ thống có kết nối internet.

Tôi nghĩ rằng rất nhiều trong số đó phải làm với lớp trên lớp mã thư viện. Rõ ràng khi bạn sử dụng một thư viện, bạn không sử dụng mọi thứ trong đó, do đó, số tiền thừa sẽ tăng lên khi bạn bao gồm ngày càng nhiều thư viện.

Kết hợp với thực tế là chi phí một giờ làm việc từ một lập trình viên ngày càng đắt đỏ trong khi sức mạnh xử lý / lưu trữ của máy tính thông thường ngày càng rẻ hơn theo năm, bạn thấy rằng nó thực sự hiệu quả hơn về mặt chi phí.

• "Chúng tôi cần một cái gì đó để làm X. Hãy sử dụng thư viện $ BIGFATLIBDESIGNEDFORSOMETHINGELSE, bởi vì tôi đã sử dụng nó trong một dự án khác"
• "Tôi nghĩ rằng chúng ta không cần phần mã này nữa, nhưng để chắc chắn rằng không có gì phá vỡ, chỉ cần giữ nó"
• Không hoặc không đủ bài kiểm tra đơn vị, dẫn đến
• Không tái cấu trúc
• Không có theo dõi, nơi các cài đặt đã được lưu trữ trong nhiều năm qua, vì vậy bây giờ các cài đặt ở khắp mọi nơi
• ...

Đó là một vòng luẩn quẩn mà mọi người trong chu kỳ tuyệt vọng có thể bị đổ lỗi . Một chu kỳ tuyệt vọng bao gồm các bước sau:

1. Người kinh doanh yêu cầu các tính năng cồng kềnh.
2. Các nhà phát triển triển khai các tính năng cồng kềnh mặc dù họ biết rằng họ không nên.
3. Khách hàng trả tiền cho các tính năng cồng kềnh mặc dù họ chỉ muốn sản phẩm chứ không phải tính năng ngu ngốc.
4. Người kinh doanh tin rằng khách hàng muốn các tính năng cồng kềnh.
5. Chuyển đến bước một và lặp lại.

Làm thế nào để bạn ngăn chặn nó? Không có câu trả lời dễ dàng về cách làm, nhưng rõ ràng là để dừng chu kỳ thì một trong những bước phải bị phá vỡ. Do đó, nó chỉ có thể bị phá vỡ bởi doanh nghiệp, nhà phát triển hoặc người tiêu dùng thực hiện một hành động mang tính cách mạng.

1. Một kỹ sư đã cố gắng tối ưu hóa một mô-đun nhưng đã giới thiệu một số vấn đề của khách hàng. Sau đó, quản lý của anh nói không. Sau đó, kỹ sư quyết định không "gây rắc rối" cho đến khi gặp rắc rối.
2. Đối với một hệ thống phức tạp, nhà cung cấp đã thêm nhiều bản vá và sửa hàng ngàn lỗi để ổn định trong môi trường của khách hàng. Nó không có chất lượng tốt theo quan điểm của phần mềm nhưng nó hoạt động. Không ai muốn viết lại nó để sửa cùng một số lượng lỗi.
3. vì lý do tương thích ngược, ngay cả khi một tính năng không phổ biến trên thị trường, chúng ta cần giữ nó ở đó.

Sự lười biếng luôn luôn thay đổi, đó là nguyên nhân gây ra sự phình to. (hoặc bùn như trong bài báo chuyên đề về chủ đề này, Big Ball of Mud )

Ví dụ, nơi tôi làm việc, chúng tôi có một ứng dụng C ++ "di sản" được thiết kế khá tốt, Các máy khách nói chuyện với một API nói chuyện với một máy chủ hoạt động DB. Tất cả hợp lý được thực hiện. Gần đây, chúng tôi cần một mô-đun bổ sung, nhưng thay vì triển khai nó một cách chính xác, nhà phát triển đã quyết định triển khai điều này trong .NET, và tệ hơn nữa, anh ấy đã quyết định rằng việc truy cập dữ liệu qua API là quá khó (không phải ...) anh ấy sẽ tạo kết nối DB trực tiếp Vì vậy, bạn thấy làm thế nào loại lộn xộn xảy ra. (và tất cả với sự đồng ý của TA đã đặt "nhanh" lên "tốt")

Tôi cũng đã từng thấy loại điều này trước đây - tại một địa điểm cũ, một phần nhỏ của GUI là html, vì một số nhà phát triển nghĩ rằng nên viết dữ liệu bằng html và hiển thị GUI đó. Vì vậy, 1 phần nhỏ làm một cái gì đó khác với phần còn lại.

Nói tóm lại, lười biếng là xấu, và tính nhất quán là tốt (bất kể công nghệ được sử dụng). Tôi muốn có một ứng dụng toàn MFC hơn một ứng dụng là một phần MFC và một phần Winforms và một phần WebGL với nhiều kiến ​​trúc back-end khác nhau buộc tất cả lại với nhau.