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

63

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.

Giorgio
źródło
9
nie, 90% programistów to;)
jk.
24
Cóż, w oprogramowaniu możesz zacząć od budowy dachu, a następnie zejść do fundamentu, podczas gdy gotowe części unoszą się w powietrzu. Jeśli coś nie pasuje, możesz użyć taśmy izolacyjnej, aby dopasować. Spróbuj tego, budując wieżowiec. ;)
Zabezpiecz
65
W teorii nie ma różnicy między teorią a praktyką, ale w praktyce jest.
Joris Timmermans
6
Dobra książka do wyszukiwania alogrithms? Większość oprogramowania jest po prostu prostym CRUD bez niczego zbliżonego do tego, co jest zawarte w kursie lub książce z algorytmem.
Gilles
44
Teoria dotyczy współczesnych języków i algorytmów. Pierwszego dnia praktyka przychodzi do pracy, a jej zadaniem jest dodanie niewielkiej funkcji do oprogramowania Point of Sale działającego na kasie, która korzysta z oprogramowania, które zostało ręcznie przekonwertowane z BASIC na K&R C przez osoby, które nie znały C , przy użyciu błędnego kompilatora od dostawcy, który zbankrutował i oczekuje się, że funkcja ta będzie działać najpóźniej do piątku.
Gort the Robot

Odpowiedzi:

61

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.

Michael Borgwardt
źródło
1
Zgadzam się z tobą, że w inżynierii oprogramowania ważne jest, aby mieć odpowiednią ilość formalizmu. Zbyt wiele oznacza, że ​​nigdy nie możesz zacząć, a może kiedy się dowiesz, że popełniłeś błąd, jest już za późno. Za mało oznacza, że ​​możesz zrobić bałagan. Myślę, że masz bardzo mocny punkt, mówiąc, że produktywność i jakość są znacznie trudniejsze do zmierzenia w inżynierii oprogramowania niż w inżynierii lądowej.
Giorgio
2
„... podczas gdy w inżynierii oprogramowania nie ma równie silnej siły, aby zachować niepraktyczność ...” Myślę, że masz na myśli, że takiej siły już nie ma . W przeszłości ograniczenia wynikające ze słabszych procesorów, mniejszej pamięci i małej ilości pamięci / brak pamięci działały jako taka siła.
blesh
1
@ Rozwiązywanie problemów: Nie sądzę. Surowe ograniczenia sprzętowe ograniczają zarówno dobrą, jak i złą inżynierię.
Michael Borgwardt
Twoje przykłady nie są teorią programowania. Ograniczenia w oprogramowaniu dotyczą wykorzystywanych technologii i zdolności matematycznych pisarzy.
Paul Nathan
5
Jest coś zdecydowanie „teoretycznego” w UML ... ... jego użyteczności!
ObscureRobot
29

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.

Kevin Cline
źródło
1
Zgadzam się z twoimi spostrzeżeniami, że czynnik ludzki jest znacznie silniejszy w oprogramowaniu, ale myślę, że próba analizy problemu lub struktury rozwiązania jest ogólną postawą / narzędziem. Moje pytanie brzmi: dlaczego niektórzy programiści uważają, że nie jest to użyteczne podejście (ani nawet strata czasu). Wspomniałeś o Haskell: starałem się nauczyć Haskella, chociaż nie użyłem go w żadnym projekcie, ponieważ myślałem, że pomogłoby mi to napisać lepszy kod (nawet w C ++ lub Javie). Nawet jeśli nie jestem w stanie tego zmierzyć, mam wrażenie, że stałem się bardziej produktywny: robię więcej rzeczy.
Giorgio
2
Trzy-liniowy szybkiort Haskell? Hmm ... Czy to w ogóle możliwe do wdrożenia Quicksort w języku, w którym wszystko jest niezmienna przez projekt?
Mason Wheeler
3
@MasonWheeler Pierwszy wynik od Google: Quicksort w Haskell .
chrisaycock
3
@Mason: środowisko wykonawcze wciąż ma wartość O (n log n). Wymaga także pamięci O (n log n), w przeciwieństwie do szybkiego sortowania w miejscu, który wymaga tylko dodatkowej pamięci O (log n) do rekurencji.
kevin cline
2
@kevincline W zakresie, w jakim typowy projekt oprogramowania jest wyjątkowy, rozpocząłem unikalny projekt przebudowy mojej łazienki. Różnica polega na tym, że jeśli spieprzę kod, moje testy staną się czerwone, a jeśli popsuję okablowanie, mój dom spłonie. Oczywiście ten projekt był również nadgodzinowy i przekraczał budżet, ponieważ nie mam doświadczenia w rozwiązywaniu problemów związanych z przebudową. Główny problem, który widziałem w projektach oprogramowania, jest podobny ... to nie jest tak, że właściwi ludzie nie mogli szybciej rozwiązać tych problemów, to, że właściwi ludzie nie są dostępni i musimy stać się właściwymi ludźmi na latać.
philosodad
17

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.

