Prototypowanie kontra czysty kod na wczesnych etapach

43

Planuję pracować / rozpocząć kilka osobistych projektów, które mogą zakończyć się moją codzienną pracą. Sprawiło, że pomyślałem, w jaki sposób powinienem zacząć?

  • Tylko prototyp - napisz działający kod podstawowy, który może kosztować mnóstwo czasu optymalizacji i refaktoryzacji w celu łatwej rozbudowy.

  • Napisz czysty, zoptymalizowany i udokumentowany kod od samego początku, pamiętając, że jeśli po pewnym czasie nie będzie opłacalny, zostanie usunięty.

Aktualizacja: Połączenie YAGNI z odpowiedziami sunpech i M.Sameer ma dla mnie idealny sens :) dziękuję wszystkim za pomoc.

JackLeo
źródło
1
patrz także: Kiedy refaktoryzować
komara

Odpowiedzi:

39

Istnieje trzecia opcja ... napisanie czystego kodu za pomocą programowania opartego na testach, aby wdrożyć wymagania, które są dziś potrzebne, ponieważ YAGNI.

Pokusa, by napisać kod, który nie jest w tej chwili potrzebny, ale może być w przyszłości, ma kilka wad ... od Ciebie nie będziesz go potrzebował :

  • Czas poświęcony jest na dodawanie, testowanie lub ulepszanie niezbędnej funkcjonalności.
  • Nowe funkcje muszą być debugowane, dokumentowane i obsługiwane.
  • Każda nowa funkcja nakłada ograniczenia na to, co można zrobić w przyszłości, więc niepotrzebna funkcja może uniemożliwić późniejsze wdrożenie koniecznej funkcji.
  • Dopóki ta funkcja nie jest faktycznie potrzebna, trudno jest w pełni zdefiniować, co powinna zrobić i przetestować. Jeśli nowa funkcja nie zostanie poprawnie zdefiniowana i przetestowana, może nie działać poprawnie, nawet jeśli w końcu będzie potrzebna.
  • Prowadzi to do wzdęcia kodu; oprogramowanie staje się większe i bardziej skomplikowane. Jeśli nie ma specyfikacji i kontroli wersji, funkcja ta może nie być znana programistom, którzy mogliby z niej skorzystać.
  • Dodanie nowej funkcji może sugerować inne nowe funkcje. Jeśli te nowe funkcje zostaną również zaimplementowane, może to spowodować efekt kuli śnieżnej w kierunku pełzającego featuryzmu.

W rezultacie nie powinieneś po prostu prototypować ... ani pisać od razu czystego, zoptymalizowanego i udokumentowanego kodu, pamiętając, że jeśli w pewnym czasie nie będzie to opłacalne - zostanie porzucone.

Napisz kod, którego potrzebujesz teraz, wiedząc, że możesz najlepiej zaspokoić potrzeby dnia dzisiejszego i jutra.

Dakotah North
źródło
4
Chociaż nie jestem fanem pełnego TDD, zawsze jest to dobra rada, ponieważ przestrzeganie TDD zmusi cię do napisania czystego, dobrze udokumentowanego kodu.
Wayne Molina
1
Myślę, że miał na myśli to, że porzuciłby cały projekt, jeśli się nie powiedzie. Jeśli to prawda, ta odpowiedź nie wydaje się różna od „napisz czysty kod”.
Jeremy
@Jeremy, zakładasz, że trafiłeś w moją odpowiedź. Ale ta odpowiedź nie jest taka sama. Opiera się na ścisłym sposobie programowania, podczas gdy inny opiera się na doświadczeniu, na pewno wyglądają w niektórych przypadkach podobnie, ale to nie to samo :) dobrze przynajmniej z punktu widzenia :)
JackLeo
1
@JackLeo Myślę, że chodzi o to, że po osiągnięciu pewnego poziomu doświadczenia przestaje istnieć różnica między „kodem, nad którym ciężko pracowałem”, a „kodem, który właśnie napisałem”.
Ant P
@AntP Rzeczywiście.
Ciekawie
16

jak zwykle...

To zależy

