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-03 21:35
1

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


Limitations are limitless

> ##### Ola Nordmann napisał(a)
> Moim językiem ojczystym jest C++ i proszę uszanować to, że piszę po polsku.

Pozostało 580 znaków

2016-02-04 13:09
1

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.

Pozostało 580 znaków

2016-02-05 14:54
1

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.

Pozostało 580 znaków

2016-02-05 15:53
1

Ja z kolei opierałem się sporo na tej książce, http://helion.pl/ksiazki/refa[...]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.

edytowany 1x, ostatnio: axelbest, 2016-02-05 15:53

Pozostało 580 znaków

2016-02-05 16:17
Mały Kot
1

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

Pozostało 580 znaków

2016-02-05 16:50
1

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ści Ci pomogły? loll - karolinaa 2016-02-05 16:58
Jakie maści, co wy? Lintery! http://sjp.pl/lintery - aurel 2016-02-08 10:49
Aaaaa, no to teraz wiele wyjaśnia! :D - XardasLord 2016-02-08 14:02

Pozostało 580 znaków

2019-03-05 20:51
0
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 ?

Jeśli napisanie czystego kodu w legacy codzie, będzie wiązało się z refaktoryzacją i trwało tydzień, a klient zapłaci np. za 4h (bo to w końcu tylko jeden malutki feature) to ma się do wyboru - albo zmienić firmę, albo pisać kod tak jak napisał Mały Kot. - axelbest 2019-03-05 22:33
@axelbest: tak po prawdzie najlepszy kod udawało mi się pisać w legacy. biznes już doświadczony co to znaczy na szybko i ma czas i kasę, bo system na produkcji. Więc prawie zawsze szacowałem w stylu, mogę to zrobić dobrze w 2 dni, ale chętnie jeszcze posprzątam dookoła w dodatkowe 2. Praktycznie zawsze była wybierana wersja b. Btw. na szybko byłoby w 4h, ale tego nie mówiłem, chyba, że przy dirty fixach na niedziałającą produkcję. Ale nawet wtedy normalnie było potem sprzątanie. Btw. są też legacy bez pieniędzy i to faktycznie równia pochyła - trzeba uciekać. - jarekr000000 2019-03-07 08:49
Ja akurat miałem przyjemność pracy przy legacy, gdzie były pieniądze. Zgadzam się w 100%. - axelbest 2019-03-07 08:54

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