Co powinienem zrobić, gdy mój kod pachnie?

Jestem początkującym programistą i często, kiedy pracuję nad własnymi projektami, zawsze mam wrażenie, że konstrukcja mojego kodu nie jest najlepsza z możliwych, i nienawidzę tego uczucia. W końcu spędzam czas na szukaniu rzeczy, ale potem łatwo mnie przytłacza wiele szczegółów, takich jak wzorce projektowe do wyboru i kiedy używać abstrakcyjnej klasy lub interfejsu. Czy powinienem spróbować nauczyć się wszystkiego wszystkiego na raz?

Kilka sugestii:

1. Użyj enkapsulacji do zarządzania złożonością, dzieląc funkcjonalność na odrębne elementy składowe. Udowodnij, że każdy blok działa (za pomocą testów jednostkowych) i możesz go używać, nie martwiąc się o jego wewnętrzne szczegóły.

2. Ucz się i badaj wzorce oprogramowania . Wzorce oprogramowania to wypróbowane i sprawdzone metody wykonywania niektórych typowych, dobrze znanych zadań.

3. Przestudiuj i zrozum struktury danych. Poznaj odpowiednie zastosowania i charakterystyki wydajności dla każdego rodzaju struktury danych.

4. Dobrze znasz swój język programowania, jego mocne i słabe strony oraz jak najlepiej korzystać z jego funkcji.

Nie musisz tego wszystkiego wiedzieć od razu, ale powinieneś przestudiować to wszystko z czasem.

Moja rada: przestań się martwić.

Doświadczenie jest najlepszym nauczycielem, a nie dostaniesz doświadczenia, jeśli nie napiszesz kodu. Również źle zaprojektowane kod, który jest napisany lepiej niż wielki projekt, który jest nie .

Więc napisz więcej kodu. Zakończ swoje projekty. To poczucie, że kod nie jest idealny, jest prawdopodobnie słuszne. I prawdopodobnie będziesz mieć problemy z tym kodem. A kiedy masz te problemy, a następnie chcesz dowiedzieć się dokładnie, dlaczego to było złe. Nauczysz się o wiele więcej z doświadczenia z pierwszej ręki niż z „szukania rzeczy”.

Nie należy też mieć nadziei, że to uczucie „zapachowego kodu” zniknie. W miarę postępów poprawisz niektóre problemy, ale zaczniesz zauważać nowe, bardziej niejasne / zaawansowane.

Jest to powszechny problem z początkującymi programistami. Nie paraliżuj się, myśląc, że wszystko musi być idealne. To najpewniejszy sposób, aby nigdy nie ukończyć projektu. Jedną z najważniejszych umiejętności do nauczenia się jako programista jest różnica między doskonałym a wystarczająco dobrym . Zaakceptuj, że każdy tworzony system można ulepszyć. Skoncentruj się na zakończeniu swoich projektów. Po zakończeniu możesz wrócić i ulepszyć je. W końcu dlatego mamy wersję 2.0.

Czy powinienem spróbować nauczyć się wszystkiego wszystkiego na raz?

Mam nadzieję, że nie. Z drugiej strony powinieneś uczyć się i doskonalić przez cały czas.

Czytaj książki, bierz udział w kursach, zdobywaj kwalifikacje, pracuj nad tym i powinieneś się doskonalić.

Moja najlepsza rada to skupić się na takich podstawach, jak lista sugerowana przez Roberta Harveya. Tworzenie oprogramowania to złożony potwór, którego opanowanie zajmuje lata, zwłaszcza w zakresie dobrego projektowania interfejsu. Naprawdę trudno jest docenić wiele aspektów tworzenia oprogramowania bez ich wcześniejszego doświadczenia. Nawet coś tak podstawowego jak kod komentowania może być niedoceniane. Od samego początku uczysz się pisać dobrze udokumentowany kod. Przyznaję, że dopiero po tym, jak naprawdę byłem trochę zaangażowany w $$ próbę zrozumienia kodu, który napisałem kilka miesięcy temu, zanim naprawdę doceniłem wartość dobrych komentarzy. To samo można powiedzieć o wielu koncepcjach programistycznych. Na przykład enkapsulacja danych, moduły o niskim sprzężeniu i czyste interfejsy.

Najcenniejszym zasobem, z jakim się spotkałem, są moi współpracownicy. Będziesz źle pisać kod. Po prostu to zaakceptuj. To, co robisz, aby upewnić się, że z czasem piszesz lepszy kod, który definiuje cię jako programistę. Na przykład, kiedy zaczynałem pracę, moja firma nie miała żadnych formalnych procedur sprawdzania kodu lub projektu. Podjąłem się poddania mojej pracy krytyce moich starszych współpracowników i szczerze mówiąc, czułem się jak idiota przez większą część pierwszego roku pracy.

