Jakosc kodu, clean code - jak sie go nauczyliscie

Odpowiedz Nowy wątek
2016-02-02 09:32
0

Takie raczej szybkie pytanie. Juz troche w sumie doswiadczenia komercyjnego mam, a mimo to ciągle mi sie wydaje ze nie za bardzo idzie mi pisanie naprawde dobrego jakościowo kodu, glownie przez niedbalosc o to w mojej obecnej firmie. Nie mówie tutaj o jakichś architekturach, ale o takim prostym DRY, KISS, SRP, Clean Code.

Takze mam pytanie do tych którym udało sie "wyjsc ze spaghetti". Czy dobrym rozwiazaniem byloby np zmiana firmy na taka w ktorej bili by mnie batem za pisanie badziewia i niestosowanie wzroców, czy moze jest to tylko kwestia walki z lenistem, czy moze dobrym rozwiazaniem jest np wieksze zaangazowanie w jakis nowoczesny projekt Open Source? Co u was zadziałało?

to marne to twoje doświadczenie skoro cały czas odwalasz fuszerkę a wytłumaczenie "bo inni tak robią" jest słabe - szarotka 2016-02-02 10:41

Pozostało 580 znaków

2016-02-02 09:51
4

Niech Cię biją batem :) ja u siebie nie mam bata, ale staram się bić innych linijką (ale tak na sztorc). A tak na serio... to staraj się wymagać najwięcej od samego siebie. A jak się zapominasz to potem refaktoryzuj, z czasem zobaczysz że nie warto pisać na "odpie...l", bo będziesz miał więcej roboty. U mnie zadziałało używanie narzędzi do sprawdzania poprawności kodu, które wychwytuje pewne "brzydkie zapachy" w kodzie :)

edytowany 1x, ostatnio: axelbest, 2016-02-02 09:54
Można wiedzieć jakie to narzędzia?:) - Kooneer 2016-02-03 17:39
PhpCodeSniffer, MessDetector, CopyPasteDetector, PhpStandardFixer - axelbest 2016-02-03 17:48
Podziękował - Kooneer 2016-02-03 21:16

Pozostało 580 znaków

2016-02-02 10:12
4

Spróbuj po np. pół roku dodać w swoim większym projekcie nową, albo zmodyfikować istniejącą funkcjonalność mając na to krótki deadline, im większy poziom wkurwienia będzie temu towarzyszył tym szybciej w głowie się utrwali myśl, że nie warto robić czegoś "na szybko", u mnie podziałało i staram się teraz za każdym razem dbać o jakieś przyzwoite minimum jakości kodu :D
Zmiana firmy na taką, która kładzie duży nacisk na jakość pewnie przyspieszy ten proces, bo jednak człowiek nie lubi być krytykowany więc po kolejnych code review gdzie informacja zwrotna to długa lista uwag nt. jakości tego co zostało napisane będzie się dążyło do stanu, w którym będzie jak najmniej tych uwag od osób sprawdzających Twój kod.


Pozostało 580 znaków

2016-02-02 10:28
3

Pisz unit testy ze 100% pokryciem. Napisanie takiego testu dla słabego kodu jest bardzo trudne więc jak widzisz ze nie wiesz jak sensownie zrobić test (tak zeby nie miał 1000 linii) to znaczy że kod jest do refaktoringu.


Na PW przyjmuje tylko (ciekawe!) zlecenia. Masz problem? Pisz na forum, nie do mnie.

Pozostało 580 znaków

2016-02-02 12:26
eL
2

Koledzy z pracy którzy nie przepuszczą pull requesta z chociażby jedną literówka czy głupotą w kodzie idealnie wspomagają proces pisania czystego kodu ;).
Warto też moim zdaniem czytać ogólnodostępne biblioteki.

Pozostało 580 znaków

2016-02-02 13:07
6

Juz troche w sumie doswiadczenia komercyjnego mam, a mimo to ciągle mi sie wydaje ze nie za bardzo idzie mi pisanie naprawde dobrego jakościowo kodu, glownie przez niedbalosc o to w mojej obecnej firmie.

