Dlaczego niektórzy programiści uważają, że istnieje kontrast między teorią a praktyką? [Zamknięte]

Porównując inżynierię oprogramowania z inżynierią lądową, byłem zaskoczony, widząc inny sposób myślenia: każdy inżynier budownictwa wie, że jeśli chcesz zbudować małą chatkę w ogrodzie, możesz po prostu zdobyć materiały i przejść do budowy, a jeśli chcesz zbudować dom 10-kondygnacyjny (lub, na przykład, coś jak ten ) trzeba zrobić sporo matematyki, aby mieć pewność, że nie będzie się rozpadać.

W przeciwieństwie do tego, rozmawiając z niektórymi programistami lub czytając blogi lub fora, często znajduję szeroko rozpowszechnioną opinię, którą można sformułować mniej więcej w następujący sposób: teoria i metody formalne są dla matematyków / naukowców, podczas gdy programowanie polega bardziej na wykonywaniu zadań .

Zwykle sugeruje się tutaj, że programowanie jest czymś bardzo praktycznym i chociaż chociaż formalne metody, matematyka, teoria algorytmów, czyste / spójne języki programowania itp., Mogą być interesującymi tematami, często nie są potrzebne, jeśli wszystko, czego się chce, to dostać rzeczy gotowe .

Zgodnie z moim doświadczeniem powiedziałbym, że chociaż nie potrzebujesz wiele teorii, aby stworzyć 100-liniowy skrypt (chatę), w celu opracowania złożonej aplikacji (10-piętrowy budynek) potrzebujesz projektu strukturalnego, cóż, -definiowane metody, dobry język programowania, dobre podręczniki, w których można wyszukiwać algorytmy itp.

Tak więc teoria IMO (odpowiednia ilość) jest jednym z narzędzi do wykonywania zadań .

Moje pytanie brzmi: dlaczego niektórzy programiści uważają, że istnieje kontrast między teorią (metody formalne) a praktyką (wykonywanie zadań)?

Czy inżynieria oprogramowania (oprogramowanie budowlane) jest postrzegana przez wielu jako równie łatwa w porównaniu, powiedzmy, inżynieria lądowa (budowanie domów)?

Czy te dwie dyscypliny są naprawdę różne (oprócz oprogramowania o kluczowym znaczeniu, awaria oprogramowania jest znacznie bardziej akceptowalna niż awaria budynku)?

Staram się podsumować, co zrozumiałem z dotychczasowych odpowiedzi.

1. W przeciwieństwie do inżynierii oprogramowania, w inżynierii lądowej jest o wiele bardziej jasne, jaka teoria (modelowanie, projektowanie) jest potrzebna do określonego zadania.
2. Wynika to częściowo z faktu, że inżynieria lądowa jest tak stara jak ludzkość, podczas gdy inżynieria oprogramowania istnieje już od kilku dziesięcioleci.
3. Innym powodem jest fakt, że oprogramowanie jest bardziej niestabilnym rodzajem artefaktu, z bardziej elastycznymi wymaganiami (może wystąpić awaria), różnymi strategiami marketingowymi (dobry projekt można poświęcić, aby szybko wprowadzić go na rynek) itp.

W konsekwencji znacznie trudniej jest ustalić, jaka właściwa ilość projektu / teorii jest odpowiednia w inżynierii oprogramowania (za mało -> niechlujny kod, za dużo -> nigdy nie mogę się skończyć), ponieważ nie ma ogólnej reguły i tylko (dużo) doświadczenia może pomóc.

Więc jeśli poprawnie interpretuję twoje odpowiedzi, ta niepewność co do tego, ile teorii jest naprawdę potrzebna, przyczynia się do mieszanych uczuć miłości / nienawiści, które niektórzy programiści mają względem teorii.

Myślę, że główna różnica polega na tym, że w inżynierii lądowej fizyka świata rzeczywistego działa jak ciągła, potężna kontrola rzeczywistości, która utrzymuje rozsądek teorii i ogranicza złe praktyki, podczas gdy w inżynierii oprogramowania nie ma równie silnej siły, aby utrzymać niepraktyczne koncepcje wieży z kości słoniowej jako tandetne wykonanie w szachu.

Wielu programistów miało złe doświadczenia z niekontrolowaną teorią, która stała się aktywną przeszkodą w realizacji zadań (np. „Wykonywalny UML”, super biurokratyczne procesy rozwoju). I odwrotnie, brudne hacki i łatki mogą cię do cholery daleko posunąć, choć w końcu powoli. I jak zauważyłeś w ostatnim akapicie: niepowodzenia zwykle nie są tak ostateczne, a zatem nie są tak problematyczne.

