Od półtora roku pracuję jako programista aplikacji (nie wiem długo) i właśnie dostałem swój pierwszy duży projekt.

Nie trzeba dodawać, że nie poszło to bardzo gładko, dlatego szukałem porady od starszego programisty zaangażowanego w projekt, jak podejść do tego.

Powiedział, że drastycznie przestałem myśleć o tym zadaniu, i ponieważ nigdy nie zajmowałem się projektem na taką skalę, zanim spędziłem zbyt wiele czasu nad myśleniem o wzorach projektowych. W swoich mądrych słowach powiedział mi: „Kurwa, buduj przyszłość”.

Czy programiści zazwyczaj podążają za takim projektem? Na przykład, jeśli poproszono Cię o wykonanie modelu koncepcyjnego, czy typowym trendem jest po prostu zebranie wykonalnego przykładu tak szybko, jak to możliwe?

Edycja: W świetle debaty, którą to wywołało, chciałbym wspomnieć, że ta sytuacja jest dość ekstremalna: mamy bardzo napięte terminy z przyczyn niezależnych od nas (tj. Rynek, na który dążymy, straci zainteresowanie, jeśli im coś pokazać), a jego rada okazała się bardzo skuteczna w przypadku tego konkretnego zadania.

Kapitan Oczywisty na ratunek!

Będę tu Kapitanem Oczywistym i powiem, że można znaleźć jakiś środek.

Chcesz budować na przyszłość i unikać uzależnienia się od wyboru technologicznego lub złego projektu. Ale nie chcesz spędzać 3 miesięcy na projektowaniu czegoś, co powinno być proste, lub dodawaniu punktów rozszerzeń dla szybkiej i brudnej aplikacji, która będzie miała 2 lata użytkowania i prawdopodobnie nie będzie mieć projektów następczych.

Trudno jest znaleźć to rozróżnienie, ponieważ nie zawsze można przewidzieć sukces produktu i jeśli trzeba będzie go później rozszerzyć.

Buduj na teraz, jeśli ...

• projekt zostanie złomowany
• projekt ma krótką żywotność
• projekt nie powinien mieć rozszerzeń
• projekt nie ma wartości ryzyka (głównie pod względem wizerunku)

Ogólnie rzecz biorąc, na razie należy opracować własne projekty lub coś zbudowanego dla klienta. Pamiętaj, aby mieć proste wymagania i odnosić się do nich w razie potrzeby, aby wiedzieć, co jest potrzebne, a co nie. Nie chcę spędzać zbyt wiele czasu na czymś, co „miło mieć”. Ale nie koduj też jak świnia.

Pozostaw problem ogólny na później, jeśli będzie to kiedykolwiek konieczne i warte wysiłku:

Buduj na przyszłość, jeśli ...

• projekt będzie publiczny
• projekt jest komponentem do ponownego wykorzystania
• projekt stanowi odskocznię dla innych projektów
• projekt będzie zawierał kolejne projekty lub wydania usług z ulepszeniami

Jeśli budujesz coś publicznego lub zostanie to ponownie wykorzystane w innych projektach, masz znacznie większe prawdopodobieństwo, że zły projekt wróci, by cię prześladować, więc powinieneś zwrócić na to większą uwagę. Ale nie zawsze jest to gwarantowane.

Wytyczne

Powiedziałbym, że przestrzegaj następujących zasad najlepiej, jak potrafisz, i powinieneś postawić się w sytuacji projektowania wydajnych, elastycznych produktów:

• wiedzieć, że YAGNI ,
• KISS ,
• ilekroć masz ochotę podrapać się na świąd i pomyśleć o dodatku, zapisz go. Spójrz wstecz na wymagania swojego projektu i zadaj sobie pytanie, czy dodatki są priorytetami, czy nie. Zapytaj, czy dodają podstawową wartość biznesową, czy nie.

