Jakosc kodu, clean code - jak sie go nauczyliscie

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?

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 :)

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.

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.

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.

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

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.

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.

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.

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.

Różne materiały np.
Mi najwięcej jednak dało code review, chociaż to akurat trochę, dziwne, bo widzę drzazgę w czyimś oku nie widząc belki w swoim - jak mam zrobic komus CR to dostrzege dużo, ale mój kod to wiadomo...idealny xD
Do tego zawsze może wrzucić kod w jakiegoś sonara i zobaczyć co tam wypluwa

Klep dużo kodu, jakość przyjdzie z czasem. Gdy już osiągniesz dobry poziom w klepaniu, to poznasz przy okazji biblioteki/frameworki, które nauczą Cię pośrednio pisać dobry kod. Na pewnym etapie rozwoju poznasz też zapewne paru wymiataczy, którzy będą po Tobie poprawiac 90% kodu, co mało kto znosi dobrze :D Wtedy powstanie to tarcie, które spowoduje, że staniesz się porządnym developerem.

Na początek polecam przeczytać "Czysty Kod" - Robert C. Martin.
Poza tym polecam zapoznanie się jakimś standardem kodowania i trzymaniem się go. Przeglądanie projektów open sourcowych.

Potem to jest kwestia dyscypliny, dbałości o szczegóły i czasu.

Ja z kolei opierałem się sporo na tej książce, http://helion.pl/ksiazki/refaktoryzacja-ulepszanie-struktury-istniejacego-kodu-martin-fowler-kent-beck-john-brant-william-opdy,refuko.htm
Nie wiem jak inni programiści - ale o dziwo, jej lektura najlepiej mi wchodziła podczas "posiedzeń" :D
Może nie jest to typowa książka o clean code - ale refaktoryzacja chyba jako tako wchodzi w skład tego pojęcia.

Clean code to pojęcie bardzo względne.

W każdym razie im czystszy kod będziesz tworzył tym trudniej będzie Ci zaakceptować pracę innych osób i tu nie chodzi, że im się nie chce, że nie umieją (choć tak też może być), lecz o to, że w mniejszych projektach nie zbyt wiele czasu na takie drobnostki, a w większych jest już trochę za późno, żeby taki czysty kod robić.

Patrząc na moje projekty, tam gdzie stawiałem na jakość/czysty kod/naukę nowych rzeczy to te projekty właśnie kończyły na dnie szuflady. Najlepiej mają się tylko te, które faktycznie robią coś pożytecznego, wtedy jak trzeba to się je poprawi i bólu nie ma.

Dlatego zarówno z perspektywy pracy jak i własnych projektów lepiej jest umieć przeprowadzić sprawną refaktoryzację do wzorców i mieć tak z rok doświadczenia nad legacy code. Wtedy zrozumiesz na ile brudny kod możesz pisać, żeby wszyscy byli szczęśliwi :-)

Mi znacznie pomogły lintery maści przeróżnej. Dzięki temu masz tą przyjemną satysfakcję, że na Ciebie nic nie krzyczy w czasie pisania kodu.

Mały Kot napisał(a):

Clean code to pojęcie bardzo względne.

W każdym razie im czystszy kod będziesz tworzył tym trudniej będzie Ci zaakceptować pracę innych osób i tu nie chodzi, że im się nie chce, że nie umieją (choć tak też może być), lecz o to, że w mniejszych projektach nie zbyt wiele czasu na takie drobnostki, a w większych jest już trochę za późno, żeby taki czysty kod robić.

Patrząc na moje projekty, tam gdzie stawiałem na jakość/czysty kod/naukę nowych rzeczy to te projekty właśnie kończyły na dnie szuflady. Najlepiej mają się tylko te, które faktycznie robią coś pożytecznego, wtedy jak trzeba to się je poprawi i bólu nie ma.

Dlatego zarówno z perspektywy pracy jak i własnych projektów lepiej jest umieć przeprowadzić sprawną refaktoryzację do wzorców i mieć tak z rok doświadczenia nad legacy code. Wtedy zrozumiesz na ile brudny kod możesz pisać, żeby wszyscy byli szczęśliwi :-)

Ty tak na serio ?