Inżynieria oprogramowania i inżynieria lądowa mają niewiele wspólnego. Wysiłki inżynierii lądowej są ograniczone właściwościami fizycznymi ich materiałów i środowiska. Inżynierowie budowlani spędzają dużo czasu na poznawaniu właściwości gleby i właściwości materiału. Rozwój oprogramowania jest fizycznie ograniczony jedynie szybkością procesorów i dostępną pamięcią. Oba są łatwe do zrozumienia i nie poświęcamy dużo czasu na ich studiowanie. Głównym ograniczeniem rozwoju oprogramowania jest ludzki intelekt. I nie ma dwóch takich samych programistów. Czy ten kod można utrzymać? Przez kogo? Trzywierszowa implementacja quicksort w Haskell może być oczywiście poprawna dla niektórych, ale dla innych niezrozumiała. Zespół dwóch osób może ukończyć aplikację w ciągu miesiąca, podczas gdy inny zespół dziesięciu ma problemy z dostarczeniem w ciągu roku.

Tworzenie oprogramowania to projektowanie, artefakty są o rząd wielkości bardziej złożone niż jakikolwiek wyprodukowany artykuł, a każdy z nich jest unikalny.

Jako mniej lub bardziej szczery inżynier mechanik (z pewnym obywatelskim) został programistą, następnie doktorem CS (AI), potem nauczycielem, a następnie programistą (przepraszam, inżynier oprogramowania ), mam na myśli ten ogólny temat.

W tradycyjnej inżynierii

• musisz poznać swoją matematykę i naukę, ponieważ wszystko, co robisz, jest na niej oparte
• „bohaterami” w tej dziedzinie są ludzie, którzy wymyślają nowe rzeczy, odkrywają nowe pomysły, rozwiązują problemy uważane za nierozwiązywalne

Istnieje „fizyka”, która dotyczy oprogramowania - teorii informacji, ale inżynierowie oprogramowania mają niewielki kontakt z nią, a na pewno nic nie ma zastosowania. Większość teorii, którą otrzymują, to obliczalność i big-O.

Ciągle też jestem zdumiony ludźmi, którzy uważają, że znajomość programowania wystarczy i nie muszą rozumieć tematyki ich programów.

Co więcej, nie zachęca się pomysłowości. Odradza się stosowanie metod myślenia grupowego o najmniejszym mianowniku, zamaskowanych jako „czytelność”. (Wyobraź sobie, że inżynierowie lotniczy lub nuklearni byliby zachęcani do nie robienia niczego, co może być trudne do zrozumienia dla ich młodszych rówieśników.)

Rzeczy, których się uczą, takie jak programowanie aplikacji internetowych, mają wielką wartość. Podobnie jest z umiejętnościami hydraulika lub elektryka, ale to nie jest inżynieria.

Jeśli zrobię krok w stronę większości programów i zrobię coś, co nie jest najlepszym projektem, ale wykonam zadanie, nikt nie umrze. To ten sam powód, dla którego chata w ogrodzie nie potrzebuje takich samych standardów jak budynek 10-piętrowy. Mogę jednak zbudować bardzo dużą aplikację, taką jak Facebook, a jeśli to spieprzy i straci jakieś dane, czy coś w tym rodzaju, nie jest to naprawdę wielka sprawa. Łatwiej jest również naprawić fundament dużej aplikacji po tym, niż zastąpić fundament 10-piętrowego budynku. Wszystko sprowadza się do kontekstu i obliczania ryzyka.

Mogę też bezpiecznie i po prostu dodawać do aplikacji. Nie możesz łatwo wrzucić nowego trzeciego piętra 10-piętrowego budynku (co czyni go 11). Mogę codziennie wrzucać nową funkcję do dużej aplikacji.

Teraz dobry projekt ułatwia to wszystko w programowaniu. Ale przy złym projekcie i ryzyku nie jest to niemożliwe ... błędne oprogramowanie. Zwykle nie śmierć.

Opowiedz mi o tym. Mam rację.

Kiedyś profesor powiedział mi kiedyś, że zwlekanie prowadzi do zwlekania, chociaż większość ludzi po nocy nękania pisaniem / wrzucaniem / programowaniem mówi sobie: „Nigdy więcej tego nie zrobię. Następnym razem zacznę wcześnie i załatw wcześnie ”. Z mojego doświadczenia jako doskonałego prokrastynatora stwierdziłem, że jest to prawdą, a oto wyjaśnienie profesora, dlaczego: bez względu na to, jak nieprzyjemne jest doświadczenie zwlekania, w większości przypadków osiąga się względny sukces. Jest to zachowanie wysokiego ryzyka / wysokiej nagrody. Po chwili zapominasz o wszystkich nieprzyjemnościach i pamiętasz tylko nagrodę. Zatem kolejna pokusa zwlekania jest tym bardziej kusząca, ponieważ udało się wam ostatni raz.

Myślę, że można tu dokonać analogii do techniki programowania „załatw sprawę”, którą zbyt często widzimy. Programista lub zespół programistów, być może z powodu ignorancji, lenistwa, a może prawdziwego ograniczenia czasowego, przyjmuje podejście „załatwiaj sprawy” w programowaniu, wyrzucając całą swoją teorię, matematykę i dobre praktyki za okno. I wiesz co? Robią wszystko. Nie jest elegancki, ładny ani łatwy w utrzymaniu, ale spełnia swoje zadanie. Może przełożony nietechniczny, który nie zna średnika z semafora, chwali go za „załatwienie sprawy”. Zatem następnym razem, gdy programista pokusi się na takie luźne podejście do programowania, jest to tym łatwiejsze, że hej, zadziałało ostatnim razem, prawda? Jest to „łatwe” wyjście, chyba że jesteście biedni,

