Неужели за последние 20 лет не было чего-то такого, что обеспечило бы огромный выигрыш в разработке программного обеспечения? [закрыто]

45

В книге «Нет серебряной пули» Фред Брукс делает различные прогнозы о будущем программной инженерии, которые лучше всего суммируются:

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

Его аргумент очень убедителен. Брукс писал в 1986 году: был ли он прав? Производят ли разработчики в 2014 году программное обеспечение в 10 раз быстрее, чем их коллеги в 1986 году? Какой-то подходящей метрикой - насколько велик прирост производительности?

Патрик Коллинз
источник
4
Комментарии не для расширенного обсуждения; этот разговор был перенесен в чат .
Мировой инженер,

Ответы:

58

Производят ли разработчики в 2014 году программное обеспечение в 10 раз быстрее, чем их коллеги в 1986 году?

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

Увеличение производительности произошло благодаря сочетанию факторов. Примечание: это не полный список:

  1. Лучшие компиляторы
  2. Порядочно более мощные компьютеры
  3. Intellisense
  4. Ориентация объекта
  5. Функциональная ориентация
  6. Лучшие методы управления памятью
  7. Проверка границ
  8. Статический анализ кода
  9. Строгая типизация
  10. Модульное тестирование
  11. Лучший дизайн языка программирования
  12. Генерация кода
  13. Системы контроля исходного кода
  14. Повторное использование кода

И так далее. Все эти методы объединяются для повышения производительности; нет ни одной серебряной пули, которая когда-либо вызывала бы ускорение на порядок.

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

Роберт Харви
источник
15
Не забудьте лучшие системы контроля версий и версий.
Довал
7
Ах, верно. Я полагаю, что мы могли бы добавить еще дюжину (или сотню) вещей в этот список.
Роберт Харви
44
@ user61852: Потому что ожидания всегда превосходят реальность.
Роберт Харви
9
@ user61852 thecodelesscode.com/case/154
Идан Арье,
1
@RossPatterson: На данный момент мы получили то, что нам нужно для инструментов разработчика. В наши дни мы даже делаем глупо бесполезные вещи с нашими циклами компиляции процессора только потому, что можем - взглянуть на метапрограммирование шаблонов. Помните, мы сравниваем с 80-ми; хотя я тогда, конечно, не был разработчиком, я научился кодировать на машине, созданной в 1990 году.
tmyklebu
71

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

Когда я начинал свою карьеру, не было STL, .NET, QT и т. Д. У вас был сырой C или C ++, и это все.

Вещи, которые раньше занимали дни или недели или работа (синтаксический анализ XML, соединения TCP / IP, HTTP-коммуникация), теперь могут быть выполнены с помощью нескольких строк кода C #. Вот где мы получили на порядок лучше с точки зрения общей производительности разработчиков.

В нашем текущем продукте используется структура окна стыковки, которую мы приобрели у поставщика. Это позволило мне получить полностью функциональный интерфейс окна стыковки за считанные минуты. Мне страшно подумать, что нужно сделать, чтобы сделать это в дни использования Win32 API.

17 из 26
источник
19
Я бы добавил к этому наличие документации и помощи. Двадцать лет назад у вас был список рассылки и ваши ближайшие коллеги. Теперь мировой опыт в программировании почти во всех темах доступен мгновенно через единый интерфейс.
NWard
15
@NWard, поэтому в основном переполнение стека =)
Крис
2
@tmyklebu people just found other (generally better) solutions[цитата нужна]. Использование библиотек для быстрого анализа «гор» XML во многих отношениях лучше, чем ручное кодирование уникальных решений. XML, конечно, может быть слишком кратким и повторяющимся, но в большинстве случаев библиотеки позволяют использовать его на одном дыхании.
WernerCD
5
@tmyklebu Как ни больно анализировать большие объемы XML, попробуйте проанализировать большие объемы двоичных данных в недокументированном проприетарном формате, как это было бы сделано большинством приложений, написанных примерно в 1986 году.
James_pic
2
@ tmyklebu Никто не нуждался в гигабайтах чего-либо в прошлом (или даже мегабайтах!). Что генерирует такое количество XML, так это то, что мы храним и отслеживаем больше данных, чем когда-либо. james_pic - это правильно, XML намного лучше, чем использование bazillion проприетарных двоичных форматов. XML может быть многословным, но он кроссплатформенный, удобочитаемый и очень гибкий. Это все ценные черты.
17 из 26
62