Jeśli prototypujesz w celu zmniejszenia ryzyka lub ujawnienia nieznanego, po prostu koduj go i spodziewaj się, że porzucisz go po zakończeniu

Jeśli prototypujesz w celu iteracyjnego udoskonalenia, po prostu koduj i spodziewaj się częstej modyfikacji i refaktoryzacji

Jeśli zaczynasz pisać rzeczywisty produkt, ale nazywasz go prototypowaniem, abyś był leniwy , nie bądź leniwy i napisz go dobrze za pierwszym razem

Steven A. Lowe
źródło
2
+1 świetny post! Dodam, że chociaż po opracowaniu tej funkcji może się to wydawać bezużyteczne, NIGDY nie wyrzucaj swoich prototypów. Zawsze kontroluję źródła każdego prototypu, nad którym pracuję, ponieważ czasami odsyłam do nich w celu uzyskania wskazówek i wskazówek.
wałek klonowy
1
@maple_shaft: tak, „wyrzucanie” jest metaforyczne, ponieważ w „niekoniecznie próbuj go refaktoryzować, planuj przepisanie go”
Steven A. Lowe
2
Mówię, bądź leniwy i napisz to dobrze za pierwszym razem, abyś nie musiał wracać i odwiedzać go później.
Blrfl
Trzecie zdanie uczyniło mój dzień.
Christopher Francisco
10

Jeśli prototypujesz, dlaczego myślisz o czystym kodzie? Sam pomysł prototypowania polega na tym, że ma on udowodnić koncepcję lub pomysł, a następnie zostać wyrzucony.

Nie zgadzam się z większością wszystkich tutaj, mówiąc, że jeśli już myślisz o wyborze między pisaniem czystego kodu lub zrobieniem czegoś szybko do prototypowania, wybierz ten drugi. Zwłaszcza, gdy mówisz o wczesnym rozwoju. Nie mówię, że nigdy nie pisz czystego kodu, mówię, wypuść pomysł, zobacz, że to jest kierunek, a następnie wróć, posprzątaj - refaktorem.

Jako programiści za pierwszym razem jesteśmy tak przyzwyczajeni do robienia rzeczy i sprzątania, że nie zdajemy sobie sprawy, że nie dostarczamy kodu, to rozwiązanie problemu .

Myślę o kodowaniu, gdybym pisał artykuł:

Pisząc artykuł, zaczynamy gdzieś, szkicujemy pomysły, kontury itp. Nie będzie on zawierał wszystkich szczegółów ani nie będzie miał w nim żadnego skończonego wyglądu - jest to zasadniczo pierwszy szkic, a następnie drugi i tak dalej. Wiele zostanie przepisanych, zastąpionych i / lub nawet usuniętych po drodze na bardziej wyrafinowany i wykończony papier. (Oczywiście ta analogia nie idzie tak daleko, że można powiedzieć, że kod jest naprawdę zawsze ukończony lub ostateczny jak papier).

gąbka
źródło
+1 Bardzo dobra odpowiedź :) zdarzało mi się bardzo dużo na początku, więc skakanie po dużych projektach może powodować to samo ... tego się boję.
JackLeo,
„Jako programiści oprogramowania jesteśmy tak zajęci robieniem rzeczy po raz pierwszy i czyszczeniem, że nie zdajemy sobie sprawy, że nie dostarczamy kodu, to rozwiązanie problemu”. Powiedziałbym, że jest na odwrót: „Nigdy nie mamy czasu, aby zrobić to dobrze, ale zawsze mamy czas, aby to zrobić”.
Christopher Francisco
6

Istnieją dwa rodzaje prototypowania:

  • Ewolucyjny prototyp, który ewoluuje poprzez ulepszenia i poprawki, aby stać się produktem końcowym.
  • Prototyp jednorazowego użytku, który istnieje tylko po to, aby gromadzenie wymagań i przekazywanie informacji zwrotnych przez klientów były bardziej efektywne na wczesnych etapach projektu, a następnie całkowicie odrzucane, a rozwój produktu końcowego rozpoczyna się od zera.