Byłem tą biedną, nieszczęśliwą duszą i prawdopodobnie wielu z was. Błagam was wszystkich. Nie wybieraj łatwego wyjścia! :)

Twoja przesłanka jest wadliwa. Głównym powodem, dla którego inżynierowie budownictwa stosują inżynierię przy projektowaniu dużych budynków, mostów, tuneli itp., Jest zapewnienie minimalnego zużycia materiału (betonu, stali konstrukcyjnej itp.), Który spełnia wymagane normy bezpieczeństwa. Całkowicie możliwe jest zbudowanie wysokiego budynku bez przeszkód w matematyce (np. Piramidy starożytnych cywilizacji egipskich i Majów), jeśli koszty materiałów i robocizny nie są przedmiotem, ale po wybudowaniu zazwyczaj nie ma sensu modyfikować aby zwiększyć efektywność wykorzystania materiałów.

W projektowaniu dużych systemów oprogramowania występuje nieco inna dynamika. W ogóle są one zwykle niedoprojektowane, ale dzieje się tak dlatego, że projekt może być dynamicznie zmieniany w miarę postępu prac, czego po prostu nie da się tak łatwo zrobić przy projektach inżynieryjnych.

Wspólnym czynnikiem jest koszt. Projektowanie w tradycyjnym projekcie inżynieryjnym zmniejsza koszty (zarówno faktyczne, pod względem materiałowym, jak i potencjalnym pod względem odpowiedzialności), podczas gdy przychodzi moment na rozwój oprogramowania, w którym koszt projektu wzrasta ponad wartość zwracaną.

Chciałbym również wskazać, oprócz kilku innych doskonałych odpowiedzi, że ludzkość robi odpowiednik „inżynierii lądowej” od czasu Egipcjan, więc mieliśmy dużo czasu na udoskonalenie ogólnej teorii, jak rzeczy powinny będzie zrobione. Tworzymy oprogramowanie od około 70 lat (w zależności od tego, co uważasz za pierwsze „oprogramowanie”); Mam na myśli, że nie mieliśmy tyle czasu, aby rozwinąć to samo doświadczenie.

Plany architekta / inżyniera budownictwa praktycznie nigdy nie są identyczne z planami „jak zbudowano”. Coś ZAWSZE się zmienia. Dlaczego? Ponieważ istnieją i zawsze będą „nieznane nieznane”. Są rzeczy, o których wiesz i które możesz zaplanować, rzeczy, o których wiesz, że są nieznane, więc możesz badać i oceniać, a są rzeczy, o których nie wiesz, że nie wiesz; „niespodzianki”. Chcesz wyeliminować je w większości systemów, ucząc się wszystkiego, co możesz, ale wystarczy jedno małe naruszenie kodu budynku (które może opierać się na zasadzie, która nie istniała 2 lata temu, kiedy tworzony był budynek) i wszystko inne - obejmujący plan generalny musi się zmienić, czasem dość drastycznie.

Oprogramowanie jest bardzo podobne do tego; zawsze jest nieznana nieznana. Jednak, w przeciwieństwie do inżynierii lądowej i budowlanej, tworzenie oprogramowania jest z natury znacznie bardziej tolerancyjne wobec zmian w zależności od problemów, jakie stwarzają nieznane nieznane. Jeśli budujesz 10-piętrowy budynek i przeceniłeś nośność fundamentu, który postawiłeś w swoim projekcie, albo nie możesz zbudować budynku na 10 pięter, albo musisz wydrzeć znaczną ilość pracy, aby wróć do fundamentu i wzmocnij go lub odbuduj. Jednak w oprogramowaniu, jeśli nie doceniłeś wymagań dotyczących konkretnego poziomu ogólnej struktury rozwiązania, istnieje wiele opcji naprawienia tego poziomu, które nie wymagają unieważnienia całej pozostałej pracy. Możesz zastąpić pojedynczy serwer DB silniejszym serwerem lub klastrem replikacji / pracy awaryjnej, lub klaster równoważący obciążenie / rozproszony. To samo dotyczy serwera WWW. Jeśli kodujesz algorytm, który jest nieefektywny, ale prosty w oparciu o błędne założenia wielkości wejściowej, prawie zawsze możesz po prostu usunąć i przepisać implementację w stosunkowo chirurgiczny sposób, bez wpływu na inny kod, który ma wiedzę na temat algorytmu (wywołuje i przekazuje dane wejściowe do lub oczekuje od niego wyniku).