Wiem, że osobiście mam tendencję do zbytniego zastanawiania się i nadmiernej inżynierii. To naprawdę pomaga spisywać pomysły i bardzo często przemyśleć, czy potrzebuję dodatkowych funkcji. Często odpowiedź brzmi „nie” lub „byłoby później fajnie”. Te ostatnie pomysły są niebezpieczne, ponieważ pozostają z tyłu mojej głowy i muszę zmusić się, żeby nie planować ich.

Najlepszym sposobem na kodowanie bez nadmiernej inżynierii i bez blokowania się na później jest skupienie się na dobrym minimalnym projekcie. Ładnie rozkładaj elementy na części, które możesz później rozszerzyć, ale nie zastanawiając się już, w jaki sposób można je później rozszerzyć. Nie możesz przewidzieć przyszłości.

Po prostu buduj proste rzeczy.

Dylemat

Nadmierna inżynieria

Czy programiści zazwyczaj podążają za takim projektem?

O tak. To znany dylemat i pokazuje tylko, że zależy Ci na produkcie. Jeśli nie, to bardziej niepokojące. Nie ma zgody co do tego, czy zawsze mniej znaczy naprawdę więcej, a jeśli gorzej jest zawsze naprawdę lepiej . Możesz być facetem typu MIT lub New Jersey . Nie ma tutaj łatwej odpowiedzi.

Prototypowanie / Quick-n-Dirty / Less to więcej

Czy to typowy trend, aby jak najszybciej znieść praktyczny przykład?

Jest to powszechna praktyka, ale nie w ten sposób podchodzi się do większości projektów. Mimo to prototypowanie jest moim zdaniem dobrym trendem, ale ze znacznym minusem. Kuszące może być promowanie szybkich i brudnych prototypów na rzeczywistych produktach lub wykorzystanie ich jako podstawy dla rzeczywistych produktów pod presją zarządzania lub ograniczeniami czasowymi. Wtedy prototypowanie może cię prześladować.

Prototypowanie ma oczywiste zalety , ale także duży potencjał niewłaściwego użytkowania i nadużyć (w rezultacie wiele dokładnie odwrotności wcześniej wymienionych zalet).

Kiedy używać prototypowania?

Istnieją wskazówki na temat najlepszych rodzajów projektów do zastosowania prototypowania :

[...] prototypowanie jest najbardziej korzystne w systemach, które będą miały wiele interakcji z użytkownikami.

[...] prototypowanie jest bardzo skuteczne w analizie i projektowaniu systemów on-line, szczególnie w przetwarzaniu transakcji, gdzie użycie dialogów ekranowych jest znacznie bardziej widoczne. Im większa interakcja między komputerem a użytkownikiem, tym większa korzyść [...]

„Jednym z najbardziej produktywnych zastosowań szybkiego prototypowania do tej pory było narzędzie do iteracyjnej inżynierii wymagań użytkownika i projektowania interfejsu człowiek-komputer”.

Z drugiej strony:

Systemy z niewielką interakcją użytkownika, takie jak przetwarzanie wsadowe lub systemy, które w większości wykonują obliczenia, niewiele korzystają z prototypowania. Czasami kodowanie potrzebne do wykonywania funkcji systemu może być zbyt intensywne, a potencjalne korzyści, jakie może zapewnić prototypowanie, są zbyt małe.

A jeśli masz w pobliżu zielonego potwora, pamiętaj o zachowaniu prototypu w ramach budżetu ...

Kiedy zaczynasz programować, wszystko jest dowodem koncepcji, nawet jeśli jest to tylko dla ciebie. Są przypadki, gdy pomysł wymaga czegoś szybkiego i brudnego lub prototypu, ponieważ czas jest kluczowym czynnikiem. Ogromny strach wśród deweloperów polega na tym, że interesariusze myślą, że mała aplikacja jest gotowa do produkcji, lub powinieneś móc dodawać funkcje w tym samym tempie na zawsze. Pracujesz nad dużym projektem i okazuje się, że tak nie jest.