Według Capers Jones, ewolucyjne prototypy wytwarzają produkty końcowe niskiej jakości, które będą wymagały znacznie więcej wysiłku i dłuższego czasu, aby osiągnąć stabilność.

Jeśli więc myślisz o prototypowaniu, aby klient mógł zobaczyć coś tak szybko, jak to możliwe, aby uzyskać lepszy pomysł i więcej szczegółów na temat wymagań, lepiej być prototypem jednorazowego użytku, a później opracować czysty kod. Jeśli nie możesz sobie na to pozwolić, napisz czysty kod od samego początku i zachowaj go ostrożnie, ale jak sugerują inni, nie optymalizuj i nie dodawaj rzeczy, dopóki ich nie potrzebujesz.

M.Sameer
źródło
Bardzo dobra uwaga, to znaczy do pokazywania różnych rodzajów prototypów, nie myślałem o tym :) Jedzenie za trochę dla mnie tutaj :)
JackLeo
Zgadzam się z celem!
Richard Topchiy
Duże ryzyko związane z prototypem jednorazowym polega na tym, że kierownictwo będzie miało problem ze zrozumieniem, dlaczego wersja produkcyjna powinna trwać tak długo w porównaniu z prototypem i dlaczego praca nad prototypem powinna zostać „zmarnowana”. Oczywiście, jeśli jest to twój własny start-up, nie ma takiego zarządzania, więc to znacznie ułatwia.
Jan Hudec
5

Niechętnie usprawiedliwiam brudne kodowanie z jakiegokolwiek powodu. Z mojego doświadczenia wynika, że ​​ludzie, którzy twierdzą, że szybkie i brudne usprawiedliwienie tworzenia prototypów mają takie podejście do każdego kodu, w tym do produkcji. Jeśli ktoś tworzy niechlujny prototyp, tworzy bałagan w dowolnym kodzie. Prototypowanie nie oznacza brudnego kodowania, oznacza uproszczone założenia do testowania najważniejszych przypadków użycia. Kod może nie zostać formalnie przetestowany lub zadbać o wszystkie szczegóły, ale nadal powinien być dobrze zaprojektowany i dobrze wdrożony. Czystość jest oznaką kompetencji, kompetentni programiści odczuwają naturalne obrzydzenie do niechlujnego kodu, bez względu na jego cel.

Gene Bushuyev
źródło
Tylko jedną rzecz, o której zapomniałem wspomnieć. Widziałem to raz po raz, ludzie pisali szybko i brudno dla celów „prototypowania” i stało się bolesne i brzydkie dla celów produkcyjnych. Odkąd skończyło się i działało, ludzie ciągle dodawali do niego bandaże, układając bałagan na bałaganie.
Gene Bushuyev
Masz rację - „po co pisać, jeśli to działa?” jest problemem dla wielu młodych firm, widzę to nawet na moim obecnym stanowisku pracy, gdy duże firmy używają 10-letniego CMS, którego uaktualnienie do dzisiejszych standardów jest bolesne ... Dlatego zadaję takie pytanie, nie „ nie chcę tutaj popełnić błędu. Chociaż twoja odpowiedź brzmi głównie, że szukam wymówki, aby napisać niechlujny kod. Nie. Sunpech i M.Sameer zrozumieli mój punkt widzenia. Prototyp ma zrobić coś, aby zobaczyć, jak zareaguje świat. Jeśli to działa - zrób to dobrze.
JackLeo,
1

Napisz czysty, zoptymalizowany i udokumentowany kod od samego początku. Nie jestem w stanie tego zrobić i to jest prawdziwy problem. Nie jestem programistą, ale pracowałem w firmach zajmujących się tworzeniem oprogramowania na wysokich stanowiskach kierowniczych wobec klientów, a ponieważ dają mi wiele dobrych pomysłów, od czasu do czasu buduję prototyp. Niemal za każdym razem, gdy prototyp ten był przekazywany deweloperowi, który „wyczyścił go” i przekształcił w produkt wysyłkowy. Kiedy sprawdzę źródło, nadal będzie to 80-90% mój gówniany kod.

