Чему могут научиться программисты из строительной отрасли? [закрыто]

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

Один из лучших способов учиться (или учить) - это анализ аналогий - какие другие аналогии можно извлечь из построения? (будь то в общем использовании в программном обеспечении или нет).

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

^{[Благодарность программным концепциям, взятым из искусства и гуманитарных наук за идею]}

Вот откуда появились шаблоны дизайна.

Человек, который якобы ввел эту концепцию в мир, был Кристофер Александер в своей книге «Образец языка: города, здания, строительство» в 1977 году . Оттуда Банда Четырех (GoF) подняла его , а остальное уже история.

Даже сейчас во время лекций и в книгах по разработке программного обеспечения и архитектуре преобладают аналогии между миром строительства и миром разработки программного обеспечения.

Некоторые аналогии и ссылки, которые я могу вспомнить или вспомнить:

• Например, при изменении требований во время строительства здания для клиента, возможно, станет более очевидным, насколько это абсурдно, например: «О, и я хочу гараж вместо того, где находится кухня, которую вы только что закончили».
• Временные средства, такие как строительные леса (значение в мире строительства | разработка программного обеспечения )
• Клиенты не могут продолжать добавлять функции без того, чтобы это стоило им, много раз они хотят, чтобы что-то было сделано бесплатно, и иногда мы достаточно глупы, чтобы принять; это просто не могло произойти в строительном мире (см. требования ползучести ).
• В роли в разработке программного обеспечения: архитектор занимает центральное место в проектировании решения; консультант и подрядчик могут быть взаимозаменяемыми условиями; рабочие - программисты.
• Клиент не может предоставить точные требования в обоих случаях.
• Бюджеты и оценки времени часто неверны.
• Продукт не может быть действительно виден в его истинной форме до конца .
• Здание может иметь сбои конструкции после того, как построено, так же, как программное обеспечение имеет ошибки .
• Если продукт сделан плохо, иногда его лучше снести и начать заново, чем чинить.
• Не зная о реальных и реальных результатах некачественной работы, клиенту требуется самое дешевое решение .
• Открытый источник . Я просто смотрел этот доклад Дока Сирлса под названием « Почему весь бизнес будет основан на Open Source », где он рассказывает, как строительное сообщество делится методами и общими знаниями вместо того, чтобы патентовать их, как сообщество с открытым исходным кодом, даже когда некоторые вещи в зданиях содержат встроенные фирменные продукты.
• Проекты получаются лучше для всех, если клиент активно вовлечен .

(Если больше придет в голову, я добавлю их.)

Есть те, кто не считает, что общая аналогия верна, для этого рекомендуется прочитать «Аналог конструирования программного обеспечения сломан» . Кроме того, есть вопрос об этом в SO под названием « Что не так с аналогией между программным обеспечением и конструкцией здания?» ,

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

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

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

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

Что касается слов, многое берется из строительства, правильно и неправильно.

Фреймворк - самый очевидный, который еще не взят. И есть трубы .

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

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

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

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

Тогда клиент спрашивает что-то нелепое: можешь ли ты превратить мой садовый сарай в гараж? Я не хочу, чтобы вы делали все, что сделали ... Я просто хочу, чтобы вы сделали это побольше, чтобы я мог оставить свою машину там. Затем, во многих случаях, мастер думает, что «клиент всегда прав» и приступает к строительству надстроек на 3 сторонах сарая, чтобы увеличить его, сбивает стену между перегородками и т. Д. Конечно, крыша заканчивается до провисания, потому что он не построен правильно и т. д.

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

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

1. Человек, способный построить действительно хороший садовый сарай, не обязательно квалифицирован, чтобы построить дом.

2. Если бы вы знали заранее, что построите дом поэтапно, но все начнется как садовый сарай, вы сделаете все по-другому, и сарай будет стоить намного дороже (вы бы налили действительно толстая прокладка, убедитесь, что у вас достаточно большой проводник для полной нагрузки готового дома и т. д.).

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

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

Agile Manifesto является результатом признания того, что аналогия программного обеспечения / конструкции нарушена. Такие вещи, как автоматизированные модульные тесты и итеративные циклы выпуска, не имеют параллели в построении. Эти вещи используют почти нулевую стоимость перехода от проекта к прототипу (мы называем это компиляцией или сборкой).

На ум приходят условия Finish work и Trim .

Идея в том, что можно принять некоторые эстетические решения, когда основные структурные решения завершены.

Старая пословица: отмерь дважды и отрежь один раз.

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

Ограничения существуют как в строительстве, так и в программировании .

Если вы, как клиент, не можете выдвигать такие нелепые требования, как расширение готового здания гостиницы в выходные дни и помещение аэропорта на подземный этаж и взлетно-посадочную полосу в его пентхаусе, почему вы не можете согласиться с тем, что не все корректировки с готовым софт возможен? Это не волшебный шар 0 и 1, это сложная строительная структура, хотя и несущественная, но и со своими ограничениями.

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

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

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

С другой стороны, мы все еще обнаруживаем, что многие из наших моделей и практик нуждаются в улучшении. Раньше синглтон был хорошей идеей, теперь большинство, кто об этом думает, предпочитают паттерны IoC / DI.

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

Конечно, в обеих областях архитектор может нарисовать то, что не может быть реализовано.

Строительные леса , «временное сооружение, используемое для поддержки людей и материалов при строительстве или ремонте зданий и других крупных сооружений». ^{[определение из википедии]}

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

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

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

Ошибки могут в конечном итоге быть чертовски дорогими или даже убивать людей?

Существуют основные рекомендации для сложных инженерных проектов любой дисциплины:

1. важность планирования, чертежи, дизайн и т. д.,
2. Важность основной математики
3. повторное использование идей / обучение из других подобных проектов
4. используя готовые строительные блоки / компоненты, созданные кем-то другим
5. исправление проблем в самом начале жизненного цикла
   и т. д.,

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

Через некоторое время

Но в строительной отрасли работникам платят сверхурочные.

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

Я не могу найти на рынке ничего, что соответствовало бы нашим изготовленным на заказ розеткам.

Когда у тебя есть только молоток, все выглядит как гвоздь. :)

Повторяющиеся деформации травм

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