Pogodzenie sprzecznych porad programistycznych: spraw, by coś działało i iterowało, a naprawdę pomyśl o tym przed kodowaniem

Jestem średnio zaawansowanym programistą z kilkuletnim doświadczeniem zawodowym, który jest w połowie drogi magisterskiej. Podczas nauki programowania często słyszałem dwie pozornie sprzeczne rady.

Pierwsza rada: spraw, by coś działało szybko, sprawdź, jak to działa (poprzez prototypowanie lub testy nieformalne), popraw wersję, zobacz, jak to działa ponownie, popraw to ponownie ... a następnie powtarzaj cykl, aż skończysz . Jest to czasami nazywane „rozwojem spirali” lub sformułowane jako „wczesne wydanie, częste wydanie”.

Druga porada brzmiała: naprawdę przemyśl projekt, zanim napiszesz jakikolwiek kod.

Odniosłem sukces w obu metodach i powiedziałbym, że zgadzam się z każdą filozofią.

Ale teraz zaczynam zajmować się znacznie bardziej złożonymi projektami, których nie mam pojęcia (jak aplikacje rozproszone i programowanie graficzne oparte na wydajności).

Jak mogę przejść do tych projektów?

Czy po prostu zaczynam kodować COŚ i uczę się (platformy / metody / języki / architektury), kiedy przechodzę - czy też powstrzymuję się od kodowania i robię mnóstwo badań / czytania, zanim jeszcze otworzę IDE?

Jak pogodzić te sprzeczne wskazówki programistyczne?

Nie jestem pewien, czy myślenie o problemie przed czasem a podejście iteracyjne jest ze sobą sprzeczne. Podobnie jak wiele innych rzeczy, myślę, że powinieneś dążyć do osiągnięcia równowagi między nimi. Jak znaleźć równowagę? To jest coś, czego uczysz się z doświadczeniem i często najlepsze lekcje czasu (tj. Rzeczy, które dają ci doświadczenie), kiedy nie rozumiesz tego dobrze (lub jeszcze lepiej: lekcja: po prostu źle zrozum to źle). Jak już zauważyłeś, jest powiedzenie „szybko wypuszczaj, często wypuszczaj”. Jest jeszcze jeden podobny: „zawodzić wcześnie, zawodzić szybko, zawodzić często”

Myślenie naprzód jest świetne i powinieneś to absolutnie zrobić. Ale z doświadczeniem dowiedz się, kiedy przestać myśleć i po prostu zbudować coś, nawet jeśli nie masz wszystkich danych. Budując go, będziesz w stanie uzyskać lepszy wgląd w dziedzinę problemów i potencjalnie znaleźć znacznie lepsze rozwiązanie. Dlatego polecam nie wykluczać jednego z drugiego, ale uczynić z „iteracyjnej głowy” część swoich iteracji iz czasem myślę, że sam znajdziesz właściwą odpowiedź na to pytanie.

Tylko mały przykład. Pewnego dnia zmagałem się z decyzją dotyczącą projektowania oprogramowania. Z perspektywy czasu było to względnie trywialne, ale miałem dwie alternatywy i wydawało się, że obie będą działać. Ciągle krążyłem z powrotem do zalet / wad każdego z nich, a następnie krążyłem z powrotem i ponownie rozważałem swoje decyzje. Patrząc wstecz, to trochę krępujące, ile czasu spędziłem na myśleniu. Potem powiedziałem sobie: kurwa! I zamiast używać jednego z projektów, po prostu pospiesznie zhakowałem trochę kodu, całkowicie ignorując wszystkie dobre rzeczy, których dowiadujesz się o dobrym projekcie. Uruchomiłem tę funkcję w około 45 minut. Potem wróciłem, spojrzałem na mój kod i przekształciłem go w coś solidnego i coś, czego nie wstydziłbym się po sprawdzeniu kontroli źródła. Zabawne jest to, że po uruchomieniu hacka wymyśliłem „

Kolejną rzeczą, którą poleciłbym szczególnie w przypadku problemów, z którymi się teraz borykasz (tj. Zbliżających się dużych, złożonych zadań). Zamiast robić rzeczy szeregowo, rób to równolegle. Podziel dzień na części, w których prowadzisz badania, a następnie zatrzymaj się, przełącz na chwilę bieg i kod, przynajmniej na części projektu, które nie są kompletnymi niewiadomymi. W ten sposób trzymanie się blisko kodu zapewni lepszą perspektywę i nie wypalisz się, próbując zbyt szybko wchłonąć zbyt wiele informacji. Dla mnie przynajmniej po kilku godzinach badań dobrze jest pozwolić mózgowi trawić rzeczy, zmieniać zadania i robić coś innego przez jakiś czas. Następnie wróć do dalszych badań.

Są pewne decyzje, które należy podjąć z wyprzedzeniem.

