Czy metody rozwoju powinny zmiażdżyć indywidualizm dewelopera?

9

Jestem na ostatnim semestrze studiów i biorę kurs inżynierii oprogramowania. W klasie uczymy się o różnych metodach tworzenia oprogramowania. Tym, na którym skupiliśmy się i przy którym opracowaliśmy nasz projekt, była metoda wodospadu.

Wydaje mi się, że instruktor mógł źle go zaimplementować. Na naszych diagramach klas musieliśmy wymienić WSZYSTKIE właściwości i metody, w tym prywatne. Przeczytałem kilka książek, a mianowicie Clean Code, które mówią o tym, aby funkcje były możliwie krótkie i skoncentrowane. Wymienienie każdej najmniejszej funkcji na naszych diagramach wydaje się żmudne, jeśli nie pomaga innym programistom (są prywatne, nikt ich nie użyje). Dodatkowo, mogę nie myśleć o każdej drobnej funkcji podczas projektowania programu, mogą pojawić się podczas refaktoryzacji.

Czy instruktor powiedział nam źle, prosząc nas o listę wszystkich funkcji? I czy te metody projektowania niszczą indywidualizm programisty, aby napisać kod, jak najlepiej to rozumieją?

David Peterman
źródło
20
Szkoda, że ​​twoja klasa uczy metody Waterfall, która jest kanonicznym przykładem złych procesów tworzenia oprogramowania.
whatsisname
6
Powiedziałbym, że ta klasa wiele cię nauczyła.
JeffO,
7
W rzeczywistości oryginalny wodospad ma iteracje, które łączą się ze sobą. Niepoprawne nauczanie Wodospadu przez lata zniszczyło jego przydatność. Nawet w przypadku czegoś takiego jak Scrum kroki, przez które przechodzi historia w sprincie, naśladują wodospad. Diagramy UML są przydatne tylko przy projektowaniu na wysokim poziomie. Jak tylko kod zostanie napisany, wszelkie dokumenty napisane przed tym kodem są teraz nieaktualne. To jest realizacja inżynierii. Ostatecznie kod musi być dokumentacją.
Andrew T Finnell,
10
Prawie każdy programista widział przypadki indywidualizmu dewelopera, które powinny zostać zmiażdżone. (Chociaż prawdopodobnie nie metodologią wodospadu).
psr
2
@whatsisname, zdecydowanie się nie zgadzam. Każdy programista powinien nauczyć się programowania Waterfall, aby ROZUMIEĆ i DOŚWIADCZYĆ go jako kanonicznego przykładu złego oprogramowania. Co więcej, wiele sklepów jest nadal wodospadem za dobre lub złe i ważne jest, aby grads byli na to przygotowani.
wałek klonowy

Odpowiedzi:

10

Czy zapytałeś instruktora, dlaczego musiałeś wymienić wszystkie metody?

Możliwe jest, że podobnie jak w przypadku większości wymagań w środowisku klasowym, nie chodziło o to, aby diagramy klas były bardziej pomocne dla programistów, ale by pomóc tobie i kolegom z klasy zastanowić się, jak zaprojektować klasy. Gdy uczniowie uczą się, jak rozkładać większe problemy na mniejsze, prawdopodobnie warto zastanowić się, jakich prywatnych metod prawdopodobnie potrzebowaliby. I prawdopodobnie instruktor może lepiej zrozumieć, jakie metody uczniowie myślą o wdrożeniu, aby interweniować wcześniej, jeśli projekt kogoś jest źle przemyślany. Dokumentacja w środowisku klasowym jest często znacznie bardziej zaangażowana niż dokumentacja w środowisku rzeczywistym, ponieważ instruktor „

Oczywiście możliwe jest również, że instruktor uważa, że ​​ten poziom dokumentacji jest pomocny w prawdziwym projekcie. W takim przypadku instruktor jest prawdopodobnie nieaktualny lub pochodzi z określonego niszowego środowiska, w którym ten poziom planowania i dokumentacji jest odpowiedni. Jeśli budujesz na przykład system nawigacji dla promu kosmicznego lub projektujesz urządzenia medyczne, na ogół bardziej odpowiednie jest zainwestowanie dużych środków w projektowanie z wyprzedzeniem niż ponowne kodowanie kodu podczas programowania. Z drugiej strony, jeśli tworzysz serwis społecznościowy, bardziej zwinne podejście jest bardziej odpowiednie.

