Czego programiści mogą nauczyć się od branży budowlanej? [Zamknięte]

Rozmawiając z kolegami o zasadach projektowania i tworzenia oprogramowania, zauważyłem, że jednym z najczęstszych źródeł analogii jest przemysł budowlany. Mamy budować oprogramowanie i uważamy, że projektowanie i budowa być architektura .

Jednym z najlepszych sposobów uczenia się (lub nauczania) jest analiza analogii - jakie inne analogie można wyciągnąć z konstrukcji? (czy już są powszechnie używane w oprogramowaniu czy nie).

Podaj opis lub swoje osobiste doświadczenie dotyczące tego, jak koncepcja programowania jest podobna do koncepcji budowy.

^{[Podziękowania dla koncepcji programowania zaczerpniętych ze sztuki i nauk humanistycznych dla pomysłu]}

Stąd wzięły się wzorce projektowe.

Osobą, która rzekomo przedstawiła światu tę koncepcję, był Christopher Alexander w swojej książce „A Pattern Language: Towns, Buildings, Construction” z 1977 r . Stamtąd Gang of Four (GoF) podniósł go , a reszta jest już historią.

Nawet teraz podczas wykładów oraz w książkach poświęconych tworzeniu oprogramowania i architekturze nadal dominują analogie między światem budownictwa a światem rozwoju oprogramowania.

Niektóre analogie i odniesienia, które mogę wymyślić lub przypomnieć:

• Na przykład zmiana wymagań podczas budowy budynku może być bardziej oczywiste dla klienta, jak absurdalne jest to, np .: „OH, i chcę garaż zamiast tego, gdzie jest właśnie ukończona kuchnia”.
• Tymczasowe pomoce, takie jak rusztowania (w budownictwie | rozwój oprogramowania )
• Klienci nie mogą dodawać funkcji bez ponoszenia kosztów, wiele razy chcą, aby rzeczy były robione za darmo, a czasem jesteśmy na tyle głupi, aby zaakceptować; to po prostu nie mogło się zdarzyć w świecie budownictwa (patrz wymagania pełzają ).
• Te role w rozwoju oprogramowania: architekt ma zasadnicze znaczenie dla zaprojektowania rozwiązania; konsultant i wykonawca mogą być warunkami wymiennymi; pracownicy są programistami.
• Klient nie może podać dokładnych wymagań w obu przypadkach.
• Budżety i szacunki czasu są często błędne.
• Produktu nie można naprawdę zobaczyć w prawdziwej formie do końca .
• Budynek może mieć błędy konstrukcyjne po zbudowaniu, podobnie jak błędy oprogramowania .
• Jeśli produkt jest źle wykonany, czasem lepiej jest rozebrać i zacząć od nowa niż naprawić.
• Nie wiedząc o rzeczywistych i rzeczywistych skutkach złej jakości pracy, klient chce najtańszego rozwiązania .
• Open Source . Właśnie oglądałem tę rozmowę z Doc Searls zatytułowaną „ Dlaczego cała firma będzie oparta na otwartym źródle ”, gdzie opowiada, w jaki sposób społeczność budowlana dzieli się technikami i ogólną wiedzą zamiast opatentować je podobnie jak społeczność open source, nawet gdy niektóre rzeczy w budynkach zawierają wbudowane produkty zastrzeżone.
• Projekty są lepsze dla wszystkich, jeśli klient jest aktywnie zaangażowany .

(Jeśli przyjdzie ci na myśl więcej, dodam je.)

Są tacy, którzy nie sądzą, że ogólna analogia jest poprawna, zalecana lektura to Analogia budowy oprogramowania jest zepsuta . Jest też pytanie na ten temat zatytułowane Co jest nie tak z analogią między oprogramowaniem a konstrukcją budynku? .

W całej historii rozwoju oprogramowania czerpaliśmy wiele słów i pomysłów z branży budowlanej. W rzeczywistości prawdopodobnie pochłonęliśmy ich wielu i nie sądzę, aby zostało nam coś jeszcze do zrobienia.

Cały proces polegał na tym, że klienci sporządzili specyfikację, potem projekt architekta, następnie inżynierowie projektujący, a na koniec małpy kodujące wdrażające z branży budowlanej, i okazało się, że było to całkowicie mylące.

Dzieje się tak dlatego, że kiedy budujesz dom, jeśli twoja podstawa jest zła, jesteś skazany. Poważnie. Podniesienie budynku i zastąpienie jego fundamentów kosztuje więcej niż złomowanie całości i rozpoczęcie od nowa. Ale w oprogramowaniu jest to całkowicie możliwe. Przekształciłem oprogramowanie klienckie w rozwiązanie klient-serwer, tak aby użytkownik niczego nie zauważył, oprócz tego, że przeniosłem modem do serwerowni. To jak zastąpienie betonowego fundamentu łodzią podczas spania mieszkańców.

Oprogramowanie nie przypomina budowy. I dlatego cała branża oprogramowania w pewnym momencie zaczęła działać na początku, a cały proces „wodospadowy” prowadzenia projektów został zastąpiony sprawnymi procesami w ciągu zaledwie kilku lat.

