Який хороший приклад ідеї розробки програмного забезпечення або методики, яка мала збій?

Зокрема, які приклади, де ідеї мас де просто неправильні. Чому люди заперлися на ідеї в першу чергу? І чому ідеї були відхилені? А може, ідеї ще живі і здорові, і якщо так, чому?

Наприклад, я можу описати CORBA (та інші подібні технології) як щось, що намагалося вирішити проблему зв'язку між компонентами програмного забезпечення. Багато хто вважав за необхідне визначити договори між різними компонентами. Зрештою, HTTP + JSON вирішив проблему для маси та інші різноманітні механізми RPC, такі як Thrift та Proto-bufs.

В основному, як і у світі поза комп'ютерами, ідеї та технології змагаються за увагу, важелі тощо. Деякі виграють, деякі програють; а дехто може здатися певним переможцем деякий час, а потім зникає в невідомості з появою наступної великої речі. Це може і не мати нічого спільного з тим, що було насправді тим краще. Свідк VHS проти Betamax, або пізніша війна між різними форматами DVD.

CORBA був величезним, незграбним і важким у використанні, але це було найкраще, що люди могли винайти на той час (зауважте, що він був розроблений ще до всесвітньої павутини - а HTTP, Java, XML, ... - стали широко відомими). І це був також класичний приклад дизайну від комітету , де вони набиваються в кожній ідеї, щоб задовольнити кожного, врешті-решт роблячи її марно роздутою (принаймні розглядається сьогоднішніми очима). Не кажучи вже про його ціну, яка з появою FOSS незабаром стала непомітною.

Зрештою, HTTP + JSON вирішив проблему для мас

Принаймні, для того, хто не бачив пари подібних «остаточних рішень», піднімаються і в кінцевому підсумку падають ... Добре пам’ятати, що в той час були подібні настрої щодо CORBA ;-)

Я вважаю, що цілком припустимо цитувати з "Піднесення та падіння CORBA" :

Історія CORBA така, яку обчислювальна індустрія бачилася багато разів, і, мабуть, ймовірно, що поточні зусилля середнього програмного забезпечення, зокрема веб-сервісів, відновлять подібну історію. [...]

Загалом, процес впровадження технологій OMG повинен розглядатися як основна причина падіння CORBA. Процес заохочує розробку комітетом і політичним маневруванням до того рівня, коли важко досягти технічної посередності, не кажучи вже про технічну досконалість. Більше того, додавання розрізнених рис призводить до поступового стирання архітектурного бачення. [...]

Демократичний процес, такий як OMG, однозначно не підходить для створення хорошого програмного забезпечення. Незважаючи на відомі процедурні проблеми, проте галузь вважає за краще покладатися на великі консорціуми для виробництва технологій. Веб-сервіси, поточна срібна куля проміжного програмного забезпечення, використовує процес, подібний до OMG, і, за багатьма рахунками, також страждає від міжусобиць, роздробленості, відсутності архітектурної узгодженості, проектування комітетом та особливостей. Мабуть, неминуче, що веб-сервіси прийматимуть історію, подібну до історії CORBA.

Тепер під іншим кутом зору: читаючи ваш термін "ідеї мас", я думав про зовсім інші речі, ніж CORBA або інші стандарти; це, як правило, ідеї однієї людини або малої групи. Я думав про сумнозвісні практики / точки зору, такі як "ковбойське кодування", "код і молиться", "це працює на моїй машині" і т. Д. Це справжні "ідеї мас" ІМХО, оскільки це майже будь-який новачок розробник інстинктивно починає писати код. І вони помиляються, оскільки не масштабують ані в просторі, ані в часі - таким чином не можна створювати великих, підтримуваних, розширюваних програм. Але я відчуваю, що, на жаль, це все-таки норма, а не виняток для людей, які намагаються працювати таким чином у професійних магазинах по всьому світу.

Іншою крайністю цього є багато ідей керівників та теоретиків про "правильний підхід" до розвитку ПЗ, що проявляється в таких методологіях, як М-М, РУП, Водоспад і т.д. правильний процес, і він почне автоматично виробляти якісне програмне забезпечення детерміновано, незалежно від того, хто насправді розробники. Зауважте, що в цю ж гру можна грати і методами Agile - це лише зміна міток. Будь-який менеджер, який вважає, що вибір (та збереження) правильних членів для його / її команди з розробки є менш важливим, ніж процес розробки, невдалий, залежно від того, який процес відбудеться. Однак ця віра в Process все ще здається переважаючою - можливо, його все ще викладають у школах управління?

