Что является хорошим примером идеи или техники разработки программного обеспечения, которая была неудачной?

9

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

Например, я мог бы описать CORBA (и другие подобные технологии) как нечто, пытавшееся решить проблему связи между компонентами программного обеспечения. Многие считали необходимым определить контракты между различными компонентами. В конечном счете, HTTP + JSON решил проблему для масс и других различных механизмов RPC, таких как Thrift и Proto-bufs.

Evan
источник
1
посмотрите на EXXXXXXXXXXXXXXXXXTREEEEEEEEEEEEEMEE Программирование ...
авария
Нет «идей масс», просто идеи, которые становятся популярными, и я не думаю, что идея о том, как сделать что-то, что используется достаточно долго, чтобы стать массовой популярностью, может быть «просто неправильной», так как это очевидно должен решить некоторые проблемы, иначе он немедленно откажется от всех, кто его попробует.
Майкл Боргвардт
2
CORBA не провал .. это все еще в использовании
Энона
@ oenone, это провал в том смысле, что он не выполнил свое первоначальное обещание решения проблем совместимости в целом, и теперь это нишевая технология.
Петер Тёрёк
HTTP JSON решил проблемы с WebServices, но не с другой областью программного обеспечения!
сарат

Ответы:

11

По сути, так же, как в мире за пределами компьютеров, идеи и технологии конкурируют за внимание, рычаги влияния и т. Д. Некоторые выигрывают, некоторые проигрывают; и некоторые могут казаться Победителем в течение некоторого времени, а затем исчезают в безвестности с появлением Следующего Большого. Это может иметь или не иметь ничего общего с тем, что было на самом деле лучше. Свидетель VHS против Betamax или недавней войны между различными форматами DVD.

CORBA была огромной, неудобной и сложной в использовании, но это было лучшее, что некоторые люди могли изобрести в то время (обратите внимание, что она была разработана до того, как World Wide Web - и HTTP, Java, XML, ... - стали широко известны). И это был также классический пример дизайна комитетом , где они втиснули каждую идею, чтобы удовлетворить всех, в конце концов делая ее бесполезно раздутой (по крайней мере, увиденной сегодняшними глазами). Не говоря уже о его цене, которая с появлением FOSS вскоре стала запретительной.

В конечном итоге HTTP + JSON решил проблему для масс

По крайней мере, для тех, кто не видел, чтобы пара подобных «окончательных решений» росла и в конечном итоге падала… Хорошо иметь в виду, что в то время было схожее мнение о CORBA ;-)

Я чувствую, что уместно привести цитату из книги «Взлет и падение CORBA» :

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

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

Такой демократический процесс, как OMG, совершенно не подходит для создания хорошего программного обеспечения. Однако, несмотря на известные процедурные проблемы, отрасль предпочитает полагаться на крупные консорциумы для производства технологий. Веб-сервисы, нынешняя серебряная пуля промежуточного программного обеспечения, используют процесс, очень похожий на OMG, и, по многим отзывам, также страдают от распрей, фрагментации, отсутствия архитектурной согласованности, дизайна комитетом и раздувания функций. Кажется неизбежным, что Web-сервисы будут вести историю, очень похожую на историю CORBA.


Теперь под другим углом: прочитав ваш термин «идеи масс», я подумал о совершенно разных вещах, чем CORBA или другие стандарты; Обычно это идея одного человека или небольшой группы. Я думал о пресловутых практиках / точках зрения, таких как «ковбойское кодирование», «кодируй и молись», «это работает на моей машине» и т. Д. Это ИМХО настоящие «идеи масс», так как это способ практически любого новичка. Разработчик инстинктивно начинает писать код. И они не правы, поскольку они не масштабируются ни в пространстве, ни во времени - таким способом нельзя создавать большие, поддерживаемые, расширяемые программы. Тем не менее, я чувствую, что, к сожалению, это все же норма, а не исключение, чтобы люди пытались работать таким образом в профессиональных магазинах по всему миру.

Другая крайность этого - идеи многих менеджеров и теоретиков о «правильном подходе» к разработке ЕО, проявляющиеся в методологиях большого М, таких как CMM, RUP, Waterfall и т. Д. Идея, лежащая в основе всего этого, заключается в том, что все, что вам нужно, это Правильный процесс, и он начнет автоматически производить качественное программное обеспечение детерминистическим способом, независимо от того, кто на самом деле разработчики. Обратите внимание, что в ту же игру можно играть и с помощью Agile-методов - это просто смена меток. Любой менеджер, который считает, что выбор (и сохранение) правильных членов для его / ее команды разработчиков менее важен, чем процесс разработки, неизбежно провалится, в зависимости от того, какой процесс произойдет. Тем не менее, эта вера в процесс все еще кажется распространенной - может быть, она все еще преподается в школах управления?

Петер Тёрёк
источник
Прочитав эту ссылку: дорогой бог, CORBA, должно быть, было ужасно, если EJB V1 вытеснили его, потому что они были проще ...
Майкл Боргвардт,
Продукт, который Михи Хеннинг продолжил разрабатывать, исправляет многие недостатки CORBA.
Blrfl
13