Doświadczenie komercyjne != pisanie czystego kodu.
Są firmy, w których się dba o to, są firmy, w których się na to kładzie lachę. Ty trafiłeś do takiej, gdzie się kładzie lachę. Wnioski sam sobie wysnuj...

Nie mówie tutaj o jakichś architekturach, ale o takim prostym DRY

DRY - to akurat najprostsze. Wystarczy:

  • nie stosować metody kopiuj-wklej
  • zamiast robić zmienne typu zmienna1, zmienna2, zmienna3, zastosować tablicę/listę
  • starać się ogranicząć ify. Szczególnie, jak masz w jednej funkcji z 5 podobnych ifów, które niewiele się różnią zarówno pod kątem warunku, jak i tego co jest wykonywane jeśli warunek jest prawdziwy -- to wiedz, że coś się dzieje i że jest tu code smell...
  • wydzielać powtarzającą się logikę gdzieś (np. do klasy, do funkcji, ale czasem wystarczy do zwykłej pętli)
  • jeśli potrzeba, to wydzielone funkcjonalności wsadzić do osobnych plików
  • pamiętać o decouplingu
  • umieć postrzegać podobieństwa różnych use'caseów. Jeśli masz mysz, kota i psa, to nie musisz rozpatrywać każdego przypadku z osobna, wystarczy, że gdzieś zrobisz jakąś strukturę danych dla każdego zwierzęcia, gdzie wypiszesz cechy dystynktywne dla każdego zwierzaka (np. pokarm, wygląd itp.) a potem będziesz pobierać te dane z tej struktury. Uogólniaj po prostu.
    czyli nie:
    PSEUDOKOD
    if (kot) {
    jedzMieso()
    }
    if (mysz) {
    jedzSer()
    }

    tylko

    PSEUDOKOD
    kot.jedzenie = 'mięso';
    mysz.jedzenie = 'ser';
    ...
    zwierze = kot
    jedz(zwierze, zwierze.jedzenie);

    może to banał, ale często widzę, że ludzie tego nie umieją uogólniać, nawet zaawansowani rzekomo programiści. Łatwiej jest im zrobić kopiuj wklejkę i zmodyfikować niż stworzyć strukturę/słownik/klasę/obiekt z danymi.

, KISS.

KISS - to akurat najtrudniejsze. Niestety dopiero dochodzę do tego etapu, więc nie mam sprawdzonych recept. Zazwyczaj dochodzę do zachowania zasady KISS po iluś próbach przepisania czegoś od zera. Niestety nie zawsze mogę sobie na to pozwolić (w projektach komercyjnych, gdzie goni deadline często trzeba zrobić jakkolwiek, zamiast najlepiej).

Anyway, jest taki fajny cytat o zasadzie KISS:
Doskonałość osiąga się nie wtedy, kiedy nie można już nic dodać, ale kiedy nie można nic ująć.
Antoine de Saint-Exupéry

zazwyczaj na początku człowiek napakuje niepotrzebnie kod podobnie do tego, jak się pakuje wędliny wodą, żeby więcej ważyły. dopiero potem się zauważa, że nie chodzi o to, ile ficzerów czy ile wzorców projektowych się włoży do kodu, ale raczej bardziej ważne jest to, żeby w projekcie znajdowało się tylko to, co naprawdę potrzebne.

Nie wiem w jakim języku programujesz, ale np. jesli chodzi o JavaScript to radziłbym się zainteresować projektami Dana Abramova (Redux i toole do niego), bo to gość, który robi biblioteki właśnie w stylu KISS (przynajmniej na poziomie koncepcji oraz ich używania, co do kodu to mało zaglądałem, ale też ponoć dość prosty kod pisze).


((0b10*0b11*(0b10**0b101-0b10)**0b10+0b110)**0b10+(100-1)**0b10+0x10-1).toString(0b10**0b101+0b100);
edytowany 4x, ostatnio: LukeJL, 2016-02-02 13:17

Pozostało 580 znaków

2016-02-02 13:30
2
Sarkofag89 napisał(a):

