Що можуть дізнатися програмісти у будівельній галузі? [зачинено]

Розмовляючи з колегами про принципи розробки та розробки програмного забезпечення, я помітив, що одним із найпоширеніших джерел аналогій є будівельна галузь. Ми будуємо програмне забезпечення і вважаємо дизайн та структуру архітектурою .

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

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

^{[Кредит до програмування концепцій, взятих з мистецтва та гуманітарних наук для ідеї]}

Ось звідки взялися дизайнерські зразки.

Людина, яка нібито представила концепцію світові, був Крістофер Олександр у своїй книзі "Мова візерунка: міста, будівлі, будівництво" у 1977 році . Звідти Банда чотирьох (GoF) забрала його , а решта - історія.

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

Деякі аналогії та посилання, про які я можу придумати або згадати:

• Наприклад, змінивши вимоги під час будівництва будинку, можливо, клієнту стане очевидніше, наскільки це абсурдно, наприклад: "О, і я хочу гараж замість того, де кухня, яку ви тільки що закінчили".
• Тимчасові засоби, такі як будівельні ліси (сенс у світі будівництва | розробка програмного забезпечення )
• Клієнти не можуть продовжувати додавати функції, не коштуючи їх, багато разів вони хочуть, щоб речі були зроблені безкоштовно, і іноді ми досить тупі, щоб прийняти; що просто не могло статися у світі будівництва (див. вимоги повзучі ).
• У ролі в розробці програмного забезпечення: архітектор займає центральне місце в проектуванні рішення; консультант та підрядник можуть бути взаємозамінними умовами; робітники - це програмісти.
• Клієнт не може забезпечити точні вимоги в обох випадках.
• Бюджети та кошториси часу часто неправильні.
• Продукт неможливо побачити у справжньому вигляді до кінця .
• Будівля може мати помилки в будівництві після побудови, так само як і програмне забезпечення має помилки .
• Якщо виріб зроблено погано, іноді його краще знести і почати заново, ніж виправляти.
• Не знаючи про фактичні та реальні результати неякісної роботи, клієнт хоче найдешевшого рішення .
• Open Source . Я щойно дивився цю розмову з Doc Searls під назвою " Чому весь бізнес буде базуватися на відкритих джерелах ", де він розповідає, як будівельна громада ділиться технікою та загальними знаннями, а не патентує їх так, як спільнота з відкритим кодом, навіть коли деякі речі в будівлях містять вбудовані фірмові продукти.
• Проекти виходять краще для всіх, якщо клієнт бере активну участь .

(Якщо більше прийде на думку, я додам їх.)

Є такі, хто не вважає, що загальна аналогія є правильною, рекомендується прочитати це: Аналогія побудови програмного забезпечення порушена . Крім того, на цьому запитанні є питання під назвою Що не так з аналогією між програмним забезпеченням та будівництвом будівель? .

За всю історію розробки програмного забезпечення ми взяли багато слів та ідей з будівельної галузі, і насправді ми взяли багато, і я не думаю, що є що вдіяти.

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

Це тому, що коли ви будуєте будинок, якщо ваш фундамент неправильний, ви стикаєтесь. Серйозно вийшов. Підняти будівлю і замінити фундамент коштує більше, ніж бракувати всю справу і починати спочатку. Але в програмному забезпеченні це цілком можливо. Я переробив програмне забезпечення клієнта на рішення клієнт-сервер, не помічаючи нічого користувача, за винятком того, що я перемістив модем у серверну кімнату. Це як замінити бетонну основу човником, поки мешканці спали.

Програмне забезпечення не схоже на будівництво. І тому вся індустрія програмного забезпечення увімкнула час на початку, і весь процес «водоспаду» запущених проектів був замінений гнучкими процесами всього за пару років.

Щодо слів багато береться з побудови, правильно і неправильно.

Рамка є найбільш очевидною, яка вже не прийнята. А труби є .

Я використовував цю аналогію ... багато програмних проектів починається, тому що людина, яка потребує певного програмного забезпечення, знає еквівалент "майстра", і вони наймають цю людину, щоб створити їм програмний еквівалент садового сараю. Це маленьке, корисне маленьке додаток, яке дуже добре виконує свою роботу.

Потім замовник повертається до майстра, задоволений їх роботою, і просить змінити програмне забезпечення, щоб зробити ще одну справу. Багато разів ця нова функція не має великого відношення до оригінального запиту, тому майже так, як вони просять вас побудувати ще одну кімнату на задній частині садового сараю з окремим входом.

Потім вони хочуть поставити світло всередині сараю, щоб вони повернули майстра назад, і він запускає єдину ланцюг від головної панелі будинку, встановлює вимикач ланцюгового вимикача в стелі кожної кімнати і підключає їх до ланцюга .

Потім замовник вирішує, що хоче запустити деякі електроінструменти, але він продовжує дути автоматичним вимикачем, тому вони передзвонюють людину, і він насправді повинен вирвати єдину ланцюг, яку він вибіг на головну панель, і встановити більший провідник і підпанель у сараї. Йому довелося двічі провести дріт і заплатити за два дозволи на електроенергію тощо. Це неефективно.