Mike Dunlavey
źródło
5
Fizyka może powiedzieć, czy jakaś struktura zawali się pod własnym obciążeniem. CS mówi ci, że nie możesz powiedzieć, czy dany program się zatrzyma, biorąc pod uwagę określone dane wejściowe. Metody formalne IMO skalują się znacznie lepiej w inżynierii lądowej lub mechanicznej niż w oprogramowaniu, głównie dlatego, że systemy są mniej złożone i mniej dynamiczne ...
Guy Sirton
6
@GuySirton „CS mówi ci, że nie możesz powiedzieć, czy dany program się zatrzyma, biorąc pod uwagę określone dane wejściowe.” jeśli to wszystko, co myślisz, CS, myślę, że możesz nie wiedzieć tyle o CS, co myślisz ...
gregghz
2
To nieprawdopodobne, żebyś kiedykolwiek używał materiałów, których nikt wcześniej nie używał. McCarthy zrobił to samo, co Turing, ale tak naprawdę inżynieria oprogramowania nie jest aż tak niesamowita. Gdyby to było w porządku, że budynek opadł na dno oceanu, bo może po prostu ponownie uruchomić go, że będzie jak inżynierii oprogramowania.
philosodad
3
Dałbym ci +1, z wyjątkiem pęknięcia dotyczącego czytelności. Utrzymywalność wynosi 80% kosztów oprogramowania, więc czytelność nie jest niewielką sprawą. Ponadto, gdy inżynier lotniczy lub nuklearny tworzy coś, co zostanie wyprodukowane, aby inni ludzie zrozumieli, że jest to ważne. Wojsko, rząd, a nawet duże instytucje nie są zadowolone z magicznego wynalazku, którego nie może powielić ani zrozumieć nikt inny niż wynalazca.
Thomas
2
@Thomas - Twierdzenie, że realne rozwiązania są często odrzucane przy zmianie „czytelności”, według podświadomości, niekoniecznie oznacza, że ​​rozwiązania nie są tak czytelne, jak powinny. Widziałem jak to się dzieje. Do diabła, przyłapałem się na robieniu tego.
Erik Reppen
13

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ć.

CaffGeek
źródło
Cóż, masz nadzieję, że nie umrą ... zależy od twojego oprogramowania;)
Rig
3
@Rig, dlatego powiedziałem „większość” i „zwykle”. Niektóre programy są znacznie bardziej krytyczne.
CaffGeek
Myślę, że staje się to coraz bardziej złym punktem widzenia, na pewno większość oprogramowania nie ma wpływu na bezpieczeństwo, ale wiele oprogramowania wiąże się z pieniędzmi i prywatnością, a popełnienie błędu może również doprowadzić cię do sądu
jk.
11

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! :)

