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

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

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.

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.

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.

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.

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.

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.

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.

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

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.