Ta względna łatwość zmian pozwala inżynierowi oprogramowania pisać na podstawie tego, co wie, bez niepotrzebnego martwienia się o to, czego nie wie. Pozwala to na luźniejsze zastosowanie teorii i wstępny projekt koncepcyjny; nurkujesz i załatwiasz to, a po drodze znajdujesz kodowane rzeczy, które należy zmienić i zmienić. Nadal musisz znać pojęcia i teorię, ponieważ gdy odkryjesz problem, są to rzeczy, które pomogą ci zidentyfikować przyczynę i stworzyć rozwiązanie. Ale możesz podjąć szybką decyzję bez ulegania „paraliżowi analizy”, ponieważ jeśli okaże się, że podjąłeś błędną decyzję na podstawie czegoś, czego nie wiedziałeś lub nie wziąłeś pod uwagę swoich „obliczeń”, błąd łatwiej naprawić.

Różnica wynika przede wszystkim ze znanych wymagań:

• Po stronie teorii wszystko jest zdefiniowane z góry, więc możesz dokładnie wiedzieć, czego potrzebujesz, zanim zaczniesz.
• W praktyce często ich nie ma lub odkrywasz coś w trakcie wdrażania, co powoduje, że musisz coś przeprojektować. O wiele lepiej jest skakać z co najmniej podstawowymi projektami, abyś mógł wcześnie odkryć te problemy.

Ponadto, gdy mówimy o „teorii”, zwykle oznacza to stronę informatyki zamiast inżynierii oprogramowania. Jest to część informatyki, która w dużej mierze polega na znalezieniu lepszych i bardziej wydajnych algorytmów, potwierdzających, czy coś jest możliwe (na przykład P i NP) i tak dalej. Chociaż dobrze jest mieć to w pamięci, nie pojawiają się one często przy tworzeniu oprogramowania.

Używamy bibliotek do tego typu rzeczy w jak największym stopniu.

W rzeczywistości istnieje kilka poziomów inżynierii oprogramowania, w zależności od tego, co tworzy oprogramowanie.

NASA potrzebuje oprogramowania do sterowania załogowymi promami w kosmosie, więc naturalnie poziom procesu inżynieryjnego jest znacznie bardziej rygorystyczny niż w przypadku budowy strony internetowej w celu pokazania zdjęć rakiet.

Jeden z moich współpracowników, który pracował dla NASA, wcześniej opisał swój proces inżynierii oprogramowania jako pisanie setek stron uzasadnienia i setek godzin spotkań w celu usprawiedliwienia napisania jednej linii kodu!

Nie zrozumcie mnie źle, bo nie mówię tego bez szacunku, kiedy to mówię, ale mimo tylu kosztów czasu, zasobów i miliardów dolarów prom kosmiczny wciąż wybuchł.

Nawet inżynierowie budownictwa wiedzą, że bez względu na to, ile teorii włożyli w projekt, coś w końcu to złamie, dlatego też muszą opracować plany awaryjne.

Podczas tworzenia oprogramowania jego awaria rzadko powoduje utratę życia, dlatego o wiele łatwiej jest szybko go wyrzucić i przetestować. Zgódźmy się, że szybkie wykonanie zadań powoduje słaby kod. Nawet jeśli tak jest zawsze, zobaczenie oprogramowania w akcji jest najlepszym sposobem dla dewelopera na sprawdzenie, gdzie jest ono słabe i wymaga wzmocnienia w porównaniu z tym, gdzie jest słabe i wciąż wiele razy silniejsze, niż musi nadążać ładunek.

Podsumowując, Premature optimization is the root of all evil jak zawsze mawiał mój szefShipping is a feature!

Wiele dobrych odpowiedzi tutaj, ale myślę, że porównanie między informatyką a inżynierią lądową jest wadliwe.

Ściśle mówiąc, to, co robią profesjonalni programiści, bardziej przypomina Inżynieria oprogramowania niż Informatyka. Lepszą analogią jest to, że informatyka jest fizyką inżynierii oprogramowania. Podobnie, Civil Engieering to zbiór uproszczeń i aproksymacji fizyki do praktycznego budowania.

Wyobrażam sobie, że inżynierowie rzadko muszą brać pod uwagę ogólną teorię względności podczas wykonywania swojej pracy. Wiele inżynierii lądowej można bezpiecznie zbudować w mechanice Newtona. Podobnie inżynieria oprogramowania może być osiągnięta bardzo skutecznie z mniej więcej przybliżonym zrozumieniem teoretycznej informatyki.

Duża różnica polega na tym, że mosty, drapacze chmur i inne produkty inżynierii lądowej są dość dobrze rozumianymi rzeczami. Inżynierowie oprogramowania często budują nowatorskie konstrukcje lub wykorzystują nowatorskie metody do budowania dobrze rozumianych rzeczy. Inżynieria oprogramowania jest o wiele mniej dojrzała niż inżynieria lądowa, i prawdopodobnie będzie to nadal obowiązywać w dającej się przewidzieć przyszłości.

TL; DR : Teoria i praktyka różnią się w inżynierii oprogramowania tak, jak wszędzie indziej. Właściwą analogią jest Inżynieria oprogramowania: Inżynieria lądowa :: Informatyka: Fizyka. Ale w praktyce jest to trochę bardziej skomplikowane :)