Частий приклад того, що люди пішли не так - модель водоспаду. Це схема стереотипної моделі водоспаду, яка також з’являється у статті Вінстона Ройса «Управління розвитком великих програмних систем» .

Після цього зображення додається цей текст:

Я вірю в цю концепцію, але реалізація, описана вище, є ризикованою і запрошує провал ... Фаза тестування, яка настає в кінці циклу розробки, є першою подією, для якої час, зберігання, введення / виведення, передачі тощо, - це досвід, який відрізняється від проаналізованого. Ці явища точно не піддаються аналізу. Наприклад, вони не є рішеннями стандартних часткових диференціальних рівнянь математичної фізики. Але якщо ці явища не зможуть задовольнити різні зовнішні обмеження, тоді потрібен незмінний капітальний дизайн. Простий восьмеричний пластир чи повтор якогось ізольованого коду не виправить подібних труднощів. Необхідні зміни в дизайні, ймовірно, будуть настільки руйнівними, що вимоги до програмного забезпечення, на яких ґрунтується дизайн, і які забезпечують обґрунтування всього, порушуються. Або вимоги повинні бути змінені, або необхідні суттєві зміни в дизайні. Насправді процес розробки повернувся до початку, і можна очікувати до 100-відсоткового перевиконання графіку та / або витрат.

Пізніше у статті Ройс представляє альтернативні моделі технологічних процесів, які передбачають ітерацію між поточною фазою та попередньою фазою та циклом між вимогами-аналізом-дизайном та іншим циклом між тестом-кодом-тестом. Він також визначає низку документів та протягом яких етапів вони повинні бути завершені, а також виступає за залучення замовника та численні водоспади в рамках кожної фази, щоб включити аналіз, тестування та використання всіх артефактів, що займаються. Насправді, те, що обговорює Ройс, можна вважати раннім підходом до спритних методів - хоча це все ще дуже орієнтоване на плани, але є основою для спритного руху.

Чому люди причаїлися до першого водоспаду, я не знаю. Я думаю, їм подобається ризикувати і запрошувати невдачі.

Автоматичне генерування коду з більш високого рівня абстракції або автоматичне програмування .

У статті Вікіпедії дещо бракує історичної інформації, але це мрія менеджерів з тих пір, як програмісти стали дорожчими за комп’ютери.

Після розробки мов вищого рівня, таких як Fortran та Cobol, прийшла розробка мов для спеціальних областей, таких як написання звітів. Easytrieve та SAS - це кілька прикладів.

Протягом 1980-х рр. Лють інструменти CASE . CASE розшифровується для комп'ютерної інженерії програмного забезпечення. Вважалося, що суворе застосування інженерних принципів прискорить розробку програмного забезпечення. Головною причиною цих інструментів, окрім витрат, був високий рівень стандартизації даних, необхідний для ефективної роботи інструментів.

Інтернет став відомим у 90-х роках. Типи програмування, які сприяв Інтернет, вибухнули. Програмісти повинні були обробляти ілюстрації, карти, фотографії та інші зображення, а також просту анімацію зі швидкістю, яку ніколи не бачили, за допомогою мало відомих методів. Кількість технологій виробництва цих об'єктів множилася. Мрії про автоматичне програмування згасали.

Аутсорсинг програмування на дешевіші місця - один з небагатьох методів, що залишилися для зниження витрат програміста. Проблеми з аутсорсингом включають проблеми зв'язку та специфікації.

Формальні методи

Колись було запропоновано, щоб програмне забезпечення могло бути доведено правильним. (Ідея полягає в тому, що тестування не може показати, що помилок немає, але докази зможуть.) На жаль, розробка доказу для програми має деякі основні недоліки:

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

Ця концепція була дуже популярною в 70-х роках.

Зв'язок: http://en.wikipedia.org/wiki/Formal_methods http://c2.com/cgi/wiki?ProofOfCorrectness http://c2.com/cgi/wiki?PractitionersRejectFormalMethods