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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Возможность мгновенно найти ответ практически на все проблемы, с которыми вы можете столкнуться как разработчик, позволяет значительно повысить производительность. Не знаете, как выбрать 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 и т. Д.), Лучшее оборудование (нет, я не буду очень продуктивным, если придется писать в Ассемблере для медленного процессора и очень ограниченного объема ОЗУ) и т. Д.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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