Частым примером того, как люди ошибаются, является модель водопада. Это схема стереотипной модели водопада, которая также появляется в статье Уинстона Ройса «Управление разработкой больших программных систем» .

Модель водопада Уинстона Ройса

Это изображение сопровождается этим текстом:

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

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

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

Томас Оуэнс
источник
6
Люди ухватились за первый метод «Водопад», потому что это было бы поразительно похоже на проект гражданского строительства, такой как строительство 40-этажного небоскреба. При строительстве небоскреба требования и ограничения слишком болезненны, чтобы их можно было пропустить, и на полпути ничего не изменится. Анализ и проектирование (архитектура) должны быть полными и тщательными, не оставляющими места для интерпретации. Здание должно быть построено в соответствии со спецификацией, и, наконец, инспекторы должны прийти и квалифицировать готовую продукцию. Программное обеспечение почти никогда не бывает таким ясным, поэтому модель Waterfall - неудача.
maple_shaft
2
@maple_shaft Я нахожу это интересным, так как Уинстон Ройс был первым, кто обсудил использование этой модели в программном проекте и создал диаграмму, которая всем знакома сегодня, однако люди не продолжали читать, чтобы понять, почему он сказал, что это не должно использоваться в программном проекте. Если человек, который первым пишет эту идею, говорит, что она плохая, и заявляет не только почему, но и как это сделать правильно, почему люди все равно решили бы зацепиться за нее? Интересно, имеет ли это отношение к первым разработчикам программного обеспечения из математики и электротехники? В EE этот подход работает?
Томас Оуэнс
1
Модель водопада не совсем неправильна: она правильно определяет основные этапы разработки программного проекта и логически упорядочивает их. Что он не может признать, так это тот факт, что программный проект может быть написан итеративно и модульно, и, как таковые, этапы, описываемые моделью водопада, могут выполняться в различных конфигурациях для отдельных итераций и / или компонентов всей системы.
tdammers
3
@ Томас Оуэнс: «Если человек, который впервые пишет эту идею, говорит, что она плохая, и говорит не только почему, но и как это сделать правильно, почему люди все равно решили зацепиться за нее?» Адам Смит, отец современного капитализма, написал свой манифест о свободном и чистом рынке, но затем в своей книге он продолжает говорить о том, насколько опасной может быть концепция корпораций и как они подрывают правительства, чтобы влиять на рынки в свою пользу. Обычно люди игнорируют те части концепции, которые они либо не понимают, либо идут вразрез с их предвзятыми представлениями о том, что правильно.
maple_shaft
2
«Почему люди ухватились за самый первый водопад, я не знаю. Думаю, им нравится рисковать и провоцировать неудачи». ИМХО, это с точностью до наоборот. Людям в целом нравится чувствовать, что они контролируют ситуацию, и диаграммы процессов и сложные методологии дают им это чувство безопасности. Поскольку эти процессы и диаграммы помогли им раньше во многих других областях, они предполагают (в данном случае ошибочно), что это будет работать также и в разработке ПО ...
Péter Török
4

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

В статье в Википедии не хватает исторической информации, но это мечта менеджеров с тех пор, как программисты стали дороже компьютеров.

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

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

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

Аутсорсинг программирования в более дешевые места - это один из немногих оставшихся способов снижения затрат программистов. Проблемы с аутсорсингом включают проблемы коммуникации и проблемы спецификации.

Гилберт Ле Блан
источник
1
Кроме того, SQL и Visual Basic, оба из которых были объявлены, чтобы позволить непрограммистам писать программы.
Шон Макмиллан
2

Формальные Методы

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

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

Эта концепция была очень популярна в 70-х годах.

Связь: http://en.wikipedia.org/wiki/Formal_methods http://c2.com/cgi/wiki?ProofOfCorrectness http://c2.com/cgi/wiki?PractitionersRejectFormalMethods

Шон Макмиллан
источник
3
В формальных методах есть нечто большее, чем просто доказательства. Он варьируется от сильно математических и доказательств использования теорем, которые вы упоминаете, до более легких методов, которые включают моделирование с использованием UML и OCL и создание формальной спецификации в Z. Да, введение любого уровня формальных методов увеличивает время и стоимость, но если вы создаете Программное обеспечение, которое может убивать или ранить людей (от кардиостимулятора до самолета или ракеты), затрачивая дополнительное время и усилия на максимально возможную проверку и проверку, может означать разницу между жизнью и смертью.
Томас Оуэнс
@ Томас: хороший момент. И формальные методы имеют некоторое применение в проектах, где смерть на грани. Но они, конечно, не были серебряной пулей для программного обеспечения без ошибок.
Шон Макмиллан
Абсолютно. Они занимают свое место в программном обеспечении миссии и жизнеобеспечении, в различной степени в зависимости от системы. Ведь серебряных пуль нет.
Томас Оуэнс