Ради аргумента я не согласен с утверждением Фреда Брукса .

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

Возможность мгновенно найти ответ практически на все проблемы, с которыми вы можете столкнуться как разработчик, позволяет значительно повысить производительность. Не знаете, как выбрать n-й элемент в JQuery? Поиск в Google приводит к ответу на точный вопрос о переполнении стека . Не знаете, как использовать overflowв CSS? MDN Мозиллы здесь . Забыли, что virtualозначает ключевое слово в C #? Гугл помогает , опять же.

Когда я начал программировать, у меня не было интернета. У меня были книги, а также некоторая документация в цифровом формате, хранящаяся локально, но поиск по книгам и документации был медленным процессом, и независимо от того, сколько у меня было книг, было много проблем, которые там не упоминались.

Что еще более важно, почти все проблемы, с которыми вы сталкиваетесь, уже встречались ранее. Интернет помогает найти людей, которые имели эту ошибку и успешно ее исправили. Это не та информация, которую вы найдете в книгах или официальной документации, такой как MSDN. Вместо этого обычно можно найти такую ​​информацию:

  • На переполнение стека, очевидно. Например, я не видел ни одной книги, в которой упоминалась бы эта проблема .

  • В блогах. Я нашел много помощи в блогах, когда у меня были особые проблемы, будь то конфигурация WCF или прокси-сервер, который не запускается, или загадочная ошибка при использовании определенного API на машине с культурой, отличной от en-US.

  • В сообщениях об ошибках, касающихся программного обеспечения с открытым исходным кодом. Например, это было очень полезно в последнее время, когда я пытался использовать MAAS Ubuntu и когда я использовал PXE. Вы также не найдете такого рода информацию в книгах.

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

  • Интернет не сильно помогает на этапах архитектуры и проектирования (может помочь Programmers.SE, но для архитектора будет гораздо ценнее читать книги об архитектуре и дизайне, изучать шаблоны проектирования и т. Д.).

  • Он начинает помогать на этапах тестирования и реализации, когда возникают реальные проблемы.

  • Но большинство проблем, возникающих во время технического обслуживания, возникает, когда помощь от других через Интернет кажется решающей . Базовый пример: служба WCF прекрасно работает на моей машине , но без каких-либо исключений дает сбой при развертывании в производстве, хотя она работала последние две недели. Это случилось со мной, и я благодарен авторам блогов и сообществу Stack Overflow за помощь в решении проблемы в течение нескольких часов, а не недель.

Оправдывает ли это увеличение производительности в 10 раз? Сложно сказать.

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

  • С другой стороны, общая производительность улучшилась благодаря нескольким факторам, таким как лучшее управление проектами (на ум приходят Agile, TDD и т. Д.), Лучшее управление командой ( на ум приходит Radical Management Стивена Деннинга), лучшие инструменты (отладчики, профилировщики , IDE и т. Д.), Лучшее оборудование (нет, я не буду очень продуктивным, если придется писать в Ассемблере для медленного процессора и очень ограниченного объема ОЗУ) и т. Д.

Арсений Мурзенко
источник
4
«Интернет» - это тоже не единственная разработка.
Бен Фойгт
1
@BenVoigt: я бы назвал это технологией из цитаты Брукса. Но я согласен, термины могут быть неочевидными: во-первых, будет ли это Интернет (начало 1980-х) или Всемирная паутина (1989)? Во-вторых, важна была не только сама технология, но и ее популярность.
Арсений Мурзенко
Но вещи, которые мы складываем под понятием «Интернет», включают в себя множество различных технологий. Существует несколько поколений Всемирной паутины (DHTML / Javascript / browser). Есть волоконно-оптические достижения, которые делают возможными соединения в масштабе центра обработки данных. Есть усовершенствования процесса CMOS, которые позволяют серверам иметь терабайт оперативной памяти и выполнять анализ данных. Алгоритмы для индексации миллиона вопросов о программировании и обеспечения 10 самых близких совпадений в некотором смысле естественного языка.
Бен Фойгт
5
Людям, работающим с системами, разработанными Бруксом, не нужно, чтобы Google помнил, как писать JCL. Эти системы поставлялись с хорошо документированными средами разработки, которые постоянно использовались / улучшались постепенно в течение десятилетий. Из-за запланированного устаревания или чего-то менее зловещего, мы избежали этого. В любом случае, я не решаюсь назвать то, что у нас сейчас, улучшением, и совершенно не желаю объявлять это «серебряной пулей».
user1172763
Сложность - враг. Вы можете держать JCL в своей голове и держать руководство в своей руке; одна полка может документировать всю систему. В настоящее время произошел огромный взрыв в размере систем и их основной скорости изменения.
pjc50
13

