Ot, taki problem początkującego

2011-10-15 18:13
wartek
0

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?

Pozostało 580 znaków

2011-10-15 18:52
1

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


Masz problem? Pisz na forum, nie do mnie. Nie masz problemów? Kup komputer...

Pozostało 580 znaków

2011-10-15 19:16
Ace4ur
0

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.

Pozostało 580 znaków

Liczba odpowiedzi na stronę

1 użytkowników online, w tym zalogowanych: 0, gości: 1, botów: 0