Dzień dobry
Jaką książkę przeczytać, że pisać czytelny swój kod, tak jak pisze swój kod zaawansowany programista
Co programista w język C, C++, JavaScript, CSS, HTML, Android, Java itp.
Brakuje mi słowa.
Co programista powinien znać, żeby jego program był ładnie, zwięźle, fachowo, według schematu programowania, czytelnie był napisany jego kod.
Dodam, że spotkałem się z jedną osobą, która oznajmiła mi, że nie technicznie, nie fachowo napisałem kod w języku programowania.
Jaką książkę powinienem przeczytać. Przed przeczytaniem książki o podstawie programowania. C, C++, JavaScript, CSS, HTML, Android i Java, żeby mój kod był napisany fachowo czytelny sposób, jak prawdziwi zaawansowani programiści.
0
2
Clean Code? Ale raczej ciężko czytać o tym jak pisać dobry kod, kiedy nie umie się pisać kodu :D
13
Są dwa poziomy pięknego kodu:
- Poziom podłogi - to jest ładnie sformatowany kod, zmienne nazywane krótko ale sensownie np. discount, promotionCode itd., metody krótkie i odpowiedzialne za jedną rzecz, klasy max 350 linii zgodnie z SOLID blah blah blah
- Poziom sufitu - architektura programu jest taka że program jest po prostu prosty i łatwy do zrozumienia. Niestety ten poziom jest ciężko osiągnąć, i nawet mistrzom potrafi się tutaj podwinąć noga. Przykład: git - trzymanie wszystkiego jako snapshotów stanu repozytorium zamiast diffów to był pomysł który sprawił że cały system łatwo było zaimplementować nawet w tak prymitywnym języku jak C.
Poziom podłogi: Clean Code, Code Complete, masa tutoriali na necie i YT bo obie wspomniane książki są już dosyć stare.
Poziom sufitu: Praktyka, czytanie kodu open source, dyskusje z innymi programistami
4
Poziom sufitu: Praktyka, czytanie kodu open source, dyskusje z innymi programistami
No i jeszcze są dwie dobre książki: Clean Architecture oraz Designing Data-Intensive Applications
0
5
Problem jest taki, że o ile można na ten temat pisać książki (np. "Czysty Kod"), to wcale nie znaczy, że przeczytasz książkę i będziesz pisać ładnie. Programiści, którzy umieją pisać dobrze kod, często popełnili mnóstwo błędów po drodze, mnóstwo błędów też widzieli w projektach, nauczyli się też tego, że nie wszystko musi być idealnie, czasem trzeba dokonywać kompromisów. Czyli zdobyli doświadczenie, które ciężko jest ogarnąć "na skróty".
Druga sprawa, że potrzebne jest pewne poczucie estetyki i chęć do poszukiwania prostych rozwiązań. Niestety wiele osób ma nieco inne podejście i zamiast zrobić coś prostego, to kombinuje na siłę, żeby wbić się w pewien schemat "profesjonalnego programisty". A to prowadzi potem do tworzenia rozwiązań, które wyglądają "mądrze", a są przekombinowane (czyli overengineering, programistyczny odpowiednik grafomanii).
Co programista powinien znać, żeby jego program był ładnie, zwięźle, fachowo, według schematu programowania, czytelnie był napisany jego kod.
Dodam, że spotkałem się z jedną osobą, która oznajmiła mi, że nie technicznie, nie fachowo napisałem kod w języku programowania.
To spytaj dlaczego, bo "nie fachowo" to nie jest żadna konstruktywna krytyka, bo może i coś napisałeś nieładnie, ale ta osoba nie udzieliła ci konstruktywnego feedbacku, jeśli powiedziała tylko, że "nie technicznie, nie fachowo".
0
odpowiedź jest prosta -: Darwin, Planck, Einstein
zastanawiam się nad mitologiami
0
0
Xitami napisał(a):
odpowiedź jest prosta -: Darwin, Planck, Einstein
zastanawiam się nad mitologiami
Darwin czyli, że kod ma ewoluować z gorszego na coraz bardziej lepszy.
Einstein, że im czystszy kod, tym szybciej można później dorabiać kolejne ficzery (więc czas się kurczy, to co zajmowało tygodnie, w czystym kodzie zajmuje godzinę). No i też, że istnieje maksymalna czystość kodu (oznaczona literką c , czyli jest to kod czysty jak światło. Bielszy nie będzie).
Planck, czyli stosowanie zasad mechaniki kwantowej do pisania kodu?
2
Książki to teoria, aby się nauczyć pisać czytelny kod należy dawać jego próbki do code-review, słuchać konkretnych wskazówek na temat tego, co w nim nie pasuje ("twoja funkcja xxx jest długa, można by ją skrócić tak i tak" zawsze będzie bardziej kształcące niż ogólna rada "należy pisać krótkie funkcje"), wdrażać te wskazówki i z czasem człowiek się wyrobi.
W Internecie można znaleźć miejsca, gdzie ludzie z dobroci serca recenzują kod początkujących i rzucają im wskazówkami, na przykład Code Review Stack Exchange Jako że kształcące może być również czytanie recenzji cudzego kodu, więc warto poprzeglądać wątki, jakie się tam pojawiają, Od biedy można też wrzucić coś na 4programmers.
0
Ja na swoim przykładzie mogę powiedzieć, że raz przepisałem kod mojej aplikacji jeszcze raz i znowu robię te same błędy, klasy są długie, funkcje są długie funkcje robię nawet dwie czynności, po prostu mam takie złe nawyki.
0
Odnosząc się do tematu postu: nie ma reguły mówiącej, że zaawansowany programista pisze czytelny kod - często jest odwrotnie.
Wydaje mi się, że dobrymi książkami będą te do TDD bo to chyba testowalny kod jest dziś wyznacznikiem dobrego (czyt. czytelnego) kodu.
0
growing object oriented software guided by tests
0
Na HNie jedną z najczęściej polecanych książek jest m.in The Pragmatic Programmer
I nie kojarzę negatywnych opinii na jej temat w przeciwieństwie do np. Clean Koda, więc może dobra?
2
Polecam tę książkę: Czysty kod (znalazłem prawie 2x taniej na Allegro). Jest całkiem przystępnie napisana, naprawdę ciekawa i nawet zaawansowani programiści mogą się z niej czegoś nauczyć. Może być mniej czytelna dla młodych programistów, którzy muszą z nią spędzić nieco więcej czasu.
Poza tym - doświadczenie. Nie od razu Twój kod będzie ładny. Z kodem jak z poezją. Żeby napisać dobry wiersz, trzeba najpierw napisać kilka gniotów. I to jest naturalne.
1
Ja nie polecam Clean coda, jedna z gorszych ksiazek jakie czytalem.
Pol ksiazki autor walczy z tym jak poprawic biblioteke standardowa javy, a drugie pol zajmuja bezsensowne listingi kodu rozciagniete na kilka stron, plus fanatyczne podejscie do pewnych konwencji.
1
@urke, książka jest tak skonstruowana, żeby pokazać Ci, czym różni się brzydki kod od czystego. I jak poprawić brzydki kod. Usiądź do niej jeszcze raz. Fakt, że pod koniec są przydługie listingi już niewiele wnoszące, ale nie musisz tego analizować, jeśli analizowałeś te krótsze fragmenty w reszcie książki.