Moje pytanie brzmi więc, dlaczego niektórzy programiści uważają, że istnieje kontrast między teorią (metody formalne) a praktyką (wykonywanie zadań)?

Oprogramowanie do budowania nie przypomina budowania mostu. W oprogramowaniu jest wiele obiektów do zbudowania, które mogą, ale nie muszą być zdefiniowane na początku. Istnieją standardy, które zwiększają łatwość utrzymania i współpracy programistów, aby nie stosować się do arbitralnych wzorów matematycznych lub innych podobnych ideałów. Na przykład, wybierając zachowanie na podstawie zmiennej, czasem warto zastosować przełącznik, innym razem wzorzec fabryczny. Zależy to od łatwości konserwacji i zidentyfikowanych punktów bólowych, takich jak problemy z wydajnością.

Kolejnym przykładem może być manipulacja danymi. Często ma sens używanie delegatów w kontekście platformy .NET. W Javie nie jest to takie łatwe, ponieważ nie ma wsparcia dla funkcjonalnego stylu programowania .NET. Innymi słowy, w ogólnym przypadku po prostu nie jest możliwe wykonanie X w sytuacji Y. Wynika to z faktu, że X i Y zależą od N liczby czynników zmiennych.

Czy inżynieria oprogramowania (oprogramowanie budowlane) jest postrzegana przez wielu jako równie łatwa w porównaniu, powiedzmy, inżynieria lądowa (budowanie domów)?

Nie jestem pewien, czy „łatwe” jest właściwym terminem. Brak namacalnych dowodów może prowadzić do przekonania, że ​​nie wykonuje się żadnej pracy. Lub też, że istniejącą pracę można łatwo zmienić.

Czy te dwie dyscypliny są naprawdę różne (oprócz oprogramowania o kluczowym znaczeniu, awaria oprogramowania jest znacznie bardziej akceptowalna niż awaria budynku)?

Inżynieria tradycyjna i inżynieria oprogramowania są bardzo różne z powodów, które już wskazałem.

Twoja percepcja może być tutaj błędna lub zawiera wiele zasobów od ludzi, którzy nie napisali wystarczająco złożonego oprogramowania.

Twoje doświadczenie jest zgodne z tym, co powiedziałaby większość osób, które znam (którzy zaprojektowali i napisali wystarczająco złożone oprogramowanie).

To powiedziawszy, jeśli chodzi o większość programistów , kiedy zadanie pisania czegoś do nich dociera, projekt („matematyka” jak to ująłeś) został już wykonany przez architekta / lead / etc. zanim zadanie pisania dotrze do nich. Może się tak wydawać z poziomu linii frontu.

Myślę, że powodem tego kontrastu jest to, że cykl życia projektu oprogramowania i projektu sprzętu lub architektury jest inny. Większość oprogramowania ewoluuje stopniowo, nie jest planowane od początku do końca. Twórcy oprogramowania mogą stosować iteracyjne podejście do programowania: planuj, wdrażaj i słuchaj opinii. Jeśli opinie są pozytywne, nie przestawaj - cofnij się i ponownie rozważ swoją strategię. Właśnie dlatego programiści mają takie rzeczy, jak zwinne programowanie, minimalny opłacalny produkt i tak dalej.

Inżynierowie budowlani nie mają takiego luksusu. Dla nich, gdy coś jest planowane, nie można tego zmienić tak łatwo, jak w przypadku oprogramowania, ponieważ koszt takich zmian może być poważny. Z drugiej strony w przypadku tworzenia oprogramowania nie kosztuje to zbyt wiele i można to wykorzystać na ich korzyść.

Ale nie każda gałąź rozwoju oprogramowania może sobie pozwolić na takie podejście. Tworzenie oprogramowania, na przykład dla lotnictwa lub usług medycznych, wymaga bardzo starannego planowania i wielu wcześniejszych obliczeń.

Wydaje mi się to samo. Duży budynek budujesz ze standardowych bloków, betonu o standardowej wytrzymałości, stali standardowej. Budujesz dużą aplikację ze standardowych bibliotek.

Nie próbujesz matematycznie formalnie udowodnić, że duża aplikacja jest poprawna w taki sam sposób, w jaki nie próbujesz napisać funkcji falowej dla 100-piętrowego budynku

Byłem inżynierem mechanikiem i producentem, zanim około 20 lat temu odkryłem, że moje umiejętności dotyczą oprogramowania. Współczuję wielu elementom, które przedstawiliście.

Podejrzewam, że prawdziwa natura problemu polega na tym, w jaki sposób , załatwimy sprawę. Mamy teraz dziesięć lat zwinnego rozwoju pod naszymi wspólnymi paskami, a przesłanie jest jasne. Nie postępuj według warstw; postęp według funkcji. Jasne - pojawią się projekty, w których trzeba będzie przechodzić przez kolejne warstwy (np. Zbudować stos sieci przed serwerem WWW), ale w zdecydowanej większości rzeczywistych projektów nauczyliśmy się, jak dostarczać działające funkcje, jedną lub kilka w czas jest znacznie bardziej efektywny, budując ogromne niesprawdzone teorie, a następnie próbując je wdrożyć.

