Які причини, що призводять до запущеного програмного забезпечення? [зачинено]

Сьогодні я вирішив здійснити чисту установку для драйверів Creative Sound Blaster, оскільки вони через деякий час завжди починають виблискувати все самостійно. А це означало, що я повинен пройти всю процедуру очищення. І це зайняло у мене майже 2 години ..

І якщо чесно, я не бачу причини, чому ?! І хоча Creative, IMHO, є абсолютним призером 1-го місця за виробництво програмного забезпечення низької якості, яке ніколи не працює, проблема роздуття не виключна для них.

ПК із драйвером цифрової камери Canon матиме близько 10 записів Canon, які з'єднані між собою всілякими підключеннями. Visual Studio також є прекрасним прикладом: є близько 50 записів для повного встановлення, і виправити цю річ можливо лише за допомогою повного знімання. І колись це навіть вдалося зруйнувати всю установку ОС, коли я оновлювався з VS2k8 до VS2k8SP1 або щось подібне. Як виявляється, 5 Гб вільного місця було недостатньо для патчу 300 Мбіт ...

Тож це справді здається досить поширеною проблемою. Майже кожен додаток на сьогодні зазвичай містить розпаковувачі, встановлені кілька шпигунських "друзів", драйвери зазвичай близько 600 Мбіт для всього, включаючи принтери тощо.

Але чому? Це винна розробник? Такі програми, як кошмар для підтримки, вони ніколи не працюють на 100% в даний час, і майже всі користувачі, яких я знаю, дуже негативно ставляться до всього цього роздуття, яке вони отримують як обов'язковий встановлення драйвера для USB-накопичувача / принтера / камери / звукової карти / браузера.

Здається, що NSIS від Nullsoft є єдиною чистою системою налаштування, яка не роздута, з того, що я знаю, наприклад, встановити Firefox. Чиста, майже на основі xcopy встановити без проблем.

То чому люди не використовують прості налаштування та програми, коріння яких не перевищує 30 шарів взаємозв'язку? Це тому, що розробники лінуються? Використання інструментів кодегена? Це тому, що корпорації змушують важкі додатки як те, що користувачі люблять? У чому причина, і чи є сподівання, що програмне забезпечення колись повернеться до основ? Які кроки, щоб уникнути написання руйнування, коли ви починаєте нову програму з нуля?

Я здогадуюсь, що існує багато особливостей, які хтось вважав гарною ідеєю. Однак, якщо у багатьох людей є окремі ідеї, які збираються в одну програму, це може стати таким складним. Я б не звинувачував розробника у випадку великих корпоративних продуктів, де повинні бути менеджери продуктів, які відповідають за те, що є в продукті, і як оптимізувати його з різних точок зору.

Іншою стороною цього буде технічна заборгованість, яка, швидше за все, не справляється добре в більшості випадків, оскільки це не сприймається як велика інвестиція часу. Я б підозрював, що нові функції та виправлення помилок мають більше сенсу, ніж рефакторинг чи інші боргові завдання, які, можливо, мають невелику безпосередню цінність для бізнесу. Як часто команди розробників отримують пару тижнів, щоб очистити застарілий код, якщо база коду досить стара? Моя здогадка була б не часто.

Процитуйте Джоеля в стратегічному листі 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 занадто складно (це не тільки ...) він зробить з'єднання з БД безпосередньо. Отже, ви бачите, як відбувається такий вид безладу. (і все за згодою Технічної служби, яка поставила "швидке" над "хорошим")

Я вже бачив подібні речі і раніше - в старому місці невелика частина графічного інтерфейсу була html, тому що дев вважав, що це гарна ідея записувати дані в html та мати графічний інтерфейс. Отже 1 невелика частина робить щось інше для решти.

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