FishBasketGordo
źródło
3
Jeśli musisz to raz zrobić i zapomnieć o tym, jest w porządku. Ale jeśli musisz go później przedłużyć i utrzymać, szukasz kłopotów. Musisz wyczuć, ile teorii: zbyt wiele oznacza, że ​​nigdy tego nie zrobisz, a zbyt mało oznacza, że ​​zrobisz to 10 razy, zanim to się naprawdę skończy. Moje 2 centy.
Giorgio
6
Ale czasami musisz wyciągnąć oprogramowanie TERAZ . Musisz pokonać konkurenta na rynku. Lub masz prawny wymóg podania pewnych informacji. Lub po prostu potrzebujesz przepływu gotówki, abyś nadal istniał, gdy bałagan, który popełniłeś w podejściu „zrób to”, jest problemem ... co czasami jest dobrym problemem. Ponieważ jeśli go nie masz, nie wypuszczasz go na czas, a twoja firma nie żyje, zanim się zacznie.
CaffGeek
1
@Chad - zgadzam się z tobą. To jest równowaga. Wszystkie rzeczy, o których wspominasz, podlegałyby „prawdziwemu ograniczeniu czasowemu” jako przyczynie programowania, a w perspektywie krótkoterminowej jest to w porządku, a nawet korzystne, gdy chcesz to zrobić.
FishBasketGordo
@FBG: Wspaniale powiedziane.
Kuba Ober
@Chad, dobra uwaga. Martin Fowler ma podobne zdanie na stronie martinfowler.com/bliki/TechnicalDebt.html . Czasami jest to opłacalne.
John M Gant
9

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ą.

James James McLeod
źródło
„przychodzi moment na rozwój oprogramowania, w którym koszty projektowania przekraczają wartość zwróconą.”: Wyraźnie napisałem „odpowiednią ilość teorii”. Wiem, że nadmiar inżynierii nie zwiększa wydajności.
Giorgio
Istnieje prawie zero projektów IMO zaprojektowanych z góry, które faktycznie odpowiadają ich projektowi. Inżynieria lądowa (ogólnie?) Buduje to samo w kółko (droga, cholera, tunel, budynek, most). Techniki są dobrze znane. Nie dotyczy to oprogramowania. Ponieważ można to łatwo zmienić i dlatego, że ludzie nie wiedzą, czego chcą lub co działa, dopóki nie wypróbują tego na poważnie, to strata czasu. Budujemy, testujemy i iterujemy. Coś, co jest niemożliwe w inżynierii lądowej, jak wskazano powyżej. Te dwie dyscypliny nie są porównywalne.
gman
5
Przepraszam, muszę zwrócić uwagę na literówkę: nie sądzę, żeby inżynierowie budowali coś cholernego. ;-)
Giorgio
2
Wyobrażam sobie, że w przyszłości, kiedy my inżynierowie oprogramowania, budujemy fajne oprogramowanie do symulacji inżynierii lądowej, inżynierowie mogą porzucić wszystkie te matematyczne rzeczy. Wystarczy zbudować wirtualny wieżowiec o wysokości 10 km. Jeśli nie upadnie pod własnym ciężarem w ciągu pierwszych 100 wirtualnych lat i jest w stanie wytrzymać wirtualny huragan kota 5, to użyj specjalnej drukarki wieżowca 3D, aby go zbudować.
emory
1
@ RexKerr: porąbałeś połowę jego wypowiedzi: „... która spełnia wymagane normy bezpieczeństwa”
Lie Ryan
7

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.

Onorio Catenacci
źródło
6

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ć.

KeithS
źródło
3
Istnieje również wiele innych nieznanych niewiadomych w tworzeniu oprogramowania - możesz zacząć budować drapacz chmur, ale kiedy klient na to spojrzy, powie ci „właściwie chciałem dziesięciopiętrową kostkę Rubixa”.
Tacroy
@Tacroy: Co ciekawe, inżynier lądowy prawdopodobnie uznałby tego za złego klienta, który marnuje czas i zasoby, inżynier oprogramowania spróbuje opracować nową metodologię, aby go zadowolić. :-)
Giorgio
1
@Giorgio, lub odpowiednio wystawić rachunek ...
CaffGeek
5

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.

Izkata
źródło
1
+1 dla „gdy mówimy o„ teorii ”, zwykle oznacza to stronę teoretyczną informatyki”.
Joshua Drake
5

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!

Albert Lang
źródło
3
+1 dla „Wysyłka jest funkcją”! Kiedyś usłyszałem podobne zdanie: „Doskonałość nie istnieje. To oprogramowanie ma tę zaletę, że istnieje”. Oczywiście to trochę żart. Jeśli chodzi o oprogramowanie o znaczeniu krytycznym: nieprzechwycony wyjątek może spowodować awarię rakiety.
Giorgio
this software has the advantage that it exists... jeszcze tego nie słyszałem, ale trafia na moją listę świetnych ofert oprogramowania. podoba mi się
Albert Lang
@Giorgio: JSF i MISRA C są napisane, aby nie było wyjątków. Wyjątki i rakiety się nie mieszają.
Koder
5

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 :)