Я бы сказал, что интернет довольно хороший кандидат. StackOverflow и Google являются самыми мощными инструментами современного разработчика. Мгновенный обмен знаниями на глобальной основе! В наши дни вам не нужно знать ответы, вам нужно только знать, как узнать ответы - и это совершенно адекватная среда, которая позволяет разработчикам тратить меньше времени на чтение и больше времени на кодирование, и, следовательно, быть продуктивным. Это означает, что у каждого программиста в мире есть доступ ко всем ответам, и все, что им нужно сделать, это знать, как задавать правильные вопросы.

AlexFoxGill
источник
Вы единственный человек, который указал на серебряную пулю. Это не только сделало программистов более продуктивными по величине, но на самом деле на несколько величин порядка.
Данк
+1000 - вы можете получить помощь через несколько минут, вместо этого работая несколько дней над неясным вопросом.
jqa
7

Я бы предположил, что тенденции, подталкивающие нас в другом направлении (то есть к снижению производительности), по крайней мере, так же сильны, как и те, о которых вы спрашивали. Опыт работы с инструментами разработки клиент / сервер, такими как VB6 или PowerBuilder, довольно близко подошел к идеалу «быстрой разработки приложений» (RAD). Вы должны нарисовать свои формы, и были очевидные зацепки для вашего процедурного или SQL-кода.

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

Переход к веб-разработке, в значительной степени ориентированной на клиента, стал еще одним утомительным опытом; Microsoft возвращалась к идеалу RAD с WebForms, а затем быстро потеряла популярность. Вместо этого разработчики должны были злоупотреблять инфраструктурой (например, XMLHttpRequest, который редко используется для XML) и в противном случае использовать небольшую абстракцию, чтобы сделать свои сайты более интерактивными.

У всех этих переходов есть веские причины, и несправедливо сравнивать процесс, который привел к созданию собственного .EXE (требующего установки и управления на отдельном клиенте), с веб-разработкой, и не совсем справедливо сравнивать процесс, который сильно зависит на обратных передачах с одним, который дает более плавный опыт. Но я скажу, что практики, которые в настоящее время в моде, приводят к некоторым удивительно низкоуровневым мыслительным процессам среди людей, которые пропустили клиент / сервер, RAD и тому подобное. Кнопки клиент / сервер просто работали, и, конечно же, не нужно было беспокоиться о базовых каналах данных, которые передавали данные обработчикам событий, которые сделали это возможным.

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

user1172763
источник
Вы видели Meteor.js?
Страж
2
@strugee Да, и я думаю, что Meteor.js может быть шагом в правильном направлении. Тем не менее, тот факт, что мы, по сути, «начали все сначала» технологически, по крайней мере, 3-4 раза с тех пор, как Брукс написал свою книгу (здесь речь идет о переходе на ПК, затем на клиент / сервер, затем на веб, а затем на AJAX) - это, пожалуй, то, что мешало нам найти «серебряную пулю» или даже добиться линейного улучшения производительности. Время покажет, как долго нынешние методы разработки выдержат (и улучшат). Есть несколько причин для оптимизма ... теперь все стремятся к надежной, кроссплатформенной точке.
user1172763
5

Технологии очень продвинулись, и теперь у нас есть все, что Роберт Харви перечисляет в своем ответе, но:

  • Кажется, проблема заключается в изменении требований . Клиент знает, что при изменении требований к программному проекту не будет растраты материалов, поэтому они это делают. Такого рода изменения требований почти никогда не происходят, когда проект физического мира, такой как здание, наполовину завершен.

  • Другим важным аспектом является то, что программирование продолжает оставаться делом рукоделия . Редко, если когда-либо, RAD-сгенерированный код запускается в производство без предварительной модификации вручную.

  • Код продолжает быть очень сложным , и эта сложность, кажется, не уменьшается с новыми технологиями.

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

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

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

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

  • Один из вариантов зрелости индустрии программного обеспечения состоит в том, что в лицензиях на программное обеспечение по-прежнему говорится: «<companyX> не делает никаких заявлений о пригодности этого программного обеспечения для какой-либо конкретной цели. Оно предоставляется« как есть »без явной или подразумеваемой гарантии». Представьте производителя оборудования, заявляющего, что их продукт не подходит для какой-либо конкретной цели. Это состояние искусства прямо сейчас.