Тоді клієнт запитує щось абсурдне: чи можете ви перетворити мій сарай на гараж? Я не хочу, щоб ти повторно робив все, що ти зробив ... Я просто хочу, щоб ти зробив це більше, щоб я міг там припаркувати свою машину. Тоді, у багатьох випадках, майстер вважає, що "замовник завжди правий", і починає будувати прибудови на 3 сторони сараю, щоб зробити його більше, збиває стіну між перегородками і т. Д. Звичайно, дах закінчується до провисання, оскільки воно не побудовано правильно тощо.

Тож клієнт уже не вражений, але все ж хочеться більше. Вони просять рознощика знову і знову просто додати ще одну кімнату, або змінити цю існуючу кімнату, щоб це зробити, і т. Д. Ви закінчуєте щось таке, що схоже на The Burrow і виглядає так само архітектурно.

Зараз більшість людей не досить дурні, щоб спробувати це у світі будівництва, але це відбувається постійно у світі програмного забезпечення, тому що люди не мають таких зв'язків:

1. Людина, кваліфікована для будівництва справді гарного садового сараю, не обов'язково кваліфікована для будівництва будинку.

2. Якби ви заздалегідь знали, що збираєтеся будувати будинок поетапно, але це буде тільки починати як садовий сарай, ви зробили б справи по-іншому, і садовий сарай коштуватиме набагато дорожче (ви б насипали дійсно товста колодка, переконайтеся, що ви провели провідника, достатньо великого для повного завантаження готового будинку тощо).

3. У багатьох випадках перехід від однієї стадії до іншої передбачає скасування великої кількості раніше виконаних робіт, що робить її дорожчою, ніж здається, що має бути.

4. У світі будівництва ми можемо дати клієнту гарне уявлення про те, як виглядатиме результат на етапі проектування, але ми не маємо такої здатності у світі програмного забезпечення. Якщо ви довели до цього моменту, ви в основному написали значну частину програмного забезпечення.

Agile Manifesto - це результат визнання, що аналогія програмного забезпечення / конструкції порушена. Такі речі, як автоматизовані випробування блоків та ітераційні цикли вивільнення, не мають паралельних конструкцій. Ці речі скористаються майже нульовою вартістю переходу від дизайну до прототипу (ми називаємо це складанням або побудовою).

Приходять на думку терміни « Закінчити роботу» та « Трим» .

Ідея, що нормально відкласти деякі естетичні варіанти, коли основні структурні рішення будуть завершені.

Стара приказка: відміряйте двічі і поріжте один раз.

Редагувати: У Маніфесті контрольного списку Атула Гаванде є розділ , який розповідає про управління великими будівельними роботами. Коли вони дістаються до справді складного питання, вони мають зустріч із залученими експертами, щоб переглянути проблему та побачити, чи сталося щось під час проекту, про що всі повинні знати. Ми, мабуть, не можемо запланувати їх настільки заздалегідь.

Обмеження існують як у побудові, так і в програмуванні .

Якщо ви як замовник не можете висунути такі смішні вимоги, як розширити готову будівлю готелю протягом вихідних і поставити аеропорт у підземний поверх та злітно-посадкову смугу на його пентхаус, то чому ви не можете прийняти, що не все коригування готовим програмне забезпечення можливе? Це не чарівний куля 0 і 1, це складна конструкція, хоча і несуттєва, але і з обмеженнями.

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

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

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

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

Де нам також не вистачає значних ліцензій та сертифікації. У багатьох районах, навіть щоб бути лише ремонтником, не кажучи вже про монтажника, сантехнік повинен мати ліцензію або працювати під наглядом когось, хто є. Щоб отримати цю ліцензію, потрібно певний час працювати на місцях. Я не висловлююсь за або проти ліцензування, просто вказую на це, оскільки це величезна різниця.

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

Ліси , "тимчасова споруда, яка використовується для підтримки людей та матеріалів при будівництві чи ремонті будівель та інших великих споруд". ^{[визначення з wikipedia]}

Ця концепція працює тому, що риштування в програмуванні здатне швидко створюватись і забезпечує тимчасовий функціонал, поки не буде створена реальна структура.

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

Але я не думаю, що програмісти або консалтингові агенції нічого не навчилися з цих практик.

Клопи можуть бути дорогими, як пекло, або навіть вбивати людей?

Існують основні вказівки щодо складних інженерних проектів будь-якої дисципліни:

1. важливість планування, блакитних відбитків, дизайну тощо,
2. важливість основної математики
3. повторне використання ідей / навчання з інших подібних проектів
4. використовуючи готові будівельні блоки / компоненти, побудовані кимось іншим
5. виправлення проблем на початку життєвого циклу
   тощо,

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

Через деякий час

Але у будівельній галузі працівники отримують понаднормову оплату.

Використання стандартів, конвенцій та попередньо складених компонентів. Ви, ймовірно, не зіткнетеся з подібними проблемами.

На ринку я не можу знайти нічого, що відповідає нашим розробленим розеткам.

Коли все, що у вас є, це молоток, все виглядає як цвях. :)

Повторні деформації

Вони небезпечні для праці в обох галузях, і для їх запобігання потрібно вживати запобіжних заходів. Як тільки вони починаються, їх важко вилікувати.