Weźmy więc twój przykład chaty (zazwyczaj mówię o zrobieniu mostu przez rzucanie kłody przez strumień w porównaniu do kilometrowego mostu wiszącego ... cokolwiek!) I przenieśmy go do świata inżynierii oprogramowania. Główną różnicą, którą widzę, jest to, że w oprogramowaniu większość pracy jest na taką skalę, że nie wymaga dużego modelowania z góry, aby odnieść sukces. Błędem początkującego jest często założenie, że rzeczy potrzebują więcej tego, niż w rzeczywistości, i dla większości z nas, popełniwszy ten błąd kilka razy, mamy dość powtarzania go zbyt często.

Bez argumentu - są projekty, które trzeba rozpocząć od komitetu złożonego z 17 architektów oprogramowania. W rzeczywistości są one tak rzadkie jak 20-karatowe diamenty.

Myślę, że analogia jest błędna. O ile mi wiadomo, inżynieria lądowa nie ma takich samych podstaw teoretycznych jak informatyka; informatyka zrodziła się z matematyki teoretycznej - jak maszyny Turinga. Inżynieria lądowa polega na tworzeniu struktur odpornych na matkę naturę, a może nawet wyglądać pięknie. Ponownie, naprawdę niewiele wiem o inżynierii lądowej, ale nie sądzę, żeby istniały odpowiedniki inżynierów budownictwa lądowego P kontra NP, podróżującego sprzedawcy i innych zabawnych rzeczy, przeciwko którym można się zmiażdżyć. Na pewno jest miejsce na naszą teorię informatyki - jeśli ktoś rozwiąże podróżnego sprzedawcę lub problem z zatrzymaniem, czeka nas wiele niesamowitych nowych osiągnięć. Ale dla inżyniera oprogramowania, który zajmuje się projektowaniem oprogramowania, takie problemy to tak naprawdę tylko zabawa i gry.

Myślę też, że zależy to od tego, co rozumiesz przez „teorię”. Czy mówimy o wzorach projektowych, czy pompujemy lemat? Ponieważ dobre zrozumienie wzorców projektowych jest absolutnie niezbędne, aby być dobrym inżynierem oprogramowania. Jednak przy projektowaniu dużego systemu oprogramowania teoretyzowanie problemów P / NP nie jest przydatne. W tym sensie uważam, że istnieje bardzo wyraźny kontrast między inżynierią oprogramowania a teoretyczną informatyką.

Czy teoria odnosi się do algorytmów? Nie spędzasz dużo czasu na pisaniu algorytmów czasowych, których nauczyłeś się w swojej klasie algorytmów. Dlaczego? Ponieważ zazwyczaj potrzebujesz ich tylko w określonych przypadkach (a następnie przeglądasz je i badasz) lub korzystasz z biblioteki już dla Ciebie napisanej. Nie trzeba pisać kolejnego klasyfikatora bayesowskiego. Abstrakcja jest ważną zasadą w informatyce. Myślę, że inżynierowie oprogramowania zwykle nie uczą się działania algorytmu, dopóki nie będą musieli.

Innym powodem jest to, że istnieje obecnie kilka popularnych, skutecznych metod tworzenia oprogramowania „zrób to”. Na przykład w zwinnym programowaniu nie należy wcześniej projektować całego systemu. Powodem tego jest to , że nie wiesz jeszcze dokładnie, co budujesz - chcesz, aby to, co robisz, było elastyczne i dostosowywało się do nowych informacji i wymagań. Zaprojektowanie tego od samego początku, a następnie zbudowanie tego, co nie zawsze daje najlepsze oprogramowanie. Jednak nie jest to rozwiązanie na wszystko. Załóżmy na przykład, że projektujesz coś szalonego-klaster rozproszony-klaster-nowy. Nie możesz wykonać szkiców na serwetki i rozpocząć SCRUM.

TL; DR. Myślę, że słowo „teoria” jest trochę niejednoznaczne. Tradycyjnie teoria odnosi się do teoretycznych matematycznych aspektów informatyki. O ile nie badasz nowszych sposobów obliczeń, w większości teoretyczne informatyka nie odgrywa żadnej roli w codziennym życiu inżyniera oprogramowania. Inżynierowie oprogramowania dbają o wzorce projektowe i architekturę systemu. Szczegółowe szczegóły implementacji niektórych algorytmów nie są ważne. Często przy mniej skomplikowanych pomysłach nie należy dużo projektować i po prostu zacząć kodować. I myślę, że stąd pomysł, że programiści nie lubią teorii.

Różnica między teorią a praktyką jest obecnie zbyt duża. Robiąc teorię, otrzymujesz trzy aksjomaty, a następnie pokazano, że twierdzenie o jednym wierszu ma dowód na tysiąc stron lub dowód w ogóle. W inżynierii oprogramowania otrzymujesz niespójne interfejsy API tysięcy funkcji, które dają ci mnóstwo (złych) sposobów implementacji nieokreślonej funkcji.