Тулаинс Кордова
источник
2
Конечно, существует более 10 компаний, способных создавать и поддерживать свои собственные ОС, но лишь немногие предпочитают это делать, потому что другие возможности более прибыльны.
Бен Фойгт
@BenVoigt Конечно, создание и поддержка ОС сравнительно менее прибыльны из-за ее сложности, требующей десятилетий исследований и разработок, которые они должны были начать не позднее девяностых, чтобы иметь сегодня зрелый продукт.
Тулаинс Кордова
1
Также «возвратная» сторона RoI не так хороша, потому что рынок уже насыщен.
Бен Фойгт
2
Конечно, все, что вы сделали, - перечислите известные препятствия на пути к эффективному программированию, которые возникли вскоре после того, как леди Лавлейс взяла в руки карандаш. Единственное, что отличается от 30 лет назад, это то, что все стало экспоненциально сложнее.
Даниэль Р Хикс
4

В то время как кто-то может поспорить с конкретными показателями (то есть, улучшились ли вещи в 9,98 раза?), Я (говоря как нечто старое) должен согласиться с общим мнением комментария Брукса.

Во-первых, с 1970 года было изобретено очень мало действительно новой технологии. Да, интегральные схемы стали длиннее, ниже, шире, а стекловолокно улучшило скорость связи, но на каждый шаг вперед есть один отступник.

Технология компиляции позволила примерно в 10 раз повысить «производительность» программиста по сравнению с 1970 годом, когда производимая одна цифра функция делится на фактическое время кодирования, но распространение новых или «пересмотренных» языков программирования и сред означает, что средний программист тратит все больше и больше время в режиме «догоняющего» и меньше в продуктивной деятельности. Apple, Google и Microsoft выпускают новые и практически несовместимые «обновления» в свои среды со скоростью, которая чуть ниже той, которая может вызвать бунт среди их крепостных ... программистов. Точно так же HTML / CSS / Javascript / что-либо становится все более сложным.

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

Добавлено: я размышлял об этом со вчерашнего дня и, в частности, думал о проекте, над которым работал примерно с 1978 по 2008 год. Этот проект (IBM System / 38 и его преемники) был несколько уникальным в этом с самого начала сделано для того, чтобы контролировать его сложность (одна из которых состоит в разделении программного обеспечения на две примерно равные части с «машинным» интерфейсом между ними). В той конкретной области, где я работал, несколько моих коллег также были посвящены контролю за сложностью (хотя мы не использовали этот термин в то время). Результатом стал продукт, который (на первых порах) был довольно надежным и «поразил» покупателей в значительной степени с самого начала. И было приятно работать - как играть в хорошо обученном оркестре.

Конечно, с годами закралась сложность, обычно по распоряжению планировщиков рынка и менеджеров, которые не ценили управление сложностью (что несколько отличается от простого поддержания простоты). У меня нет ощущения, что это было неизбежно, но было невозможно предотвратить в этом случае без менеджера (как первоначально сделал Гленн Генри), отталкивающего силы путаницы.

Даниэль Р Хикс
источник
2
Но мне напоминают о том, что произошло со мной (и, несомненно, со многими другими) 20-30 лет назад - существует своего рода принцип программирования Питера (или, возможно, 2-й закон программирования термодинамики), который гласит, что сложность неизбежно возрастает до точка непонятности. Вещи никогда не становятся проще.
Даниэль Р Хикс
3

Многое из того, что мы узнали в практике разработки программного обеспечения за последние 30 с лишним лет, имеет форму: «Технология X может ускорить первоначальную разработку нового программного обеспечения, но если вы не тратите столько или больше времени на размышления о том, как и когда использовать его так, как вы его сохранили, в конечном итоге оно превратит ваше приложение в огромную техническую задолженность, что потребует на несколько порядков больше времени и усилий на обслуживание ».

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

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

zwol
источник