ObscureRobot
źródło
„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 newtonowskiej.”: O ile wiem, muszą używać dość dużo rachunku różniczkowego (całki i podobne rzeczy). To nie jest mechanika kwantowa, ale IMO jest zdecydowanie nietrywialne.
Giorgio
2
Jasne, ale nie musisz wyprowadzać równania falowego dla każdego elementu mostu, a następnie wyjaśniać, w jaki sposób oddziałują.
ObscureRobot
Masz rację. Nie chodzi mi jednak o to, ile teorii wykorzystuje się w inżynierii lądowej i inżynierii oprogramowania. Inżynierowie budowlani wiedzą raczej, że muszą użyć swoich formuł i wykonać obliczenia dotyczące sposobu budowy niektórych budynków. W inżynierii oprogramowania mam wrażenie, że jest więcej improwizacji i czasami, jeśli chcesz usiąść i przeanalizować problem (tylko po to, aby go naprawić, nie pisać o nim pracy doktorskiej), możesz być zaskoczony: chcemy go zdobyć skończone, żeby nie było idealnie. Ale IMO trochę teorii (nie za dużo) jest dokładnie tym, co może pomóc w jej szybszym zakończeniu!
Giorgio
Musisz znaleźć punkt równowagi odpowiedni dla twojego projektu. Młodsi programiści są zwykle bardziej roztropni w rzucaniu bzdurami, aby zobaczyć, co się trzyma. Jeśli wywodzą się z bardzo teoretycznego tła, mogą nawet mieć bardziej szalone i nadmiernie złożone pomysły. Skuteczne zarządzanie młodszymi programistami często polega na pomaganiu im w cofnięciu się o krok i analizowaniu ich pracy. Z drugiej strony, starsi programiści mogą być zbyt skoncentrowani na długoterminowych problemach projektowych do tego stopnia, że ​​mają problemy z koncentracją na pilnych potrzebach.
ObscureRobot
Wow, przepraszam, to nie jest temat, ale bez przeczytania twojej odpowiedzi skończyłem dokładnie tak samo - z TL; DR, a następnie dosłownie tą samą analogią. Format SAT. Zedytowałem to z mojej odpowiedzi, więc nie wygląda na to, że cię kopiuję, ale wciąż mnie przeraża. Może programiści myślą zbyt podobnie.
Jarsen
3

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.

rev. P.Brian.Mackey
źródło
1

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.

Steven Evers
źródło
3
„matematyka ... została już wykonana”: nie tylko rozważ wszystkie funkcje biblioteczne, frameworki, DBMS, protokoły i mnóstwo innych ciężkich rzeczy, których możemy po prostu użyć w naszym kodzie, wywołując funkcję z pewnymi parametrami. Jako programista czasami czuję się bardziej jak pracownik, który chodzi po rusztowaniu, niż jako inżynier, który zaprojektował budynek.
Giorgio
1

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ń.

gwiazda gwiazd
źródło
1

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

