Zauważyłem u siebie pewną przypadłość i nie wiem czy się cieszyć czy raczej ja zwalczać. Siadając do kodzenia (mowa tutaj o domowych projektach w celach edukacyjnych), zawsze najpierw zastanawiam się nad architekturą, mniej więcej projektuje sobie system który chcę wykonać, ale podczas pisania co chwile wpada mi do głowy " a może by tak to zrobić inaczej ". Co rozwala cały poprzedni koncept. Efektem jest to, że zamiast dokończyć jakiś projekt, może nawet nie do końca idealnie napisany, ciągle siedzę przy jego jednym komponencie, poprawiając go raz za razem, a bo tutaj któraś z zasad SOLID jest złamana, tutaj mogłem użyć innego mechanizmu, i po prostu refactoruje do znudzenia zamiast iśc do przodu. No i pytanie, czy jeżeli faktycznie nie gonią mnie żadne deadline'y, to warto poświęcić więcej (dużo) czasu na kawałek kodu, niż napisać większy kawałek systemu i dopiero jak coś zacznie źle działać to zacząć refactor?
Często mam dokładnie to samo. Mam pomysł na projekt, wszystko rozpisane, wiem ze temat się może sprzedać a mam zrobione kilka procent bo ciagle rzeźbie i poprawiam to co już mam. Jak napisze X testów i prawie większość pokryje to zaraz wymyślam nowa architekturę, nowe podejście i testy w większości przestają działać bo np scope klas się zmienił i się wszystko wywala a mimo to poprawiam te testy przez pare godzin by zaraz znowu je rozwalić. Generalnie tak to robiłem ale ostatnio doszedłem do wniosku ze to jakiś horror i ze lepszy system który działa nieidealnie niż nie działa wcale. Podobno tworcy albo ktoś z twórców linkedin powiedział kiedyś ze jeśli pracowałeś nad swoim produktem i nie wstydziłeś się jego pierwszej wersji to znaczy ze za długo nad nią pracowałeś. Generalnie wygrywają ci którzy potrafią trochę odpuścić i zaryzykować. Uważam ze podejście typu zrobię byle jak byle działało jest głupie ale z doświadczenia wiem ze lepsze jest wrogiem dobrego i nie ma co przeginać.
To jest właśnie sztuka która trzeba opanować by zaistnieć na rynku ze swoimi projektami. Ja aktualnie mam rozpisany spory projekt który będę monetyzował od pierwszej wersji, jakbym miał wypościć cały nawet nieidealnie to bym siedział nad tym ze 2 lata, ale podzieliłem go sobie na modułu na tyle, że jeszcze w tym roku wyjdzie 1 może 2 iteracje w wersji produkcyjnej i już będzie gdzieś tam budował swoją markę.
edit Pamiętajcie, że dla usera końcowego nie liczy się jak pięknie nazwaliście klasy, tylko co tam może zrobić. nie traćcie czasu na optymalizacje jeśli nie trzeba, jak z logów będzie wynikać, że niedługo obciążenie będzie za duże to wtedy siadasz i optymalizujesz albo zwyczajnie przenosisz na szybszą maszynę, w zależności co się bardziej opłaca.
#>bądź kodziarzem u janusza
#>narzekaj że janusze nie chcą ładnego kodu i testów jednostkowych, bo liczy się produkt
#>bądź kodziarzem i chciej zarobić pieniądze na własnym projekcie
#>nie ma czasu na ładny kod i testy, liczy się produkt
xDDD
Nikt nie mówi, żeby kod był spadżetti, ale kod można poprawiać w nieskończoność, a to przecież nie o to chodzi, trzeba mieć umiar we wszystkim, no chyba, że celem jest tylko piękny kod no ale wtedy raczej nigdy projekt nie ujrzy światła dziennego. Programowanie to sztuka kompromisów.
zawsze najpierw zastanawiam się nad architekturą, mniej więcej projektuje sobie system
który chcę wykonać, ale podczas pisania co chwile wpada mi do głowy " a może by tak to zrobić inaczej ".
Co rozwala cały poprzedni koncept
To akurat ok, tylko że moim zdaniem za wcześnie próbujesz zrobić produkcyjną wersję apki. Czemu nie potraktować pierwszych prób zaimplementowania aplikacji jako zwykłych prototypów? I już na wstępie się naszykować, że to zmienisz albo napiszesz od nowa? Pisanie kodu jest szybkie, to proces twórczy i zdobywanie "know how" zajmuje czas.
Do mnie przemawia hasełko "Make it work, make it right, make it fast"
http://wiki.c2.com/?MakeItWorkMakeItRightMakeItFast
Najpierw zrobić byle jak, byle działało (taki prototyp, "proof of concept"). I zebrać wiedzę techniczną i projektową (np. widzisz, jakie problemy się pojawiły podczas robienia tego prototypu, to już wiesz, czego unikać).
I potem dopiero myśleć o refaktoringu, albo o przepisaniu tak, żeby napisać lepsze rozwiązanie z lepszą architekturą (make it right). A dopiero na końcu ogarniać optymalizacje, końcowe szlify, ładne ikonki itp.
Są też inne motywujące powiedzonka "Done Is Better Than Perfect" oraz "Premature optimization is the root of all evil" (a właśnie to robisz - próbujesz przedwcześnie zoptymalizować komponenty pod kątem jakości kodu).
Efektem jest to, że zamiast dokończyć jakiś projekt, może nawet nie do końca idealnie napisany,
ciągle siedzę przy jego jednym komponencie, poprawiając go raz za razem, a bo tutaj któraś
z zasad SOLID jest złamana, tutaj mogłem użyć innego mechanizmu, i po prostu refactoruje do znudzenia zamiast iśc do przodu
Rozumiem motywację, ale takie podejście jest nierealistyczne. Rzadko kiedy aplikacja składa się z pełni niezależnych komponentów. Zwykle jest tak, że masz tych komponentów całe stado, i cały system połączeń między nimi.
Więc skupianie się na 1 komponencie może sprawić, że cały system słabo zaprojektujesz a potem ten perfekcyjny kod 1 komponentu i tak będziesz musiał zaorać, po tym jak się okaże, że cały system jest źle zaprojektowany i żeby coś zmienić na większą skalę, musisz zaorać ten niby perfekcyjny komponent.
eL napisał(a):
testy w większości przestają działać bo np scope klas się zmienił i
Też tak miałem, dlatego teraz staram się pisać testy na większym poziomie abstrakcji. Tak, żeby testy nie uzależniały się od tego, w jaki sposób są porobione zależności między klasami w projekcie, ani żeby nie pisać testów do każdej klasy/do każdego modułu, tylko testować wiele rzeczy pośrednio, nie uzależniać testów od szczegółów implementacyjnych.
Z drugiej strony nie zawsze trzeba pisać testy. Jak piszesz prototyp, który i tak pójdzie do wywalenia, to bez pisania testów się obejdzie.