Prawdziwa inżynieria oprogramowania doprowadziłaby większość do szaleństwa w dziedzinie formalnej, a prawdziwe matematyczne tworzenie oprogramowania doprowadza do szaleństwa inżynierów. Oba pola wymagają ludzi o różnych umiejętnościach i nie sądzę, aby zdolności te często się nakładały.

Teoria formalna zakłada, że ​​można dokładnie zaplanować wszystko z wyprzedzeniem, tak jak wyprodukowany produkt, że oprogramowanie będzie istniało bez końca w tym samym środowisku, a rozwiązanie ogólnego abstrakcyjnego problemu jest zawsze celem. Zakłada cykl życia oprogramowania 4D jako produktu: projektowanie, opracowywanie, wdrażanie, gotowe. Teoria formalna polega na rozwiązaniu problemu projektowania oprogramowania przy użyciu analizy, abstrakcji, uogólnienia i przewidywania przyszłych zmian. Jest to dobre, jeśli masz dobrze zdefiniowany problem w prostej dziedzinie, który jest łatwo analizowalny, przewidywalny i dość statyczny.

Praktyczne programowanie polega teraz na właściwym rozwiązaniu właściwego problemu (nie projektowania oprogramowania), aby Twoi współpracownicy mogli wykonywać swoje zadania lepiej / szybciej / w ogóle, lub aby wpłynąć do firmy. Wiele programów nie jest jak produkt, nigdy „nie zrobiony”, ale bardziej jak żywa istota, która zaczyna się od wyspecjalizowania w jednej niszy ekologicznej i może mieć bardzo zmienną długość życia, podczas której musi rozwiązać nowe, nieprzewidziane problemy w szeroka gama stale zmieniających się środowisk. W świecie biznesu, przy polityce i legalnościach oraz konkurencji i ciągle zmieniających się organizacjach, strukturach i trendach, wymagania są często dwuznaczne, złożone ze wszelkiego rodzaju szczególnych przypadków, źle zdefiniowane i podlegające szybkim nieoczekiwanym zmianom. Nie są analizowalne, przewidywalne ani statyczne, i często nie logiczne lub uzasadnione. Oprogramowanie będzie równie mało istotne w ciągu 2 tygodni, jak nadal będzie używane przez 20 lat. Przychodzi na świat, nie wiedząc wiele ani nie będąc w stanie wiele zrobić, i musi być pielęgnowany, pielęgnowany i szkolony przez całe swoje życie, aby wyrósł na silnego, elastycznego i zdolnego do przystosowania się do ciągle zmieniającego się otoczenia i nowych problemów. Jeśli zaniedbujesz go po urodzeniu, stanie się dziki, jeśli przeżyje wystarczająco długo i spowoduje ból i cierpienie, rozwiązując problemy z tępą siłą.

Teoria formalna nie zaspokaja potrzeb większości rzeczywistego oprogramowania biznesowego. Podstępnie wierzy, że oprogramowanie można zaprojektować i wykonać. Że jest to produkt, który można od czasu do czasu naprawić, dopracować lub naprawić, ale nie jest to żywa rzecz, którą należy prawidłowo wychowywać z ciągłą troską i uwagą przez całe życie. W efekcie powstaje naprawdę brzydki, dziki kod, ale formalna teoria prawdopodobnie nie pomogłaby w tym.

To wszystko brzmi dość negatywnie, ale w rzeczywistości uwielbiam używać teorii formalnej. Piękny design zawsze wywołuje uśmiech na mojej twarzy. Jednak to głównie w moim hobbystycznym programowaniu, które nie podlega perypetiom biznesu. W pracy zajmuję się głównie kodem organicznym i mam tylko nadzieję, że poświęcę mu wystarczająco dużo uwagi, aby dobrze wyrósł, sprawił, że jestem dumny i nie byłem wstrętny i niegrzeczny wobec innych, którzy mają do czynienia z nim.

Stawki są niższe, praca jest łatwiejsza, a zarządzanie rzadko widzi wartość w dobrym projekcie. Niestabilność, łatwość konserwacji i integralność systemu to problem „informatyczny”, a nie „biznesowy”. Wszyscy dyrektorzy mają jedną wspólną cechę. Są w 95% nastawieni na pieniądze lub zgłaszają się do kogoś, kto jest.

Reszta bitwy jest z innymi programistami. Wielu z nich nie może lub nie chce myśleć o problemie przed rozpoczęciem kodowania. Z uwagi na powyższe spora część tych osób to starsi programiści, co jeszcze bardziej utrudnia wprowadzenie dobrego projektu do produkcji.

Patrzyłem, jak projekt prowadzi przez wiele lat, dodając funkcje i poprawki ad-hoc do projektów, które na początku były skaliste, a następnie zestrzeliwałem każdą próbę uporządkowania chaosu za pomocą zwrotów „zbyt skomplikowane” lub „marnowanie czasu”. Nie jest przyjemnie oglądać spiralę wielkiego projektu do jego nieuchronnego losu, ponieważ kierownictwo nie przyzna, że ​​codziennie buduje własne więzienie; obawiam się jednak, że jest to niefortunna rzeczywistość, której wielu deweloperów było świadkami i od których - na dobre i złe - nauczyło się.