Martin Beckett
źródło
Jaki jest więc programowy odpowiednik analizy metodą elementów skończonych 100-piętrowego budynku? Ile wysokich budynków ma błędy w termice / katastrofie? :-)
Guy Sirton
@GuySirton - możesz analizować tylko duży budynek na bardzo grubym poziomie, mniej szczegółów niż w przypadku testowania jednostkowego typowej aplikacji. Wiele dużych budynków ma awarie, wypadają okna, zapadają się chodniki, tworzą efekt tunelu aerodynamicznego. Lub w przypadku jednego zakrzywionego, wysoce odblaskowego hotelu w Vegas, tworzysz promień śmierci w basenie!
Martin Beckett
Możesz przejść bardzo drobnoziarnisty w MES i przewidywać zachowanie z bardzo dużą dokładnością. Ludzie wciąż popełniają błędy. IMO po prostu nie jest w stanie dokonać podobnych prognoz na złożonym oprogramowaniu. Wspomniane wady to niewielki ułamek całkowitej liczby budynków. Wskaźniki defektów w oprogramowaniu muszą być o dwa rzędy wielkości wyższe. To powiedziawszy, jest to oczywiście kontinuum między tym, gdzie metody formalne są przydatne, a tymi, które są bezużyteczne.
Guy Sirton
@ GuySirton - Myślę, że trudność polega na tym, że polegasz na innych rzeczach. Nasa może testować awionikę lotu na bardzo szczegółowym poziomie (choć nadal nie jest to poprawne), ponieważ tworzą one także system operacyjny i sprzęt. Pisanie na ogólnym systemie operacyjnym z zestawami narzędzi i bibliotek jest jak budowanie mostu, w którym nie wolno znać szczegółów stali lub betonu.
Martin Beckett
1
@MartinBeckett, a współczynnik grawitacji zmienia się losowo z godziny na godzinę ... tak jak wtedy, gdy administrator systemu losowo decyduje się na aktualizację serwera bez mówienia nikomu, ponieważ „będzie przezroczysty”.
CaffGeek
1

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.

Dominic Cronin
źródło
1

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.

Jarsen
źródło
1
Widzę pewne podobieństwa między naszymi odpowiedziami, ale twoje pomysły są oczywiście oryginalne i istnieją pewne różnice. Nie zgadzam się, że zrozumienie P / NP nie jest przydatne. Nie musisz dogłębnie studiować teorii złożoności, ale działający inżynier oprogramowania powinien być w stanie oszacować O (n) dowolnego fragmentu kodu i powiedzieć inteligentne rzeczy na temat kosztów alternatywnych rozwiązań. Rzecz, o której prawie mówiłeś, ale tego nie robiłeś, to fakt, że teoria często jest zamknięta w bibliotekach. To jest dobre do rozważenia.
ObscureRobot
„Jeśli ktoś rozwiązuje ... problem zatrzymania, mamy do czynienia z wieloma niesamowitymi nowymi postępami.”: Cóż, niestety teoria udowodniła, że ​​jest to nierozwiązywalne (nie ma programu, który mógłby to rozstrzygnąć), więc nie sądzę, aby wysiłki badawcze są podejmowane w celu rozwiązania problemu zatrzymania.
Giorgio
Maszyny Turinga nie mogą ”Jednak nie wszystkie maszyny wyobrażalne ludzkim wyobrażeniom podlegają tezie Kościoła-Turinga ... Pytanie jest otwarte, czy mogą istnieć rzeczywiste deterministyczne procesy fizyczne, które na dłuższą metę wymykają się symulacji Maszyna Turinga, a w szczególności, czy jakikolwiek taki hipotetyczny proces mógłby być użytecznie wykorzystany w postaci maszyny liczącej (hiperkomputera), która mogłaby rozwiązać problem zatrzymania ... Jest również otwarte pytanie, czy w takie nieznane procesy fizyczne są zaangażowane działanie ludzkiego mózgu ... ”-Halting Problem, Wikipedia
Jarsen
Tak więc, o ile mi wiadomo, poprawcie mnie, jeśli się mylę, myślę, że nadal mamy wiele do odkrycia w zakresie obliczeń. Jak wielokrotnie wspomniano w tym wątku, informatyka jest wciąż bardzo młoda; może istnieć znacznie więcej niż Turning Machines i architektura von Neumanna.
Jarsen
@Jarsen: To prawda, że ​​informatyka jest bardzo młoda, ale każdy komputer, który został zbudowany do tej pory, może wykonywać tylko obliczenia Turinga. O ile mi wiadomo (naprawdę niewiele), nawet komputery kwantowe nie mogą zrobić więcej (mogłyby rozwiązać niektóre problemy szybciej, ale nie byłyby w stanie rozwiązać więcej problemów). Tak więc, kto wie, co można wymyślić, ale każdy formalizm komputerowy, który został wymyślony w ciągu ostatnich 70 lat, nie może zrobić więcej niż maszyna Turinga.
Giorgio
1

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.

Marco Devillers
źródło
0

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.

Promień
źródło
0

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ść.

Daniel
źródło
0

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.

Erik Reppen
źródło
0

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.

mirkok
źródło