Tworzenie oprogramowania to ciągłe uczenie się. Zadawaj mnóstwo pytań, zapoznaj się z kodem, zrozum, dlaczego sugerują to osoby starsze, nie bój się kwestionować ważności sugestii, które dają starsi programiści, a przede wszystkim nie bój się, że się mylicie. W końcu czynnik intymności lub poczucie przytłoczenia mody. Dla przypomnienia ... krzywe uczenia się są do kitu.

• Po pierwsze: Refaktoryzacja (nadal będzie pachnieć, ale będzie trochę lepiej zorganizowana)
• Po drugie: Sprawdź, czy możesz użyć Design Patter, aby dopasować ponownie elementy do twojej logiki.
• Po trzecie: kiedy wszystko zacznie wyglądać lepiej, pamiętaj czas, który spędziłeś na pierwszym i drugim kroku. W ten sposób, kiedy napiszesz jakąś nową funkcję, pomyślisz o tym, robiąc to, a nie jako kolejny proces.

Rzuć okiem na książkę Refactoring: Improving The Design Of Existing Code autorstwa Martina Fowlera. Pierwszą rzeczą, którą powinieneś zrobić, to zmienić kod w celu poprawienia czytelności kodu i zmniejszenia złożoności, aby poprawić jego konserwację.

Kiedy refaktoryzujesz swój kod, już używasz Wzorów projektowych , Kodu enkapsulacji itp.

To jedna z najlepszych książek, jakie kiedykolwiek czytałem na ten temat. Zapewnia wiele przydatnych przepisów.

Dobrym źródłem jest The Pragmatic Programmer . Rozdział „Zepsute okna” opisuje, gdzie się widzisz. Krótka i zwięzła odpowiedź polega na rozwiązaniu problemów.

Kiedy zaczniesz naprawiać swój projekt, pomaga zrozumieć, co ci się nie podoba. Łatwo jest znaleźć niejasne odpowiedzi, takie jak „po prostu wszędzie” lub „dlaczego to zrobiłem?”. Ale nie spiesz się, aby sprawdzić, czy są jakieś wspólne wzorce, których używałeś.

• Dobry projekt ponownie wykorzysta niewielką liczbę koncepcji w całej bazie kodu (ideał to jedna koncepcja, ale w praktyce może być potrzebna jeszcze kilka)
• Dobry projekt ułatwi znalezienie miejsca rozwiązania problemów (zasada DRY, zasada SRP)
• Dobry projekt będzie miał dobre raportowanie błędów (związane z powyższym punktem, ale wezwany jako osobny element, ponieważ jest to często pomijany aspekt)

Kiedy już zdecydujesz, dokąd chcesz się udać, podejmij małe, łatwo odwracalne kroki, aby się tam dostać (tj. O to właśnie chodzi w Refaktoryzacji ). Za każdym razem, gdy poprawiasz kod, rozważ wpływ na resztę kodu. Czy sprawiłeś, że było lepiej czy gorzej? Takie jest przynajmniej moje podejście do wprowadzania porządku w chaos.

Jeśli masz już doświadczenie w programowaniu, dlaczego nie studiujesz niektórych projektów open source, które mają czysty kod ? Możesz spojrzeć na TO pytanie z SO, które zawiera kilka odpowiednich linków.

Ponadto wzorce projektowe są obowiązkowe - pomyśl o tym, cała idea posiadania wzorów polega na rozwiązywaniu znanych problemów bez ponownego wymyślania koła lub pisania błędnego kodu.

Wreszcie wygląda na to, że potrzebujesz odrobiny funkcjonalnego programowania, aby oczyścić głowę. Na początek zajrzyj do Haskell lub Ocaml.

Jeśli nie jesteś niebezpiecznym potworem, powinieneś znaleźć tak zwanego przyjaciela , który może przejrzeć Twój kod i odwrotnie. Ponadto, jeśli robisz rzeczy, które zostaną ponownie odwiedzone lub po prostu nadzorowane przez innych, dobrym pomysłem jest zrobienie tego lepiej.

I nie zapominaj, że programowanie zaczyna się przed kodowaniem, zawsze powracaj do swoich pomysłów, planów. Jeśli twój plan jest zły, jego radością jest jego wyrzucenie: właśnie zaoszczędziłeś frustracji związanej z wyrzucaniem wiązki kodu (i czasu jego stworzenia) w oparciu o zły plan.

Radzę poważnie potraktować każdy zapach i spróbować go naprawić. Istnieje wiele dobrych książek na ten temat (czysty kod i GOOS to najlepsze IMHO). Ale więcej niż książki chodzą na konferencje, aby wysłuchiwać i dyskutować z innymi ludźmi oraz w społecznościach internetowych (lista mailingowa, grupy). Jeszcze lepiej spróbuj dołączyć do lokalnego xxug (dotnetug, jug, xpug itp.) Lub go znaleźć.

Dyskusja z innymi programistami to jedyny sposób, który naprawdę mogę poprawić (chyba że masz szczęście, aby współpracować z innymi programistami).