Каковы причины, которые приводят к перегруженному программному обеспечению? [закрыто]

Сегодня я решил выполнить чистую установку драйверов Creative Sound Blaster, так как они через некоторое время сами начинают глючить. И это означало, что мне пришлось пройти всю процедуру очистки. И это заняло у меня почти 2 часа ..

И, честно говоря, я не вижу причины, почему? И хотя Creative, ИМХО, является абсолютным победителем 1-го места по производству некачественного программного обеспечения, которое никогда не работает, проблема раздувания не является для них исключительной.

ПК с драйвером цифровой камеры Canon будет иметь около 10 записей Canon, которые связаны со всеми видами соединений. Visual Studio также является ярким примером, около 50 записей для полной установки, и исправить это можно только с помощью полного обнуления. И однажды ему даже удалось испортить всю установку ОС, когда я обновлял с VS2k8 до VS2k8SP1 или чего-то еще. Оказывается, 5 ГБ свободного места было недостаточно для 300 МБ патча ...

Так что это действительно широко распространенная проблема. Почти каждое приложение в настоящее время обычно содержит распаковщики, множество установленных «друзей-шпионов», драйверы обычно составляют около 600 МБ для всего, включая принтеры и так далее.

Но почему? Это ошибка разработчика? Такие приложения просто кошмарны для поддержки, в настоящее время они никогда не работают на 100%, и почти все пользователи, которых я знаю, очень негативно относятся ко всему тому, что они получают в качестве обязательной установки драйвера для флэш-накопителя USB / принтера / камеры / звуковой карты / браузера.

Кажется, что NSIS от Nullsoft - единственная чистая система установки, которая не раздута, из того, что я знаю, например, установка Firefox. Чистая, в значительной степени основанная на xcopy установка без каких-либо проблем.

Так почему же люди не используют простые установки и приложения, которые не имеют более 30 уровней взаимодействия? Это потому, что разработчики ленивы? Использование инструментов codegen? Это потому, что корпорации заставляют тяжеловесные приложения любить пользователей? В чем причина, и есть ли надежда, что программное обеспечение вернется к основам когда-нибудь? Какие шаги нужно предпринять, чтобы избежать раздувания при запуске нового приложения с нуля?

Я предполагаю, что есть много функций, которые кто-то посчитал хорошей идеей. Однако, если у многих людей есть отдельные идеи, которые объединяются в одно приложение, то это может стать настолько сложным. Я не стал бы обвинять разработчика в случае крупных корпоративных продуктов, где должны быть менеджеры по продукту, которые несут ответственность за то, что находится в продукте, и за то, как оптимизировать его с разных точек зрения.

Другой стороной этого может быть технический долг, который, скорее всего, в большинстве случаев не справляется должным образом, поскольку не рассматривается как значительная трата времени. Я подозреваю, что новые функции и исправления ошибок имеют больше смысла, чем рефакторинг или другие долговые задачи, которые могут иметь небольшую непосредственную ценность для бизнеса. Как часто команда разработчиков получит пару недель для очистки устаревшего кода, если база кода довольно старая? Мое предположение было бы не часто.

Процитирую Джоэла в Стратегическом письме IV: Раздувание и Миф 80/20 :

[...] есть много веских причин для взлома. С одной стороны, если программистам не нужно беспокоиться о том, насколько велик их код, они могут отправить его раньше. [...] Если ваш поставщик программного обеспечения останавливается перед отправкой и тратит два месяца на сжатие кода, чтобы сделать его на 50% меньше, чистая выгода будет для вас незаметной. [...] Но потеря для вас ожидания дополнительных двух месяцев для новой версии ощутима, а потеря для компании-разработчика программного обеспечения, которая должна отказаться от двухмесячных продаж, еще хуже.

Многие разработчики программного обеспечения соблазняются старым правилом «80/20». Это , кажется , сделать много смысла: 80% людей используют 20% возможностей. Таким образом, вы убеждаетесь, что вам нужно реализовать только 20% функций, и вы все равно можете продать 80% копий.

К сожалению, это никогда не то же самое 20%. Все используют разные наборы функций. [...]

Когда вы начинаете продвигать свой «облегченный» продукт и говорите людям: «Эй, это лайт, всего 1 МБ», они, как правило, очень счастливы, а затем спрашивают, есть ли у них их важнейшая особенность, и нет, так что они не покупают ваш продукт.

В значительной степени это связано с зависимостями продукта. Ваша операционная система поставляется с множеством стандартных библиотек для всех видов вещей. Однако эти стандартные библиотеки имеют разные версии на протяжении всей эволюции ОС, и любой универсальный установщик не может предположить, что конкретная версия, на которой он был построен, действительно будет присутствовать в ОС.