Jeśli chodzi o słowa, wiele wzięto z budowy, słusznie i błędnie.

Framework jest najbardziej oczywistym, którego jeszcze nie podjęto. I są fajki .

Użyłem tej analogii ... wiele projektów oprogramowania zaczyna się, ponieważ osoba, która potrzebuje jakiegoś oprogramowania, zna odpowiednik „złotej rączki” i zatrudnia tę osobę, aby zbudowała dla nich oprogramowanie równoważne szopie ogrodowej. To niewielka, przydatna mała aplikacja, która bardzo dobrze wykonuje swoją pracę.

Następnie klient wraca do złotej rączki, zadowolony ze swojej pracy i prosi go o zmianę oprogramowania, aby zrobić jeszcze jedną rzecz. Wiele razy ta nowa funkcja nie ma wiele wspólnego z pierwotną prośbą, więc prawie tak, jakby prosili cię o zbudowanie innego pokoju z tyłu szopy ogrodowej z osobnym wejściem.

Następnie chcą umieścić światło w szopie, aby odzyskać złotą rączkę, a on uruchamia pojedynczy obwód z głównego panelu w domu, instaluje wyłącznik światła łańcucha na suficie każdego pokoju i łączy je z obwodem .

Klient następnie decyduje, że chce uruchomić jakieś elektronarzędzie, ale wciąż wysadza wyłącznik, więc oddzwania do tej osoby, a on musi oderwać pojedynczy obwód, który poprowadził do głównego panelu, i zainstalować większy przewodnik i podpanel w szopie. Musiał dwukrotnie poprowadzić przewód i zapłacić za dwa pozwolenia elektryczne itp. Jest to nieefektywne.

Następnie klient prosi o coś absurdalnego: czy możesz zamienić moją szopę ogrodową w garaż? Nie chcę, żebyś zrobił wszystko, co zrobiłeś ... Chcę tylko, żebyś to powiększył, żeby móc tam zaparkować samochód. Następnie, w wielu przypadkach, złota rączka myśli, że „klient ma zawsze rację” i kontynuuje budowę dodatków na 3 stronach szopy, aby ją powiększyć, burzy ścianę między partycjami itp. Oczywiście dach kończy się zwiotczenie, ponieważ nie jest odpowiednio skonstruowane itp.

Więc klient nie jest już pod wrażeniem, ale wciąż chce więcej. Wzywają złotą rączkę w kółko, aby po prostu dodała jeszcze jeden pokój lub zmieniła istniejący pokój, aby to zrobić itp. W efekcie powstaje coś, co wygląda jak Nora i jest tak samo architektonicznie zdrowe.

Teraz większość ludzi nie jest wystarczająco głupia, aby wypróbować to w świecie konstrukcyjnym, ale dzieje się tak cały czas w świecie oprogramowania, ponieważ ludzie nie nawiązują takich połączeń:

1. Osoba wykwalifikowana do zbudowania naprawdę ładnej szopy ogrodowej niekoniecznie ma kwalifikacje do budowy domu.

2. Jeśli z góry wiedziałeś, że zamierzasz zbudować dom etapami, ale miał on zacząć się tylko jako szopa ogrodowa, zrobiłbyś wszystko inaczej, a szopa ogrodowa kosztowałaby znacznie więcej (nalałbyś naprawdę gruba podkładka, upewnij się, że poprowadziłeś wystarczająco duży przewodnik, aby w pełni załadować gotowy dom itp.).

3. W wielu przypadkach przejście z jednego etapu na drugi wymaga cofnięcia dużej ilości wcześniej wykonanej pracy, co powoduje, że jest ona droższa, niż się wydaje.

4. W świecie budownictwa możemy dać klientowi dobry pomysł, jak będzie wyglądał wynik na etapie projektowania, ale nie mamy takiej umiejętności w świecie oprogramowania. Jeśli dotarłeś do tego momentu, w zasadzie napisałeś znaczną część oprogramowania.

Manifest Agile jest wynikiem uznania, że ​​analogia oprogramowania / konstrukcji jest zepsuta. Rzeczy takie jak zautomatyzowane testy jednostkowe i iteracyjne cykle uwalniania nie mają konstrukcji równoległej. Te rzeczy wykorzystują prawie zerowy koszt przejścia od projektu do prototypu (nazywamy to kompilacją lub budową).

Przychodzą na myśl warunki Zakończ pracę i Przytnij .

Pomysł, że można odłożyć pewne decyzje estetyczne na czas, gdy główne decyzje strukturalne są zakończone.

Stare przysłowie: Zmierz dwa razy i pokrój raz.

Edycja: W Manifeście listy kontrolnej autorstwa Atula Gawande znajduje się sekcja , która mówi o zarządzaniu dużymi zleceniami budowlanymi. Kiedy dochodzą do punktu, który jest naprawdę skomplikowany, spotykają się z zaangażowanymi ekspertami, aby ponownie przyjrzeć się problemowi i sprawdzić, czy w trakcie projektu wydarzyło się coś, o czym wszyscy powinni wiedzieć. Prawdopodobnie nie jesteśmy w stanie zaplanować ich z tak dużym wyprzedzeniem.