Justin Cave
źródło
+1 za wskazanie, jak potrzebny jest inny projekt do różnych celów. Dobre punkty na temat projektowania klas;
Ethel Evans,
1
Zapamiętaj zasadę zaliczania kursu: Dowiedz się, czego chce profesor, i zapewnij to.
Christopher Mahan
9

Nie, instruktor ma rację, mówiąc, że musisz wymienić wszystkie właściwości i metody z góry, jeśli używasz metody wodospadu. Wikipedia odnotowuje krytykę wodospadu:

Wielu twierdzi, że model wodospadu jest złym pomysłem w praktyce - uważając, że żaden nietrywialny projekt nie może idealnie zakończyć fazy cyklu życia oprogramowania przed przejściem do następnych faz i wyciąganiem z nich wniosków. Na przykład klienci mogą nie wiedzieć dokładnie, jakich wymagań potrzebują, zanim przejrzą działający prototyp i skomentują go. Mogą stale zmieniać swoje wymagania. Projektanci i programiści mogą mieć niewielką kontrolę nad tym. Jeśli klienci zmienią swoje wymagania po sfinalizowaniu projektu, projekt należy zmodyfikować, aby uwzględnić nowe wymagania. Oznacza to skutecznie unieważnienie dużej liczby godzin pracy, co oznacza wzrost kosztów, zwłaszcza jeśli duża część zasobów projektu została już zainwestowana w Big Design Up Front.

Te metody projektowania nie zmiażdżą realizatora indywidualizmu projektu, ponieważ wciąż istnieją elementy do interpretacji i sposoby na nadanie niepowtarzalnego charakteru strukturze, np. Zdjęcie z szkieletem i dodanie mięśni i innych tkanek w celu stworzenia zwierzęcia, zastanawiającego się, ile wolność, czy musiałeś zaprojektować to zwierzę?

Znalazłeś wadę wodospadu tak, ale wszystko ma swoje mocne i słabe strony.

JB King
źródło
4

W klasie uczymy się o różnych metodach tworzenia oprogramowania. Tym, na którym skupiliśmy się i przy którym opracowaliśmy nasz projekt, była metoda wodospadu.

Prawdopodobnie nauczyłeś się klasycznego modelu wodospadu, który osoba przypisywana wprowadzeniu go do świata tworzenia oprogramowania stwierdził od samego początku, że jest nieodpowiedni do tworzenia systemów oprogramowania na dużą skalę. Prawdopodobnie byłbyś zainteresowany przeczytaniem artykułu Winstona Royce'a pt. Zarządzanie rozwojem dużych systemów oprogramowania, aby dowiedzieć się więcej o problemach z tym, co wiele osób uważa za model wodospadu.

Model Waterfall jest jednak dobry do nauczania cyklu życia oprogramowania w trakcie jego trwania i może poświęcić czas na naukę i wykonywanie inżynierii wymagań, projektowania architektonicznego, szczegółowego projektowania, wdrażania, testowania i konserwacji w bardzo wyraźnych, wyraźnych fazach.

Na naszych diagramach klas musieliśmy wymienić WSZYSTKIE właściwości i metody, w tym prywatne. Przeczytałem kilka książek, a mianowicie Clean Code, które mówią o tym, aby funkcje były możliwie krótkie i skoncentrowane. Wymienienie każdej najmniejszej funkcji na naszych diagramach wydaje się żmudne, jeśli nie pomaga innym programistom (są prywatne, nikt ich nie użyje). Dodatkowo, mogę nie myśleć o każdej drobnej funkcji podczas projektowania programu, mogą pojawić się podczas refaktoryzacji.

To są bardzo ważne punkty.

Wymienienie wszystkich właściwości i metod w fazie projektowania, nawet podczas korzystania z Wodospadu, jest prawdopodobnie przesadą. Zdecydowanie powinieneś wymienić wszystko, co publiczne, wraz z istotnymi właściwościami. W rzeczywistości wszystko inne jest szczegółem implementacji, który można uzyskać, przekształcając implementację w diagramy.

