Комментарии 11
Это вы хорошо отметили, про только внешнюю схожесть строительства и разработки ПО. Сам с недавних пор работаю в проектной организации и в силу её специфики пришлось очень сильно вникнуть в процесс проектирования промышленных объектов.
В строительстве прогресс идет более медленными темпами. В этой отрасли есть время собрать камни. При разработке ПО инструменты, технологии, окружение и прочее меняются очень стремительно. То что использовалось 10 лет назад, уже с трудом может быть использовано сегодня в новой разработке. В строительстве и 40 лет не помеха.
В строительстве прогресс идет более медленными темпами. В этой отрасли есть время собрать камни. При разработке ПО инструменты, технологии, окружение и прочее меняются очень стремительно. То что использовалось 10 лет назад, уже с трудом может быть использовано сегодня в новой разработке. В строительстве и 40 лет не помеха.
Добавлю из личного опыта. На конференциях и прочих мероприятиях, где общаются архитекторы ПО, модно сравнивать разработку ПО со строительством зданий. Так что я за годы выработал набор контраргументов, дабы было о чем пиво пить.
Как я это вижу (далее идет мое личное мнение). Между разработкой ПО и строительством здания, на мой взгляд, есть одно фундаментальное отличие — это цена копирования. Здание мы строим ровно один раз. После того, как мы его построили, если мы хотим еще одно точно такое же здание — мы должны построить его еще раз. А у программного обеспечения нулевая цена копирования — если мы создали программу для анализа кракозябр — то нам нет никакой необходимости еще раз создавтаь программу для подсчета кракозябр — она уже есть. И конкурентам в общем случае не нужно создавать точно такую же программу для подсчета кракозябр. Если они хотят выйти на тот же рынок — им надо сделать что-то лучшее.
Что получается в результате — при строительстве зданий опыт и удачные архитектурные решенения накапливаются, так как мы постоянно строим одно и то же. В разработке софта опыт и удачные решения накапливаются граздо хуже, потому что каждая новая программа не похожа не предыдущие.
Вот такая вот беда. Как сказал на одной из конференций умудренны опытом докладчик — «справочник по архитектуре ПО — это кулинарная книга с рецептами, ингридиенты для которых были в единственном количестве».
Как я это вижу (далее идет мое личное мнение). Между разработкой ПО и строительством здания, на мой взгляд, есть одно фундаментальное отличие — это цена копирования. Здание мы строим ровно один раз. После того, как мы его построили, если мы хотим еще одно точно такое же здание — мы должны построить его еще раз. А у программного обеспечения нулевая цена копирования — если мы создали программу для анализа кракозябр — то нам нет никакой необходимости еще раз создавтаь программу для подсчета кракозябр — она уже есть. И конкурентам в общем случае не нужно создавать точно такую же программу для подсчета кракозябр. Если они хотят выйти на тот же рынок — им надо сделать что-то лучшее.
Что получается в результате — при строительстве зданий опыт и удачные архитектурные решенения накапливаются, так как мы постоянно строим одно и то же. В разработке софта опыт и удачные решения накапливаются граздо хуже, потому что каждая новая программа не похожа не предыдущие.
Вот такая вот беда. Как сказал на одной из конференций умудренны опытом докладчик — «справочник по архитектуре ПО — это кулинарная книга с рецептами, ингридиенты для которых были в единственном количестве».
Ну, не совсем верно.
Набор инструментов в разработке ПО более-менее стабилен в течение пары лет.
Да, новые технологии появляются, старые улучшаются, но не обязательно же все сразу внедрять.
У нас есть заготовки частей каркаса (framework'и), у которых заданы правила, по которым их можно соединять друг с другом. А вот какие части выбрать и как их соединять, какую делать начинку — это всегда разное, увы.
И еще: программный продукт лучше соотносить не с законченным зданием, а с заселенным.
В каждой квартире свой ремонт, кое-где ремонта уже 10 лет не было, и нет денег и времени, чтобы его сделать, и т.д. В подъезде обваливается штукатурка, стены оказываются изрисованными, косметический ремонт спасает ненадолго, и т.д.
Но это не мешает в этом доме жить, хотя многое и не нравится.
IMHO, этот процесс уже довольно точно соответствует реальной жизни проекта.
И цена координальных изменений в ПО примерно соответствует цене перестройки части здания (а давайте на крыше бассейн сделаем?)
Набор инструментов в разработке ПО более-менее стабилен в течение пары лет.
Да, новые технологии появляются, старые улучшаются, но не обязательно же все сразу внедрять.
У нас есть заготовки частей каркаса (framework'и), у которых заданы правила, по которым их можно соединять друг с другом. А вот какие части выбрать и как их соединять, какую делать начинку — это всегда разное, увы.
И еще: программный продукт лучше соотносить не с законченным зданием, а с заселенным.
В каждой квартире свой ремонт, кое-где ремонта уже 10 лет не было, и нет денег и времени, чтобы его сделать, и т.д. В подъезде обваливается штукатурка, стены оказываются изрисованными, косметический ремонт спасает ненадолго, и т.д.
Но это не мешает в этом доме жить, хотя многое и не нравится.
IMHO, этот процесс уже довольно точно соответствует реальной жизни проекта.
И цена координальных изменений в ПО примерно соответствует цене перестройки части здания (а давайте на крыше бассейн сделаем?)
>В разработке софта опыт и удачные решения накапливаются граздо хуже, потому что каждая новая программа не похожа не предыдущие.
Отличное наблюдение, просто все однотипное быстро автоматизируется и проблемы переходят на уровень выше.
Например в абстрактном проекте сначала развертывание производилось ручками. По мере накопления опыта и роста количества серверов стало рентабельным сделать автоматическую систему развертывания, ее сделали и вместо локальных проблем деплоя на конкретном сервере встали проблемы работы этой системы.
Отличное наблюдение, просто все однотипное быстро автоматизируется и проблемы переходят на уровень выше.
Например в абстрактном проекте сначала развертывание производилось ручками. По мере накопления опыта и роста количества серверов стало рентабельным сделать автоматическую систему развертывания, ее сделали и вместо локальных проблем деплоя на конкретном сервере встали проблемы работы этой системы.
Мне понравилась аналогия из «Программист-прагматик», там авторы сравнивают ПО и процесс его разработки с садом и работой садовника. Вообще, к программным продуктам хорошо применимы аналогии из живой природы, так как большинство систем, стремящихся к гомеостазу, мы видим вокруг себя.
Есть ещё хорошая аналогия с горным походом альпинистов, она у Мараско, например, отлично описана.
Ага, жаль только что достаточно распространено мнение, что по мере увеличения масштаба все что касается архитектуры и непосредственно конструирования начинает волшебным образом вести себя как-то по другому. На самом деле это тот же сад и тот же поход, просто, если пользоваться аналогией, людей идет больше и гора выше.
да, отличная статья, жаль ссылка потерялась
Отличная статья, жаль, что слишком «мягкая». У разработки ПО вообще слишком много неверных (радикально неверных, причём) прицепилось. Тут и строительство, и автомобилестроение, а из общего там только термины, за которыми в каждом случае стоят совершенно разные вещи.
Мне когда-то попалась статья, где автор сравнил разработку ПО не со строительством, а с работой архитектора (классического, не софтварного), причём даже не одного, а целого коллектива, который должен построить дом по техзаданию вида «Лучший дом в мире! Пять тысяч этажей. И чтобы можно было на колёсиках катать по обычным дорогам».
Мне когда-то попалась статья, где автор сравнил разработку ПО не со строительством, а с работой архитектора (классического, не софтварного), причём даже не одного, а целого коллектива, который должен построить дом по техзаданию вида «Лучший дом в мире! Пять тысяч этажей. И чтобы можно было на колёсиках катать по обычным дорогам».
Извините, а о чем статья?
Я перечитал ее 2 раза и не понял ни мысли, ни цели, ни логики. Единственный point — «разработка по, это как строить дома, только по другом». Не могли бы вы помочь мне, закончив статью «выводом»? Спасибо.
Я перечитал ее 2 раза и не понял ни мысли, ни цели, ни логики. Единственный point — «разработка по, это как строить дома, только по другом». Не могли бы вы помочь мне, закончив статью «выводом»? Спасибо.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Разработка ПО: 2. Наследство