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.

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.

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

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

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.

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.

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.

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.

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.

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.

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