Rada Clean Code (nigdy jej nie czytałem - po prostu przechodzę do tego, co napisałeś) wydaje się być sprawiedliwa i ma zastosowanie nawet przy zastosowaniu metodologii Waterfall. Możesz zaprojektować swoje klasy i metody zgodnie z Zasadą Pojedynczej Odpowiedzialności , oddzieleniem problemów i innymi zasadami SOLID . Waterfall nie mówi ci, jak projektować, tylko kiedy musisz to zrobić. To powiedziawszy, jest trudniej z góry, gdy uczysz się i wymyślisz lepsze sposoby na zrobienie tego podczas wdrażania.

Myślę, że to wskazuje na fakt, że trzeba bardzo wyraźnie powtarzać projekt i wdrożenie - problem, którego nie uwzględnia tradycyjny wodospad.

Thomas Owens
źródło
1
@pillmuncher Tak mało osób to przeczytało, to trochę smutne.
Thomas Owens
3
Najsmutniejsze w tym papierze jest to, że większość ludzi faktycznie odkryło przez niego wodospad, podczas gdy jest to papier, który całkowicie dyskredytuje tę praktykę.
Joeri Sebrechts,
3

Wymienienie każdej najmniejszej funkcji na naszych diagramach wydaje się żmudne, jeśli nie pomaga innym programistom (są prywatne, nikt ich nie użyje).

Jeśli uważasz, że jest to uciążliwe, poczekaj, aż dostaniesz prawdziwe programowanie pracy. Zastanów się przez chwilę, że oprogramowanie może nie być dla ciebie opłacalne.

Dodatkowo, mogę nie myśleć o każdej drobnej funkcji podczas projektowania programu, mogą pojawić się podczas refaktoryzacji.

Więc?

czy instruktor powiedział nam źle, prosząc nas o listę wszystkich funkcji?

Nie. To powszechny wymóg.

I czy te metody projektowania zmiażdżą realizatora indywidualizmu projektu (dewelopera), aby napisać kod, jak najlepiej to rozumieją?

Tak. Kruszenie duszy jednostek jest ważną częścią rozwoju oprogramowania. Wszelka indywidualność zostanie usunięta ze wszystkich programistów przez cały czas na wszystkie możliwe sposoby. Mówi, że gdzieś w „Bożych regułach programowania” przekazano z jakiejś góry na jakiegoś proroka.

Nie. Po prostu wzdrygasz się w nudach. Pokonaj go i wróć do pracy.

S.Lott
źródło
1
@FreshDaddy. „Oni (w przeważającej części) nigdy nie zobaczą funkcji prywatnych”. Fałszywe. Po wygranej w loterii inni programiści przejmą Twój kod i zobaczą prywatne funkcje. Również. Niektóre języki (np. Python) unikają tego rodzaju prywatności.
S.Lott,
2
@ S.Lott - Wymienienie każdej funkcji prywatnej wcale nie jest powszechnym wymogiem. Zdarza się, nie zrozumcie mnie źle, ale pełna lista „wypisz każdą funkcję prywatną przed napisaniem kodu” jest z pewnością dość rzadka. Jest „niezbędny Tedius”, a następnie „bezwartościowy Tedius”. Biorąc pod uwagę, że programiści zajmują się eliminowaniem „bezwartościowego tediusa”, klienci ze świata rzeczywistego prawie nigdy nie zażądaliby czegoś tak kosztownego i bezcelowego, chyba że byłby to kod typu „życie lub śmierć”.
Morgan Herlocker,
1
@ironcode: „„ wypisz każdą funkcję prywatną przed napisaniem kodu ”jest z pewnością dość rzadkie.” Nie z mojego doświadczenia. W ten sposób ludzie uczą się projektowania. Młodsi programiści często trzymają się tego standardu, dopóki nie udowodnią, że ich praca nie wymaga takiego poziomu nadzoru. Generalnie krócej niż rok. Organizacja, która wzięła n00bs ze szkoły i rzuciła nimi w programowanie bez nadzoru, w większości powoduje ogromne problemy. Ten poziom nadzoru jest niezbędny, aby mieć pewność, że kod ma szansę na działanie.
S.Lott,
1
@S Lott - moje motto brzmi: jeśli tworzenie oprogramowania jest uciążliwe, robisz to źle. Jesteśmy programistami. Automatyzujemy nudę. Nie powtarzamy się w kodzie i nie ma powodu, aby powtarzać się w dokumentacji.
kevin cline
1
@kevin: ta odpowiedź to czysty sarkazm. Jako taki jest całkowicie nieodpowiedni i zgłosiłem to.
Michael Borgwardt,
1