Istnieją ograniczenia zarówno w budowie, jak i programowaniu .

Jeśli jako klient nie możesz stawiać tak absurdalnych żądań, aby przedłużyć ukończony budynek hotelu na weekend i umieścić lotnisko w podziemnej podłodze oraz pas startowy na jego najwyższym piętrze, dlaczego nie możesz zaakceptować tego nie wszystko z gotowym wykończeniem oprogramowanie jest możliwe? To nie jest magiczna kula zer i jedynek, to złożona konstrukcja, choć nieistotna, ale z jej ograniczeniami.

Pracowałem w budownictwie przez szkołę i są miejsca, w których nie ma nawet analogii, obowiązuje ta sama koncepcja. Ale często pokusa porównywania sięga zbyt daleko.

Kiedy pracowałem nad oszacowaniem pracy, wiedziałem, że istnieją dość pewne średnie, ile czasu zajmie zrobienie czegoś. Na przykład w celu wykonania okien witryn sklepowych po prostu policzyliśmy liczbę połączeń w ramach z planów i mieliśmy całkiem niezły pomysł, ile to zajmie. Podobnie jak programowanie, musieliśmy uwzględniać zmienne zgodnie z harmonogramem, ale to może wyssać z ciebie życie. Na przykład: pokazanie się ekipy hydraulicznej, która dowiaduje się, że parking jest brukowany i nie mogą dostać się do budynku z powodu gorącego asfaltu na drodze, który jest dość drogi.

Jednak budownictwo ma tysiące lat doświadczenia. Podstawowe zasady handlu oparte są na tych samych prawach fizyki, którymi zawsze były. Obliczenia obciążenia wiatrem i obciążeniem własnym są takie same, jak w przypadku reguł suwakowych. Nastąpiły ulepszenia narzędzi i technik, ale w szybkim tempie w porównaniu z tym, czego doświadczamy.

Z drugiej strony wciąż odkrywamy, że wiele naszych wzorców i praktyk wymaga miejsca na ulepszenia. Singleton był kiedyś dobrym pomysłem, teraz większość, którzy myślą o tym, woli wzorce IoC / DI.

Brakuje nam także znaczących licencji i certyfikacji. W wielu obszarach, nawet po prostu jako specjalista, nie mówiąc już o instalatorze, hydraulik musi posiadać licencję lub pracować pod nadzorem kogoś, kto jest. Uzyskanie tej licencji wymaga pewnego czasu pracy w terenie. Nie opowiadam się za lub przeciw licencjonowaniu, po prostu podkreślam, że to ogromna różnica.

Oczywiście w obu dziedzinach architekt może narysować coś, czego nie można zaimplementować.

Rusztowanie „tymczasowa konstrukcja służąca do wspierania ludzi i materiałów przy budowie lub naprawie budynków i innych dużych konstrukcji”. ^{[definicja z wikipedii]}

Ta koncepcja działa, ponieważ rusztowanie w programowaniu można szybko utworzyć i zapewnia tymczasową funkcjonalność, dopóki nie powstanie prawdziwa struktura.

Wiem, że niektóre firmy budowlane, które pracują w gospodarstwie, aby zaoferować najniższą cenę, wykonują niechlujstwa, uchylają się od obowiązku gwarancyjnego, skupiają się na dacie ponad jakością, a następnie naliczają absurdalny zysk za „gotowy” produkt.

Ale nie sądzę, aby programiści lub agencje konsultacyjne nauczyli się czegokolwiek z tych praktyk.

Błędy mogą być drogie jak diabli, a nawet zabijać ludzi?

Istnieją podstawowe wytyczne dotyczące złożonych projektów inżynierskich dowolnej dyscypliny:

1. znaczenie planowania, niebieskich wydruków, projektowania itp.,
2. znaczenie podstawowej matematyki
3. ponowne wykorzystanie pomysłów / uczenia się z innych podobnych projektów
4. używając gotowych elementów / komponentów zbudowanych przez kogoś innego
5. korygowanie problemów na bardzo wczesnym etapie cyklu życia
   itp.,

Podobieństwa między architekturą, dyscyplinami inżynierii lądowej i inżynierii oprogramowania wydają się wynikać głównie z braku linii montażowych : każdy projekt jest wyjątkowy sam z siebie.

Z biegiem czasu

Ale w branży budowlanej pracownicy otrzymują wynagrodzenie za nadgodziny.

Stosowanie standardów, konwencji i gotowych komponentów. Prawdopodobnie nie napotkasz tego rodzaju problemu.

Nie mogę znaleźć na rynku niczego, co pasowałoby do naszych niestandardowych gniazd.

Kiedy wszystko, co masz, to młotek, wszystko wygląda jak gwóźdź. :)

Powtarzające się obrażenia odkształcenia

Stanowią one zagrożenie zawodowe w obu branżach i należy podjąć środki ostrożności, aby im zapobiec. Gdy zaczną, trudno je wyleczyć.