Czy dobrym rozwiazaniem byloby np zmiana firmy na taka w ktorej bili by mnie batem za pisanie badziewia i niestosowanie wzroców

Bicie nie pomoże, jeśli sam nie chcesz tego robić. Znając zasady w teorii, trzeba je po prostu starać się stosować w praktyce. Nawet jeśli w pracy nikt nie kładzie nacisku na jakość, to nie znaczy, że Ty nie możesz pisać dobrego kodu w swoich klasach.


"HUMAN BEINGS MAKE LIFE SO INTERESTING. DO YOU KNOW, THAT IN A UNIVERSE SO FULL OF WONDERS, THEY HAVE MANAGED TO INVENT BOREDOM."

Pozostało 580 znaków

2016-02-02 20:42
1

To zależy co robisz i gdzie. Pomaga mieć otoczenie, które ciągnie Ciebie w górę, a nie Ty otoczenie. Praca z dobrym kodem pozwala się z nim obyć, napatrzeć na niego ;-) i przez to samemu lepiej pisać, gdy już widzisz ciekawe rozwiązania a nie musisz sam do nich dochodzić zawsze.
Jak Twoja praca polega tylko na grzebaniu w spaghetti, to nawet coś nowego robiąc może być ciężko zrobić to dobrze, jeśli masz dopisać tylko kilka linijek i nie możesz zrobić refactoringu. Jak piszesz zupełnie nowe rzeczy, nowe klasy - tutaj masz duże pole do popisu sam. Ciężko od razu dobrze coś napisać, często nawet nie powinno się, tylko powinno to wyjść przez refactoring.

Ja pracowałem z takim spaghetti, że jedynym wyjściem była zmiana firmy.


Pozostało 580 znaków

2016-02-02 22:13
4

Trochę zależy od stopnia rozgotowania tego spaghetti. Jeśli uważasz, że w obecnej pracy jest straszny chaos, inni uważają, że to jedyne słuszne rozwiązanie i brniecie tak dalej, to wiej czym prędzej. Jeśli jest neutralnie tzn. jest jakiś tam bałagan, nikogo to nie rusza, ale jeśli zrobisz po swojemu, to też ich nie ruszy, to możesz w miarę samodyscypliny popróbować pisać porządnie chociaż w swoich obszarach. Niemniej jednak jeśli znalazłbyś firmę, gdzie dają linijką po łapach za słaby kod, to z mojej strony gratulacje i ruszaj tam w podskokach.

Ja zaczynałam od pierwszego przypadku. Aplikacja była już mocno rozbudowana i próby robienia dobrze to byłoby łamanie konwencji. ;) Na szczęście gdzieś na boku udało mi się zakumplować z kimś bardziej doświadczonym, komu jakość kodu się nie podobała, i zaraziłam się jego poglądami. Potem naczytałam się książek, powędrowałam po innych firmach (mniej lub bardziej lepszych) i samo przyszło.


(konto nieaktywne)

Pozostało 580 znaków

2016-02-03 19:00
Zimny Mleczarz
0

Pisz unit testy ze 100% pokryciem.

Straszna bzdura.
Pokrycie testami kodu w 100% zazwyczaj oznacza (a w sumie zawsze oznacza) testy pisanie byle jak i bez jakiegokolwiek sensu.
Wiarygodne i rzetelne testy statystycznie obejmują około 85% kodu.

Pozostało 580 znaków

2016-02-03 19:19
1

To był skrót myślowy -> chodziło mi o 100% pokrycia dla klas dla których w ogóle piszesz testy, czyli dla serwisów i logiki. Względem całego kodu to oczywiście nie będzie 100% bo nikt przy zdrowych zmysłach nie pisze testów dla konstruktorów, setterów, getterów, DTO itd bo to nie ma sensu. Ale jeśli już piszesz test dla jakiegoś serwisu to uważam że jak najbardziej da sie i powinno się zrobić 100% pokrycie kodu takiego serwisu testami.


Na PW przyjmuje tylko (ciekawe!) zlecenia. Masz problem? Pisz na forum, nie do mnie.

Pozostało 580 znaków

Odpowiedz
Liczba odpowiedzi na stronę

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