W mojej pracy staram się znaleźć medium. Piszę nie więcej kodu w „skażone” projektów, niż jest to absolutnie konieczne, i wykorzystać każdą okazję, aby przenieść funkcjonalność z nich. „Pomiędzy projektami” spędzam czas na projektowaniu i porządkowaniu projektów, nad którymi faktycznie mam kontrolę.

Ostatecznie to wielki bałagan polityki i uczciwości osobistej, na który 75% programistów na świecie nie ma dość. Sam ledwo mogę to znieść.

Po pierwsze uwielbiam to pytanie. Napisałem około trzech 1000 słów i wszystkie były strasznie złe, zanim do nich dotarłem.

Problem z porównywaniem ich obu jako analogicznych, jak sądzę, polega na tym, że programowanie jest procesem modelowania, który może być tak abstrakcyjny lub ściśle związany z konkretem, jak chcesz.

Z drugiej strony teoria inżynierii budowlanej jest ściśle związana z bardzo specyficznymi zestawami praw opartych na rzeczywistości, z którymi musisz się dostosować. Nie możesz po prostu zmienić kontekstu ani przepisów. Sam problem jest zakorzeniony w tych prawach. Jednak w programowaniu czasami rozwiązanie faktycznie zmienia charakter pytania lub po prostu umieszcza je w innym kontekście.

Na przykład, czy wzór MVC jest idealnie dopasowany, ma wiele wspólnego z tym kontekstem. Aplikacja komputerowa zazwyczaj obsługuje tylko jeden język i tylko jeden język, nie licząc plików konfiguracyjnych.

Z drugiej strony interfejs aplikacji składa się głównie z dwóch deklaratywnych (nieprogramowych) języków i JavaScript. Jedyną rzeczą fizyczną, której nie można całkowicie oderwać od rzeczywistości, jest fakt, że zawsze istnieje ściana http, na której można przerzucić między serwerem a przeglądarką. Niezależnie od tego, jak zakopujesz go w kodzie, wymaga to czasu i projektowania asynchronicznego.

Oczywiście nie można używać popularnego i cenionego wzorca, takiego jak MVC, do rozwiązywania problemów związanych z interfejsem użytkownika wyłącznie w Internecie, bez zmiany sposobu obsługi go w kontekście aplikacji komputerowej. W rzeczywistości twierdzę, że powinieneś zdawać sobie sprawę z tego, co sprawia, że ​​MVC jest użyteczny, ale nawet nie próbuj wdrażać go w sposób szczególnie wymagający lub hurtowy. Paradygmat aplikacji internetowej jest wyjątkowy, ponieważ wszystkie rzeczy, na które patrzysz, są obsługiwane przez przeglądarkę użytkownika, a wszystkie dane / modele są zazwyczaj gdzieś na serwerze. Ale gdzie to pozostawia kontrolera? Wszystko na serwerze, czy na froncie? Ktoś musi to posiadać. A może MVC nie jest w 100% najlepszym rozwiązaniem dla tego scenariusza. Niezbyt dobrze pasuje do zaplecza .NET. Nie straszne w kontekście określonych widgetów interfejsu użytkownika.

Budowa domu rozwiązuje problem. Typowe problemy z programowaniem często obejmują jednak rozwiązywanie problemów w ramach problemów, a czasem rozwiązaniem jest przedefiniowanie problemu zewnętrznego. Niestety, rzeczywistość nie jest szczególnie zainteresowana tym pomysłem.

Glenn Vanderburg prezentuje wspaniały pogląd na różnice między inżynierią oprogramowania a bardziej tradycyjnymi dyscyplinami inżynierii: http://www.youtube.com/watch?v=NP9AIUT9nos

Gdyby inżynier budownictwa mógł przetestować swoje projekty bez żadnych kosztów przed zbudowaniem ostatecznej rzeczy, znacznie mniej wykorzystałby teorię. Jeśli w ciągu kilku sekund uda mu się zbudować most tysiąc razy za darmo, aby sprawdzić, kiedy się zepsuje, zrobiłby to zamiast spędzać miesiące na obliczaniu, kiedy teoretycznie może zahamować ...

W tworzeniu oprogramowania to właśnie robisz. Zamiast obliczać szybkość algorytmu w teorii, możesz go po prostu przetestować i poznać odpowiedź w ciągu kilku sekund.

W rzeczywistości większość dzisiejszych programów nie jest już ograniczona fizycznymi ograniczeniami, takimi jak moc obliczeniowa lub pamięć. Ograniczeniem oprogramowania jest złożoność, która występuje w coraz większych systemach. Zarządzanie tą złożonością poprzez utrzymywanie zrozumiałości systemu przez ludzi, co stanowi dziś ogromne wyzwanie w programowaniu.