Поэтому полный установщик должен будет включать правильную версию каждой зависимости, чтобы убедиться, что после установки все будет работать, независимо от исходного состояния каждой зависимости на целевом компьютере. Это может быть довольно серьезным явлением для определенных типов приложений, например приложений на основе .NET, которые необходимо развернуть в системах Windows XP.

До недавнего времени одной установочной системе, с которой я работал, требовалось устанавливать каждую предыдущую версию .NET, чтобы иметь возможность развертывать последнюю версию, поэтому для любого приложения .NET 3.5 требовались установочные двоичные файлы для .NET 1, 2, 2.5 и 3. В ТОПе 3.5. В этом случае только установщик раздут.

Одним из обходных путей является веб-установщик, который загружает только те компоненты, которые на самом деле отсутствуют в целевой системе - и это может быть огромным преимуществом. Конечно, это ограничивает ваши установки системами, которые имеют подключение к Интернету.

Я думаю, что многое из этого связано со слоем за слоем библиотечного кода. Очевидно, что когда вы используете библиотеку, вы не используете в ней все, так что избыток складывается, когда вы включаете все больше и больше библиотек.

В сочетании с тем фактом, что стоимость часа работы программиста становится все дороже, в то время как вычислительная мощность / память типичного компьютера с каждым годом дешевеют, вы видите, что на самом деле это более рентабельно.

• «Нам нужно что-то сделать X. Давайте использовать библиотеку $ BIGFATLIBDESIGNEDFORSOMETHINGELSE, потому что я использовал ее в другом проекте»
• «Я думаю, что нам больше не нужна эта часть кода, но чтобы убедиться, что ничего не сломалось, просто держите ее»
• Нет или недостаточно модульных тестов, которые приводят к
• Нет рефакторинга
• Нет отслеживания, где настройки были сохранены на протяжении многих лет, так что теперь настройки везде
• ...

Это порочный круг, в котором можно обвинить всех в циклах отчаяния . Один цикл отчаяния состоит из следующих шагов:

1. Деловые люди просят раздутые черты.
2. Разработчики реализуют раздутые функции, хотя они знают, что не должны.
3. Клиенты платят за раздутые функции, даже если им нужен только продукт, а не глупая функция.
4. Деловые люди считают, что клиенты хотят раздутых функций.
5. Перейдите к первому шагу и повторите.

Как вы это остановите? Нет простого ответа, как это сделать, но ясно, что для того, чтобы остановить цикл, необходимо прервать один из шагов. Таким образом, это может быть сломано только бизнесом, разработчиками или потребителями, совершающими революционные действия.

1. Инженер попытался оптимизировать модуль, но представил несколько проблем клиентов. Затем его менеджер сказал нет. Затем инженер решил не «создавать неприятности», пока неприятности не смутили его.
2. Для сложной системы поставщик уже добавил множество исправлений и исправил тысячи ошибок, чтобы сделать ее стабильной в среде клиента. Он не имеет хорошего качества с точки зрения программного обеспечения, но работает. Никто не хочет переписывать его, чтобы снова исправить то же количество ошибок.
3. по причинам обратной совместимости, даже если функция не пользуется популярностью на рынке, мы должны сохранить ее там.

Его неизменно лень, вот что вызывает вздор. (или грязь, как в основной статье на эту тему, Большой Шар Грязи )

Например, там, где я работаю, у нас есть «устаревшее» приложение C ++, которое, тем не менее, довольно хорошо спроектировано. Клиенты общаются с API, который общается с сервером, который работает с БД. Все разумно сделано. Недавно нам понадобился дополнительный модуль, но вместо того, чтобы правильно его реализовать, разработчик решил реализовать это в .NET, и, что еще хуже, он решил, что доступ к данным через API был слишком сложным (его нет, но ...), он будет устанавливать соединения с БД непосредственно. Итак, вы видите, как происходит такой беспорядок. (и все с согласия ТП, которые ставят «быстро», а не «хорошо»)

Я тоже видел подобные вещи раньше - в старом месте небольшой частью GUI был html, так как некоторые разработчики считали хорошей идеей записывать данные в html и отображать их в GUI. Так что 1 небольшая часть делает что-то другое для остальных.

Короче говоря, лень - это плохо, а последовательность - хорошо (независимо от используемой технологии). Я бы предпочел иметь полностью MFC-приложение, чем приложение, которое является частью MFC и частью Winforms и частью WebGL со многими различными внутренними архитектурами, связывающими все это вместе.