Programowanie to sztuka pracy w ramach ograniczeń. CPU zapewnia ograniczony zestaw instrukcji; IO jest ograniczone przez konstrukcję sprzętu; Interfejsy API systemu operacyjnego są tworzone w celu zachęcania do niektórych zachowań i ograniczania innych; języki wysokiego poziomu są często zaprojektowane tak, aby promować jeden zestaw idiomów nad innymi ...

Metodologie są również tworzone w celu ograniczenia.

Twoim wyzwaniem we wszystkich aspektach procesu rozwoju jest realizacja swojej wizji w ramach tych ograniczeń. Czy uderzysz głową w każdą ścianę rzuconą przez sprzęt, język, API i metodologię? Czy znajdziesz sposób na zharmonizowanie tego, co chcesz osiągnąć, z tym, co jest dozwolone i zachęcane?

Czy naprawdę uważasz, że twój instruktor chce czytać niekończące się strony drobiazgów? Następnie przetestuj tę teorię: podziel program i udokumentuj każdy atom. Kiedy jego biurko ugina się pod ciężarem, raczej podejrzewam, że przekonasz się, że jego prawdziwe pragnienie różni się nieco od tego, czego oczekujesz.

Lub przygotować dokumentację jak ty patrz dopasowanie. Wyjaśnij to, zrozum, uczyń jak powieść Dashiella Hammetta. A potem usiądź i porozmawiaj z nim, pokaż mu, co zrobiłeś, przekonaj go o jego zaletach.

Shog9
źródło
1

Myślę, że instruktor jest genialny w zmuszaniu cię do zrobienia tego projektu, a tym samym nauczy cię zalet i (głównie) wad rozwoju Waterfall.

afeygin
źródło
1

Prostą regułą do oceny złożoności analizy projektu jest: „Czy deweloper lub firma, dla której pracuje, może zostać pociągnięta do odpowiedzialności za coś dramatycznego (w tym śmierć lub stratę ogromnej ilości pieniędzy), która dzieje się z tworzonym oprogramowaniem?”.

Miałem takie same doświadczenia jak ty na niektórych moich kursach. Ludzie, którzy mieli doświadczenie w branży wojskowej, nauczyliby nas analizy. Byłaby to kompletna i wyczerpująca analiza, planująca cały przebieg projektu, nawet w najdrobniejszych szczegółach. Nie możesz sobie pozwolić na wiele iteracji z tego rodzaju projektem (również wybuchanie bomby może być w porządku, wybuchanie budżetu nie jest), więc nie ma tu miejsca na kreatywność, musisz przejść przez plan.

Z drugiej strony, jeśli trochę przeczytałeś, na pewno przeczytasz o zwinnych metodologiach. Zasadniczo jest mniej dokumentacji i więcej miejsca dla programisty na wykorzystanie jego kreatywności przy opracowywaniu rozwiązania napotkanego problemu.

Podsumowując, im więcej zdobędziesz doświadczenia, tym lepiej i to, co pokazuje ci twój instruktor, ma zastosowanie w pewnej części branży. Pamiętaj tylko, że istnieje wiele sposobów zarządzania i projektowania projektu, tak jak istnieje możliwość ich kodowania. I znajdziesz dla nich wszystkich obrońców i krytyków. Przetestuj je podczas nauki i wybierz ten, z którego jesteś zadowolony.

