Jak tworzyć "dobry kod"

Witam serdecznie,
Chciałbym udoskonalić tworzony przeze mnie, macie jakieś dobre rady lub żródła które pomogą mi osiągnąć ten cel?
Pozdrawiam.

Poczytaj sobie o Agile development

Masz na myśli wersję pod używany język?
Edit
Chyba znalazłem OReilly The Art of Agile Development ?
Jakieś inne porady?

Agile to cała gama metodologii jak wytwarzać oprogramowanie i jest to chyba trochę za szeroka tematyka jeżeli ktoś chce tylko poprawić jakość pisanego przez siebie kodu. poza tym agile to nie panaceum na wszystko i jest jeszcze wiele metodyk kaskadowych/waterflow, które w niektórych typach projektów sprawują się lepiej.

Jeżeli już dobrze czaisz programowanie zorientowane obiektowo to polecam najpierw poczytać klasyki:
Wzorce projektowe - http://wysylkowa.pl/ks898059.html
Refaktoryzacja kodu - http://www.czytam.pl/k,az_79493,Refaktoryzacja-ulepszanie-struktury-istniejacego-kodu-Fowler-Martin-Beck-Kent-Brant-John-Opdyke-William-Roberts-Don.html

Praktyczne i przydatne niezależne od metodologii :)

Dobry pomysł to też dzielić kod na dużo małych funkcji/metod, które robią tylko jedną rzecz. To bardzo zwiększa czytelność kodu.

To może jeszcze jedno pytanie,
Jak patrzycie na kod to jakie jego cechy sprawiają że uważacie że jest dobry?
Może taki gdzie jest konsekwencja nazewnicza, dobrze dobrane nazwy, co jeszcze ?

Jak patrzycie na kod to jakie jego cechy sprawiają że uważacie że jest dobry?
Może taki gdzie jest konsekwencja nazewnicza, dobrze dobrane nazwy, co jeszcze ?

Skończcie wreszcie z tym nazewnictwem :-) - to najmniej ważna rzecz..

Kilka aspektów, które przemawiają za dobrym kodem (mowie o OOP oczywiście...):

• łatwa przenośność kodu
• wszelkie zmiany w logice łatwe do zrealizowania (zmiany nie mogą wymagać "przepisywania klas od nowa")
• performance (czy twoja aplikacja zniesie 10tys. użytkowników?)

Można to zrealizować przez różne techniki:

• sensowny podział na klasy i moduły (dobra enkapsulacja, stosowanie dziedziczenia, brak chorych powiązań i zależności, stosowanie sprawdzonych praktyk OOP)
• wzorce projektowe
• podział na warstwy (MVC) (nie mowie o frameworku ASP.MVC, tylko o samej architekturze...)
• nie duplikować kodu!
• unit testy (zapewniona stabilność i gwarancja, że zmiany nie zepsują istniejącej logiki)

Jeśli już mowa o stylu pisania, to zamiast nazewnictwa dałbym:

• nie stosować ekstremalnie długich linii w kodzie
• w kodzie nie powinno być wszelkiej konfiguracji (konfiguracja - do plików konfiguracyjnych)
• usunąć zbędne komentarze, przykład:

public int DoorNumber; // Number of the door

Maniacy OOP mówią, że kod idealny jest tak napisany, że wszelkie zmiany w aplikacji wymagają jedynie dopisania nowego kodu, a nie modyfikacji już istniejącego.

Deti - to ja proponuje mały eksperyment. Weź jakiś open sourcowy kod którego nie znasz i po podmieinaj nazwy na coś w stylu AAAA, ABAA, BBBB. Ciekawe czy będziesz w ogóle w stanie znaleźć to co Cię interesuje (nie mówiąc już o pełnym zrozumieniu). IMHO dobre nazewnictwo poprawia czytelność nawet zwalonego designu.

A jaki jest dobry projekt Open Source, z którego warto brać przykład?

walec51 napisał(a)

Wzorce projektowe - http://wysylkowa.pl/ks898059.html

No bez jaj :|
Wzorce projektowe dla ludzi - http://helion.pl/ksiazki/hfdepa.htm

tomii napisał(a)

A jaki jest dobry projekt Open Source, z którego warto brać przykład?