Duże projekty zwykle mają bardziej złożone wymagania, więc istnieje pokusa, aby spróbować wdrożyć złożone projekty. Spędzisz dużo czasu czytając, badając i próbując je wdrożyć. Może to stać się wielkim marnotrawstwem czasu, ale jest to część uczenia się i zdobywania doświadczenia. Wiedza, kiedy użyć określonego projektu, jest trudna i zwykle wiąże się z doświadczeniem. Próbowałem „tego” na „tym” projekcie i to nie działało, ale teraz widzę, że powinno działać na „tutaj”.

Musisz dużo planować i planować, ale nie rób tego wszystkiego naraz. Na pewno nie trzeba tego robić na początku. Wolałbym, żeby ktoś stworzył swój pierwszy tak duży projekt:

1. Zaprojektuj i omów trochę.
2. Napisz garść kodu, który coś robi.
3. Rozpoznaj problemy i kod STOP.
4. Poważnie podchodź do projektowania i przestań martwić się utratą rozpędu lub kodu-mojo i zignoruj ​​kierownika projektu (wyświadczasz mu przysługę).
5. Przejmij kontrolę nad projektem. Napraw swoje bałagany. Upewnij się, że wszyscy rozumieją plan. Utrzymaj projekt pod kontrolą.

Czasami trafiasz na jedną z tych funkcji, która naprawdę niepokoi Cię, jak zaimplementować ją w istniejącej bazie kodu. To nie jest czas, aby „po prostu sprawić, by działało”. Miałem szefa, który powiedział: „Czasami musisz złapać stołek zamiast młotka”. Powiedział mi to po tym, jak przyłapał mnie na „myśleniu” przy biurku. W przeciwieństwie do wielu bossów, nie przypuszczał, że wygłupiam się i upewniłem się, że rozumiem, że chce, abym zrobił więcej. Geniusz.

Ostatecznie twój kod jest projektem. Wspierają go dokumenty, diagramy, spotkania, e-mail, dyskusje na tablicy, pytania SO, argumenty, przekleństwa, napady wściekłości i ciche rozmowy przy kawie. Jest taki moment, w którym nie możesz już więcej projektować i ryzykujesz, że poświęcisz więcej czasu na projektowanie z powodu wad, które odkryjesz tylko podczas pisania kodu. Ponadto, im więcej kodu napiszesz, tym większa szansa, że ​​wprowadzisz wadę projektową, z której nie da się kodować. Czas znów na stołek.

Czy programiści zwykle budują coś, co działa teraz, nie myśląc o przyszłości?

Tak.

Czy powinni to zrobić?

Nie.

Na pierwszy rzut oka wydaje się, że „myślenie o przyszłości” narusza ustalone zasady projektowania, takie jak KISS i YAGNI , które twierdzą, że nie należy wdrażać niczego, co nie jest obecnie wymagane.

Ale tak naprawdę nie jest. Myślenie o przyszłości oznacza projektowanie prostego, rozszerzalnego i zarządzalnego oprogramowania. Jest to szczególnie ważne w przypadku projektów długoterminowych. Z czasem wymagane będą nowe funkcje, a solidna konstrukcja ułatwi dodawanie nowych elementów.

Nawet jeśli nie zamierzasz pracować nad projektem po jego ukończeniu, nadal powinieneś go inteligentnie rozwijać. To twoja praca i powinieneś robić to dobrze, przynajmniej po to, aby nie zapomnieć o tym, jak dobra jest praca.

Zwinni programiści mają powiedzenie „Nie potrzebujesz go (YAGNI)”, które zachęca do zaprojektowania tego, czego potrzebujesz teraz, a nie tego, co Twoim zdaniem może być potrzebne w przyszłości. Aby przedłużyć projekt do pracy w przyszłości, zalecaną drogą jest refaktoryzacja.

