Słomiany zapał w programowaniu.

Witajcie,

Jako że to jest forum lifestyle, to pomyślalem, że o tym można napisać. Jak mam wene to mogę długo pisać jakiś program, poprawiać błędy aż zacznie dobrze działać. Jeśli uczę się też czegoś nowego jak teraz np. Java EE, a wcześniej było z C++ to tak samo, mogę sobie pisać. Problem zaczyna się gdy jest jakiś... problem, jak nie wiem jak zaprojektować coś żeby było rozszerzalne, żeby było wygodnie robić zmiany. Lub jak uda mi się zrobić jakąś część apki i widze jakis efekt pracy odpuszczam sobie. Nie wiem co z tym zrobić, to działa automatycznie, taka mentalność (dobry wyraz?) Jak sobie z czymś takim radzić?

PS. Nie wiem czy to dobry dział. Po innych wątkach wydaje się ok.

Najłatwiejszym, ale jednocześnie najbardziej przykrym sposobem jest po prostu zmusić się do pisania np. co najmniej pół godziny dziennie. Z tego, co wiem, stosują to czasami autorzy książek, w przypadku programowania też powinno się sprawdzić.

Zastosuj TDD. W TDD (test driven development) pisanie nowych funkcjonalności zaczyna się od pisania małych testów i małych kawałków bez długiego zastanawiania się nad architekturą, a po napisaniu jakiegoś nietrywialnego kodu refaktoruje się go na bieżąco mając świadomość, że duże pokrycie testami zminimalizuje ryzyko wprowadzenia błędów przy refaktoryzacji. Dzięki takiemu podejściu unikasz https://en.wikipedia.org/wiki/Analysis_paralysis

Książka do poczytania: http://helion.pl/ksiazki/tdd-sztuka-tworzenia-dobrego-kodu-kent-beck,tddszt.htm

to zacznij pisać za kasę, od razu jest motywacja aby dokończyć ;)

mogę sobie pisać. Problem zaczyna się gdy jest jakiś... problem, jak nie wiem jak zaprojektować coś żeby było rozszerzalne, żeby było wygodnie robić zmiany.

Bo żeby zaprojektować coś, trzeba często odejść od komputera. Kartka papieru i długopis bywa lepszym narzędziem niż klawiatura. Można też ogólnie zająć się czymś innym, jakimiś innymi życiowymi sprawami, ale np. cały czas myśleć o programie. Wtedy nawet w kiblu czy czekając na autobus możesz być kreatywny.

Lub jak uda mi się zrobić jakąś część apki i widze jakis efekt pracy odpuszczam sobie.

Nie jest to złe. Jak się zrobiło coś konkretnego, to można sobie pooglądać zdjęcia kotów czy zarzucić jakiś serial. Nie o to chodzi, żeby ciurkiem pisać nie wiadomo ile, bo odpoczynek/relaks też jest ważny, żeby zachować energię, kreatywność itp.

poza tym - trzeba niestety też się zmuszać czasem do pisania/zajmowania programowaniem, jeśli chce się coś osiągnąć.

Żeby coś było rozszerzalne musisz wiedzieć jak to będzie rozszerzane. Jeśli robisz coś pierwszy raz to po prostu tego nie wiesz.
Takie rzeczy przychodzą z doświadczeniem.
Jedną z najgorszych rzeczy jest zbytnie przekombinowanie - żeby program był elastyczny.
Program powinien być na tyle elastyczny na ile będzie to potrzebne, ew. niech po prostu wspiera wewnętrzne skrypty (Python, Lua, JavaScript etc).

Żeby coś było rozszerzalne musisz wiedzieć jak to będzie rozszerzane. Jeśli robisz coś pierwszy raz to po prostu tego nie wiesz.
Takie rzeczy przychodzą z doświadczeniem.

I to należałoby napisać pogrubioną czcionką.

Sam często popadam w dwie skrajności - albo robię coś nieelastycznego i popadam w pewnym momencie w ścianę (zmiany są bardzo ciężkie do wprowadzenia), albo robię coś z założenia superelastycznego, czego efektem jest przekombinowanie i nadmierna złożoność.

W obydwu przypadkach kończy się zwykle przepisywaniem wszystkiego albo części aplikacji od nowa, już lepiej (czyli albo bardziej elastycznie, albo bardziej prosto).

Kiedyś uważałem się za kiepskiego programistę z ww. powodów, ale kiedy zobaczyłem komercyjne i open source'owe projekty, które mają te same wady, co moje programy (czyli albo są za mało elastyczne, albo są przekombinowane), przestałem się uważać za kiepskiego. Szczególnie, kiedy widzę że mnóstwo projektów ma tak kiepski design, że je przepisują na nowo (choćby Angular 2).

Nawet jak ktoś pracuje w Google i ma doświadczenie to nie znaczy wcale, że będzie umiał zrobić zaawansowany framework. Każdy projekt jest inny tak naprawdę, inne założenia, inne wymagania, innego rodzaju problemy które programiści spotkają na swojej drodze. Nawet jak się jest doświadczonym programistą to ciągle spotyka się nowe problemy, które wymagają innego podejścia, ciągle trzeba robić kompromisy (jeśli zrobimy coś w sposób X, to będziemy mieć korzyść Y, ale za to możemy się spotkać z problemem Z, który by nie wystąpił, gdybyśmy zrobili inaczej).

Dlatego wiec programista ciągle się uczy w trakcie tworzenia projektu. Możliwe, że Angulara nie dało się od początku dobrze napisać, i słaby design 1ki był konieczny, żeby wyciągnąć z niego wnioski (mam nadzieję, że wyciągnęli, bo z 2ki jeszcze nie korzystałem).

Dlatego ja jak coś robię to stawiam na robienie działających prototypów na początek, bo prototypy się szybko robi, a każdy zrobiony prototyp to pewnego rodzaju edukacja "co się sprawdza, a co nie". (przez to tracę teoretycznie czas na prototypowanie - ale z drugiej strony ten czas i tak programiści tracą później na przepisywaniu gotowej aplikacji/całych frameworków na nowo. A to zajęłoby więcej czasu).