Jądro Linuxa.

A ja proponuję się wyluzować , systematyka przychodzi z wiekiem i praktyką - stres zabija dobre pomysły:
TU

somekind napisał(a)

No bez jaj :|
Wzorce projektowe dla ludzi - http://helion.pl/ksiazki/hfdepa.htm

Obrazki juz pokolorowales?

// Egon weź nieco przystopuj - Q

somekind napisał(a)

walec51 napisał(a)

Wzorce projektowe - http://wysylkowa.pl/ks898059.html

No bez jaj :|
Wzorce projektowe dla ludzi - http://helion.pl/ksiazki/hfdepa.htm

Proponuje jednak te dla programistów :P

EgonOlsen napisał(a)

Obrazki juz pokolorowales?

// Egon weź nieco przystopuj - Q

E tam, ten dowcip akurat się udał :)
Albo i nie, bo pewno w założeniach to nie miał być dowcip ;P

walec51 napisał(a)

Proponuje jednak te dla programistów :P

W ogólnym przypadku jedno drugiego nie wyklucza. Czyżby w Twoim przypadku było inaczej? ;)

Można być tró i czytać encyklopedie, można sięgnąć do książki, której autorzy mieli pojęcie o dydaktyce i pomysł na przekazanie swojej wiedzy. Kwestia wyboru i masochizmu.
Zawsze po HF można sięgnąć do książki "dla programistów", tylko nie będzie raczej takiej potrzeby ;]

s_k napisał(a)

Można być tró i czytać encyklopedie, można sięgnąć do książki, której autorzy mieli pojęcie o dydaktyce i pomysł na przekazanie swojej wiedzy. Kwestia wyboru i masochizmu.
Zawsze po HF można sięgnąć do książki "dla programistów", tylko nie będzie raczej takiej potrzeby ;]

Kwestia czy potrzebujesz tej dydaktycznej nadbudówki żeby to zrozumieć, czy wolisz bardziej skrócony i konkretny opis. Ja wole przekaz jak inżynier do inżyniera, niż dydaktyk to ucznia.

poza tym jak ktoś mi na klasyk bandy czworga wyjeżdża z "no bez jaj" to raczej nie zasługuje na poważne traktowanie.
Aluzja do encyklopedii jest też bezsensowna. Książka ma formę katalogu ale prawie każdy z elementów katalogu jest wpleciony w use case projektowania edytora dokumentów na początku książki.

// trochę za dużo loginów chyba mam w tym forum :)

walec-51 napisał(a)

Kwestia czy potrzebujesz tej dydaktycznej nadbudówki żeby to zrozumieć, czy wolisz bardziej skrócony i konkretny opis. Ja wole przekaz jak inżynier do inżyniera, niż dydaktyk to ucznia.

Przecież jedno drugiemu nie przeczy. W HF jest krótko i konkretnie, obrazki i "dydaktyczna nadbudówka" nie rozciągają treści, tylko są po to, żeby łatwiej przekazać wiedzę czytelnikowi. Bo chyba po to książki są, nieprawdaż?
UML także jest bez sensu? ;>

poza tym jak ktoś mi na klasyk bandy czworga wyjeżdża z "no bez jaj" to raczej nie zasługuje na poważne traktowanie.

Dlatego, bo to klasyk? I nie można krytykować?
Jedni coś wynajdują, a inni potrafią to opisać, a kwestia oceny jakości książki pozostaje i tak czytelnikowi.

A ja mogę polecić książkę Code Complete.

somekind napisał(a)

tomii napisał(a)

A jaki jest dobry projekt Open Source, z którego warto brać przykład?

Jądro Linuxa.

Jesli ktos oczekuje OOD/P to kernel nie spelni jego wymagan.
Czysto strukturalny kod w C.
Oczywiscie wysokiej klasy i jak najbardziej warto z niego brac przyklad.
Szczegolnie tym ktorzy sa przeciwni programowaniu z "goto" :-D bo tam mozna to znalezc :).

Tak, Linux... Przecież ten kernel to jeden wielki burdel, przeładowany makrami w każdym możliwym miejscu. Architektura kodu też spójna jak cholera, stanowczo nie polecam zagłębiania się w tego coś.