Ważnym aspektem tego jest zachowanie wymagań dotyczących produktu podczas projektowania i upewnienie się, że nie projektujesz szeregu wymagań, które mogą się zdarzyć w przyszłości.

Jest coś do powiedzenia dla programistów, którzy potrafią myśleć o dwóch lub trzech iteracjach - znają swoich klientów lub domenę tak dobrze, że mogą przewidywać przyszłe potrzeby z dużą dokładnością i budować dla nich, ale jeśli nie jesteś pewien, najlepiej nie spędzać zbyt wiele czasu na rzeczach, których ty lub klienci nie potrzebujesz.

Czy programiści zazwyczaj podążają za takim projektem?

Podejrzewam, że twój mentor miał na myśli to, że nie powinieneś budować dodatkowej złożoności, która może nie być wymagana przez ostateczne rozwiązanie.

Zbyt łatwo jest myśleć, że aplikacja powinna to zrobić i to i zostać masowo odsunięta na bok.

Jeśli chodzi o wzorce projektowe, warto pamiętać, że są one środkiem do celu. Jeśli z doświadczenia okaże się, że określony wzór nie pasuje pomimo wcześniejszego przeczucia, może to wskazywać na zapach kodu.

Na przykład, jeśli poproszono Cię o wykonanie modelu koncepcyjnego, czy typowym trendem jest po prostu zebranie wykonalnego przykładu tak szybko, jak to możliwe?

Przed rozpoczęciem projektu warto uzyskać kontrolę nad tym, jakie są kamienie milowe i czy będą chcieli zobaczyć wszystko po trochu (pionowy wycinek), czy tylko szczegółowo każdą część podczas jej opracowywania (wycinek poziomy). W ramach wstępnego projektu uważam, że warto wejść na pokład całej aplikacji, więc nawet jeśli kod nie jest napisany, możesz zrobić widok helikoptera na całość lub głęboko zanurzyć się w danym obszarze.

Powiedział, że drastycznie przestałem myśleć o tym zadaniu i że ponieważ nigdy nie miałem do czynienia z takim dużym projektem, spędzałem zbyt dużo czasu nad myśleniem o wzorach projektowych. W swoich mądrych słowach powiedział mi: „Kurwa, buduj przyszłość”.

Myślę, że to trochę kowbojska mentalność innego dewelopera. Współczesna wersja twardego kujona, który po prostu „robi to teraz”. Stało się popularnym tematem wśród startupów i nie dziękuję ludziom na Facebooku za rozpoczęcie frazy „lepiej to zrobić niż zrobić dobrze”.

To pociągające. To zachęcające i oferuje wizje programistów stojących wokół konsoli klaszczących w dłonie, gdy uruchamiają swój duży projekt w świat na czas, z ograniczonym budżetem, a wszystko dlatego, że niczego nie zaprojektowali.

To idealistyczna fantazja, a życie nie działa w ten sposób.

Głupiec wpadnie na projekt myśląc, że może po prostu „zrobić to” i zrobić to. Sukces faworyzuje programistę, który przygotowuje się na niewidzialne wyzwania i traktuje swój zawód jak kunszt.

Każdy starszy programista może krytykować, potępiać i narzekać - a większość tak!

Podczas gdy on / ona mówi ci, że „nadmiernie myślisz” o projekcie. Najpierw gratuluję ci „myślenia”. Zrobiłeś pierwsze kroki, aby być lepszym programistą niż ten drugi facet.

Czy programiści zazwyczaj podążają za takim projektem? Na przykład, jeśli poproszono Cię o wykonanie modelu koncepcyjnego, czy typowym trendem jest po prostu zebranie wykonalnego przykładu tak szybko, jak to możliwe?

