Witam
Mam taki problem - mianowicie kiedy piszę coś złożonego to ZAWSZE łapię się na tym, że rzeczy które zrobiłem mogę zrobić lepiej. I tak z czasem zaczynam je zmieniać, zmieniam je i zmieniam, na rozwijanie kodu i funkcjonalności poświęcam coraz mniej czasu a na poprawianie kodu coraz więcej. Z czasem bywa tak, że i projektu nigdy nie kończę - bo zabawa w kotka i myszkę trwa.
Przykład - mój ostatni projekt, stronka w Javie EE. Jeden servlecik obsługujący żądania, wszystko wyświetla się ładnie, zostało tylko dorobienie jakiegoś edytora treści - i przy zapisywaniu dotarło do mnie, że można zrobić to lepiej. No to poprawiłem nieco kod wczytywania, a przez to trzeba było zmienić serwlet główny. A przy tej okazji, że serwlet główny jest nieco przyduży to i go rozbiłem na dwa (klasę abstrakcyjną i normalną), w którym jeden tworzy stronę (deklaruje doctype'a, wczytuje CSSa, wyświetla menubar itp.) a drugi wyświetla stronę właściwą.
No ale że można i dane poprawić żeby kod był bardziej czytelny, to przerzuciłem się z JDBC na JPA itp. itd.
Ktoś też miał takie problemy? Jakoś je rozwiązuje?
Z mojej perspektywy to wygląda tak:
Pierwsza zasada: najpierw myślimy, potem klepiemy. Problem o którym piszesz występuje bardzo często u ludzi którzy od razu na hurra zaczynają od pisania "prototypowego", tzn klepią malutki kawałek systemu na zasadzie "byleby coś zadziałało" a potem do tego czegoś dopisują kolejne fragmenty. Zamiast poświęcić chwilę czasu na przemyślenie ogólnej architektury systemu.
Druga zasada: jeśli zaczynamy zabawę z daną technologią to czytamy, przynajmniej pobieżnie, dokumentację. Nie chodzi o to żeby ogarnąć wszystko, bo to by często wymagało miesięcy. Chodzi o to żeby mieć świadomość tego co jest gotowe, a co trzeba pisać samemu. Potem przynajmniej nie musimy się łapać na tym że wynajdujemy koło na nowo :P
Trzecia zasada: refaktorujemy od razu kiedy widzimy konieczność (mówie o takim refaktoringu jak wydzielanie interfejsu czy klasy abstrakcyjnej - nie o przepisywaniu połaci kodu), a nie odkładamy tego na później. Bardzo często jest tak że w trakcie pisania jakiegoś fragmentu zauważasz że możnaby pewną rzecz, z której musisz w tej chwili skorzystać, zrobić lepiej, ale zabierasz się za to dopiero po dokończeniu czegoś co pisałeś. W efekcie to co pisałeś korzysta ze starego - złego rozwiązania. Poprawka spowoduje konieczność poprawiania także tych nowych funkcjonalności (i bardzo często ludzie rezygnują wtedy z refaktoringu, uważając że byłoby z tym za dużo roboty).
Czwarta zasada: zawsze pisząc kod myślimy o tym żeby był uniwersalny i łatwo modyfikowalny/rozszerzalny. Oczywiście nie można przesadzać i warto stosować KISS, ale trzeba często zadawać sobie pytanie "co by było gdybym jednak potrzebował mieć jeszcze coś takiego..."
U mnie problem jest podobny.
Ale wpierw kończę program i wtedy analizuje co mógłbym napisać lepiej ale u mnie póki co to programy ograniczaja się do Mac 500 linii i nie są to jakies trudne do ogarniecia ale zwiazane z podstawami.