Czy tworzysz aplikację internetową? Następnie musisz wiedzieć, jak będzie wyglądać ogólna architektura. Architektury takie jak MVC już określają, jakie będą twoje duże elementy funkcjonalne (takie jak routing, kontrolery, modele, warstwy usług, protokoły komunikacyjne i tak dalej); wynalezienie tego wszystkiego od zera będzie długodystansowe, niepotrzebne i prawdopodobnie gorsze od tego, co już zostało wynalezione.

Czy piszesz jakąkolwiek aplikację, która obejmuje kolekcje obiektów lub danych? Następnie musisz dowiedzieć się, jakie struktury danych są najbardziej odpowiednie dla danego scenariusza i jakie są ich cechy wydajności. Czy potrzebujesz szybkiego czasu wyszukiwania? A co z zamówionymi zestawami danych? Czy zrobi to kolekcja w pamięci, czy potrzebujesz czegoś bardziej przemysłowego, jak baza danych? Nie możesz po prostu zacząć kodować bez przemyślenia tych decyzji, ponieważ jeśli wybierzesz zły wybór, musisz zacząć od nowa.

To powiedziawszy, po podjęciu decyzji technologicznych masz swobodę w ustalonych ramach. Celem jest zatem pozostanie elastycznym, iteracyjnym i (śmiem twierdzić) na tyle zwinnym, aby gdy klient zmienił zdanie na temat tego, czego chce, można go było obsłużyć przy minimalnym wysiłku.

Jak to robisz? Głównie doświadczenie. Jak ktoś kiedyś powiedział, doświadczenie jest tym, co dostajesz zaraz po tym, jak go potrzebujesz. Ale jeśli postępujesz zgodnie z udanymi decyzjami innych projektantów (zawartymi w platformach, bibliotekach i innych narzędziach handlu), możesz się z nich uczyć i zmniejszyć ryzyko.

Nie uważam tych dwóch za wykluczające się wzajemnie.

Jak każde zarządzanie projektem, potrzebujesz zarówno długoterminowej wizji, jak i krótkoterminowych celów.

Bez tego pierwszego zmarnujesz czas, na przykład na funkcje, których nigdy nie będziesz mógł użyć, a bez tego drugiego będziesz spędzać cały dzień, zastanawiając się, jak stworzyć idealną aplikację bez ukończenia projektu.

Jak często wypuszczasz / etc. zależy od konkretnej metodologii, której używasz.

To, co musisz zbadać, zależy od tego, co wiesz, od tego, z czym nie czujesz się komfortowo.

„Iteracja” i „przemyślenie” nie są sprzeczne, lecz uzupełniają się.

Nawet w skrajnościach odzwierciedlają dwie ścieżki do tego samego miejsca.

• Skrajną iteracją jest tysiąc małp walących w tysiąc klawiatur. Z wystarczającą ilością czasu może dostaniesz coś, co spełnia wymagania.
• Ekstremalność „przemyślenia” to podejście do Wodospadu. Jeśli masz szczęście, wymagania nie zmieniły się radykalnie od początku projektu do czasu dostarczenia kodu. Albo skończysz z paraliżem analizy i nic nie dostarczyłeś.

Zanim zaczniesz kodować, musisz trochę zrozumieć domenę i problem. To jest część „przemyśleć to”. Idealnie zobaczysz ścieżkę wysokiego poziomu od początku do końca, w jaki sposób rozwiązać problem.

Ale możesz zobaczyć tylko główne fragmenty tej ścieżki, a na pewno nie każdy przystanek po drodze. Właśnie tutaj wchodzi w grę iteracja. Możesz rozpocząć iterację od wersji aplikacji i poszukać opinii w celu:

• Zidentyfikuj przeszkody na niższych poziomach szczegółowości
• Zobacz opinie zainteresowanych stron, aby wyjaśnić te mroczne obszary na ścieżce wysokiego poziomu.

The Łacińskie korzenie decydują środki do „cut off”. Iteracja pozwala zdecydować, co działa w praktyce, a nie tylko teorię, a iteracja pozwala wyciąć inne opcje, które nie są możliwe.

Musisz więc przemyśleć problem, aby zrozumieć, co zamierzasz zrobić. Ale musisz iterować wersje aplikacji, aby faktycznie przekształcić pomysł w rzeczywisty kod.

Moja ogólna zasada: jeśli nie w pełni rozumiesz jakąkolwiek część problemu, musisz cofnąć się i w pełni przemyśleć (dołączam prototypowanie i wyrzucanie kodu, aby zrozumieć interfejsy API itp. Jako część „przemyślenia”) . Jeśli jest to w zasadzie zbiór problemów, które wcześniej rozwiązałeś i po prostu musisz znaleźć najlepszy sposób, aby dopasować wszystko do siebie w tym konkretnym przypadku, to powtórz.

Szczerze mówiąc, nie jest to trudna i szybka zasada. Naprawdę uważam, że musisz zrobić połączenie obu dla każdego projektu. To, ile z każdego zrobisz, będzie zależeć głównie od tego, jak blisko jest projekt do tego, który już ukończyłeś.