To właśnie jest dowód koncepcji. Jest to próba zmiażdżenia czegoś tak szybko, jak to możliwe, aby ludzie mogli zrobić krok do tyłu i spojrzeć na to. Ma to na celu zapobieganie błędom, niewłaściwemu kierowaniu i marnowaniu czasu / pieniędzy.

Istnieje wiele różnych rodzajów dowodów koncepcji. Możesz zbudować coś, co zostanie wyrzucone do śmieci po zakończeniu, lub możesz zbudować coś, co stanowi punkt wyjścia dla projektu. Wszystko zależy od tego, czego potrzebujesz i od tego, jak bliska jest koncepcja produktu końcowego.

To także okazja do zademonstrowania swoich pomysłów. Były czasy, kiedy przedstawiałem prototyp, który wzniósł rzeczy na poziom, którego się nie spodziewali.

Projekt jest zwykle otwarty, więc zbyt łatwo jest zastosować go za dużo lub za mało. Prawidłową kwotę poznasz dopiero po zakończeniu lub odrzuceniu projektu. A nawet nie wtedy.

Nie ma ogólnej recepty na sukces, ale możesz nauczyć się rozpoznawać skrajności. Kompletny projekt wszystkiego z przodu prawie nigdy nie wychodzi poza banalne rzeczy. Można pozostawić komponenty do udoskonalenia i mieć wrażenie, że da się to zrobić, lub istnieje sposób wczesnego wykrycia problemów.

Możesz sprawdzić, jak działa przyrostowy rozwój, jeśli nie jesteś zaznajomiony. Skuteczne metody zwykle są iteracyjne na jednym lub kilku poziomach, szukają ścisłej informacji zwrotnej i rosną na jakimś szkielecie.

Jest kilka dobrych powodów, aby słuchać rad, aby przestać planować i zacząć kodować;

1. Po zaledwie 18 miesiącach pracy jako programista jest mało prawdopodobne, że będziesz w stanie przewidzieć przyszłość na tyle dobrze, aby ją zaplanować, bez względu na GPA. Jest to coś, co jest niezwykle trudne do zrozumienia dla jasnych, ale niedoświadczonych programistów, ponieważ chodzi o to, aby nie wiedzieć tego, czego nie wiesz. Stare ręce mogły rozpoznać tę słabość w twojej wizji i mądrze zachęcały cię, abyś po prostu w nią wpadł i zrobił wszystko, co mógł.

2. Młodzi programiści mogą mieć obsesję na punkcie doskonalenia projektu, zanim zaczną kodować. Mogą obejmować strach przed napisaniem kodu (lęk przed wydajnością) lub mogą mieć blok kodera (jak blok pisarzy). Są zbieżne w projekcie, ponieważ nie ma wymaganej wydajności pracy. Młody twórca prawdopodobnie zareaguje gniewnie na sugestię, że „boją się” czegokolwiek. Może pod koniec projektu zdadzą sobie sprawę, że tak było. Rada, aby nie martwić się i uzyskać kodowanie, jest jedynym znanym lekarstwem na blok kodera. Stara ręka może mądrze zaoferować tę radę.

3. W obliczu ostrych ograniczeń harmonogramu szanse na ukończenie projektu są w ogóle ograniczone. Planuj zbyt długo i bez względu na to, jak dobry jest ten plan, nie możesz go wykonać na czas i nigdy nie wejdziesz na rynek. Zacznij hakować od samego początku, a być może będziesz miał szczęście i będziesz miał rację za pierwszym razem. Dostarczasz produkt w cudowny sposób. A może nie masz tyle szczęścia i dostarczysz na wpół upieczony kawałek żużla, ale dostanie się na rynek na czas i nauczysz się czegoś. A może zawiedziesz. Ale „może ci się nie uda” to wciąż lepsze szanse niż „nigdy nie wprowadzać na rynek”, ponieważ planowałeś zbyt długo. Najważniejsze jest to, że twoje szanse są od samego początku ograniczone, więc nic nie tracisz przez hakowanie. Twój menedżer może wiedzieć, że szanse na sukces są niewielkie, i przydzielił młodszy zasób jako ćwiczenie edukacyjne. Uczymy się lepiej z porażki niż z sukcesu. Czy może pytasz: „Kiedy mogę mieć cały projekt?”