Matthieu
źródło
I uważaj na „Czy może zabijać ludzi, jeśli się zawiesi” - istnieje inny typ o nazwie „Czy ktoś może pójść do więzienia, jeśli wydrukuje nieprawidłowe dane”, i to często wraca do faceta dotykającego klawiatury, więc dobrze jest mieć bardzo szczegółowe wymagania, w najdrobniejszych szczegółach.
Christopher Mahan
@Christopher: odpowiednio dostosowałem moją odpowiedź, dziękuję za komentarz :)
Matthieu,
0

Niektóre klasy inżynierii oprogramowania, takie jak ta, którą miałem, są prowadzone w dziwnym stylu, w którym „porażka to sukces”, sukces to zmarnowana szansa na naukę z porażki, a im więcej, tym mniej, tym więcej. Jeśli jest to jeden z nich, po prostu trzymaj się zadań i ciesz się dziwnością.

Praca
źródło
0

Myślę, że twój instruktor nie ma kontaktu. Oprogramowanie komercyjne rzadko jest projektowane lub dokumentowane w tym zakresie. Jest to o wiele za drogie, a wynikającej z tego dokumentacji nie można utrzymać bez dodatkowych kosztów. Takie praktyki IMO są dziedzictwem od czasów, gdy kodowanie często odbywało się w języku asemblera. Lepiej byłoby spędzić czas na próbowaniu bardziej zwinnych praktyk: programowanie oparte na testach, programowanie par, ciągłe refaktoryzowanie.

Czy instruktor „powiedział ci źle”?

Chyba tak.

Przypisywanie nudnej pracy pracownikom własności intelektualnej jest marnotrawstwem. W szkole nudna praca ma niewielką lub żadną wartość pedagogiczną, z wyjątkiem być może zachęcania uczniów do nudnej pracy. Takie ćwiczenia mają negatywne konsekwencje, zarówno dla studentów, jak i dla branży. Studenci są skrzywdzeni, ponieważ ich czas jest zmarnowany. Przemysł jest poszkodowany, ponieważ niektórzy studenci mogą dojść do wniosku, że takie nudy są konieczne i przydatne. To nie jest ani jedno, ani drugie. W ciągu trzydziestu lat pracy w oprogramowaniu jedyną pracą, jaką wymyśliłem, była nudna i użyteczna, była zmiana taśm zapasowych. Były w stanie to zrobić, ale były zbyt drogie.

Kevin Cline
źródło
2
Odważę się powiedzieć, że nigdy nie pracowałeś dla firmy, która zarabia na kontraktach rządowych. (edytuj) Powiedziałeś, że oprogramowanie komercyjne. Moje oświadczenie jest teraz bez znaczenia.
Andrew T Finnell,
@Andrew Finnel: Prawda jest tak bolesna na wielu poziomach.
Peter Rowell,
2
@Andrew - pracowałem do DOD2167. To było okropne i bezproduktywne, jak to było praktykowane. Później pracowałem dla innej firmy, która często wykonuje rzetelne prace rozwojowe dla rządu. Klient jest bardzo szczęśliwy. Mieli przydatną aplikację w ciągu sześciu miesięcy i co kwartał otrzymują nowe funkcje.
kevin cline,
@Andrew Mam ponad 2-letnie doświadczenie w pracy w USA DoD, jako pracownik rządowy i jako kontrahent. Przyjmowane są metody zwinne. Jeden zespół, nad którym pracowałem, aktywnie korzystał ze Scrum, tworząc „wystarczającą” dokumentację „na czas”. Tak, dokumentacja (nawet „wystarczająca” dokumentacja) jest znacznie obszerniejsza niż w wielu innych miejscach, ale zazwyczaj wynika to z liczby zaangażowanych stron (umowy mogą zmienić właściciela, inne strony mogą opracować inne systemy itd.) I / lub krytyczność bezpieczeństwa lub życia oraz znaczenie opracowywanych systemów.
Thomas Owens
2
@Andrew to nie tylko rządy. Widziałem 40 stron specyfikacji dla „produktów”; normalnie możesz wybrać wszystko z tej tabeli i podać mi rurkę rozdzieloną, proszę. Nikt nigdy nie będzie miał trudności z ich odczytaniem ...
Ben