Geordie Korper
źródło
0

Mój kolega entuzjastycznie popiera wielokrotne prototypowanie, z zastrzeżeniem, że trzeba mieć wystarczająco dużo dyscypliny, aby wyrzucić każdy prototyp i napisać od nowa - i nie tylko to, upewnij się, że nie wpływają na niego szczegóły wdrożenia ustalone podczas ostatniej rundy , ponieważ to, co potem kończy się, to pisanie tego samego prototypu w trywialnie innym stylu kilka razy. Poważnie zasugerował, że jeśli naprawdę jesteś przywiązany do jakiegoś genialnego fragmentu kodu, którego prawdopodobnie nie możesz odrzucić, że powinieneś go wydrukować, usunąć repozytorium kontroli kodu źródłowego i opublikować wydruk dla siebie - zniknie wystarczająco długo, aby nie mógł zinfiltrować następnej iteracji.

Tom W.
źródło
ten post jest raczej trudny do odczytania (ściana tekstu). Czy mógłbyś edytować go w lepszym kształcie?
komar
Czy możesz zasugerować, co według ciebie jest problemem? Być może zdania są za długie, ponieważ właśnie zauważyłem, że są tylko dwa z nich. Coś jeszcze?
Tom W
-1

Zawsze możesz zacząć od uczynienia go (w ogóle) działającym, a następnie zrewidować go, aby był czysty, a następnie uczynić go szybkim / małym, jeśli ma to sens ekonomiczny. Zacznę od niektórych eksperymentów, które wyrzucisz, a następnie TDD powrócą do istnienia, gdy będziesz miał kontrolę nad tym, co działa.

tottinge
źródło
-1

Obie są dobre. Oba lubię. Nie zaprzeczają sobie.

Lubię prototypować. Prototypowanie rozwija moje umiejętności kreatywne. Testuję wiele możliwych rozwiązań. Zrobienie tego szybko daje mi możliwość przetestowania wielu możliwych sposobów rozwiązania problemu.

Lubię pisać czysty, dobrze przetestowany kod. Rozwija moje podstawowe umiejętności. Zazwyczaj wybieram jeden z prototypów i albo go ulepszam, albo przepisuję od zera.

Ale nigdy nie należy mylić prototypu z kodu produkcyjnego. Prototyp nigdy nie powinien wejść do produkcji. Zawsze powinien być oznaczony jako prototyp. W najlepszym razie wykonaj wszystkie prototypy we własnym oddziale.

FolksLord
źródło
-2

Zazwyczaj twierdzę, że skrajności są prawie zawsze złe.

Radzę zachować równowagę między czystym, dobrze udokumentowanym i prototypowaniem. Kiedy tworzysz bibliotekę lub platformę, nie masz doświadczenia z tym, że bardziej podążam w kierunku prototypowania. Jest to szczególnie prawdziwe na początku i dla platform, np. Androida lub kontenerów, które umieszczają cię w gorsecie. Oznacza to, że wdrażasz ich interfejsy, a oni cię wzywają.

Z własnego doświadczenia wynika, że ​​większość kodu nie żyje zbyt długo. To powiedziawszy, zacznij szybko, wdrażając swoją funkcję. Kiedy prędzej czy później (przez większość czasu wcześniej) musisz przerobić / przeredagować istniejący kod ze względu na następną funkcję, którą uporządkujesz, szczególnie części, z którymi praca jest skomplikowana. Zwróć uwagę na odpowiednie automatyczne testy, aby umożliwić bezproblemową refaktoryzację. Odnosząc się do wyżej wymienionych platform, takich jak Android: często sprawiają, że automatyczne testowanie nie jest tak łatwe ze względu na ścisłe sprzężenie i brak projektu umożliwiającego testowanie. Następnie możesz podnieść bazę testową na wyższy poziom, np. Testy integracyjne.

Napisałem artykuł, który może dać kilka wskazówek na temat rozpoczęcia: https://medium.com/@ewaldbenes/start-lean-why-its-best-to-split-your-next-coding-project-by-feature-70019290036d

Ewald B.
źródło