Potrzeba dość introspektywnego i wolnego od ego programisty, aby zobaczyć własne niedoskonałości, więc medytuj chwilę przed przeczytaniem reszty, aby nie dać sobie wymówki, by przeoczyć własne słabości ...

Nie każdy programista jest szczególnie dobry w analizie, planowaniu i innych zadaniach wymagających przemyślenia. Myśl jest trudna i niegrzeczna. Wymaga pewnego rodzaju potu psychicznego, który sprawia, że ​​czujesz się niekomfortowo i wykręca się po dniu pracy. To po prostu nie jest tak zabawne jak wchodzenie w stan płynności z dwiema puszkami Potwora i twój kamień stał się głośny i kodował, kodował, kodował. Programiści, którzy nie lubią myśleć, oprą się poglądowi, że planowanie to dobry pomysł. Zalecają metody opracowywania, które nie wymagają planowania z góry. Lubią firmy i menedżerów, którzy nie kładą nacisk na planowanie. Przenikają się one do miejsc pracy, w których koszt nieplanowania nie jest zbyt wysoki. Cenią sobie całonocne sesje kodowania i udostępniają tę poprawkę klientom, których cały biznes nie działa z powodu błędu.

Niektórzy programiści zdali sobie nawet sprawę z tego, że dostanie czegoś działającego wystarczająco dobrze do demonstracji oznacza, że ​​sprawienie, by działało całkowicie i we wszystkich okolicznościach, może zostać odroczone, a może nawet zepchnięte na innego programistę, podczas gdy otrzymają pochwały za „wykonanie zadania” na początku.

Są menedżerowie, którzy sami nie mogą dostrzec trendu, dopóki nie przełamie się na Facebooku. Zamiast znaleźć pracę zarządzającą sklepem z oponami dyskontowymi, ci menedżerowie sprawiają, że Twoim problemem jest konieczność uruchomienia kodu do piątku. Nie chcą słyszeć, że musisz zaprojektować interfejs API lub przetestować, czy Twój algorytm jest skalowalny. To dla nich tylko mumbo-jumbo. Będą zachęcać do kodowania, ponieważ to wszystko, co rozumieli na temat oprogramowania, gdy pisali skrypty Perla, aby pomóc klientom w transferze plików. (Mieli tytuł „inżynier oprogramowania” w swojej pierwszej pracy sprzedażowej. Kto wiedział, że oprogramowanie będzie tak nudne i trudne?)

Pokaż mi swój kod, a powiem ci, kim jesteś

Twój kod jest Twoją wizytówką. Jeśli napiszesz niechlujny kod, co powiesz o sobie innym ludziom? Pomyśl o tym. Za każdym razem, gdy znajdujemy w biurze naprawdę zły fragment kodu, zadajemy sobie pytanie, kto go napisał i jak, u diabła, przeszedł przez uniwersytet?

Stajesz się tym, co kodujesz

Twój kod to Twój program na całe życie.

Programista piszący zły kod jest jak tancerz baletowy tańczący w klubie striptiz

Niektórym nie przeszkadza taniec w klubie striptiz. Ale jeśli są utalentowanymi tancerzami, marnują swoje umiejętności. Jeśli jesteś biednym tancerzem, ale masz ładne nogi, możesz rozebrać się dla wielu.

Na koniec powinieneś przeczytać powieść Gogola „Portret” i powinieneś zostać ostrzeżony przez historię głównego bohatera. Twój przyjaciel jest podobny do mężczyzny z portretu. Zwabia cię pieniędzmi, ale zapłacisz za to wysoką cenę.