Temat: Jakość kodu
Nie chodzi mi o magię, lecz raczej o funkcjonowanie człowieka w grupie, w zespole. Wiemy, że natura nie znosi próżni, a zdrowy rozsądek podpowiada, że tam gdzie nie ma jasnych reguł, tam pojawia się kombinowanie, kwadratura koła i wyważanie otwartych drzwi, zamiast myślenia o robocie do zrobienia ;)
I czasem to kombinowanie staje się zasadą. To własnie mam na myśli.
Wiesz, jeśli tylko z tego kombinowania przychodzi jakiś pożytek, jakaś nowa jakość - to ok.
W każdym innym przypadku to strata czasu.
Kombinowanie źle się kojarzy.
Powiedzmy sobie szczerze - dobre zasady nie biorą się ze "zgadywania".
Dla przykładu - TDD :-) . Podobno stosowanie TDD (nikt o tym nie wspomniał od jakiegoś czasu) gwarantuje "dobrą jakość" kodu...
Taaaak?
Wreszcie nie trzeba myśleć i umieć?
Wreszcie nie trzeba :)
Nawiązując do TDD jakość bierze się z :
1. Przed implementacją funkcjonalności, należy napisać jej test
2. Sprawdzić, czy test nie przechodzi (dla niezaimplementowanej [sic!] funkcjonalności)
3. Napisać kod który przechodzi test (nie ma słowa o zaimplementowaniu funkcjonalności)
4. Jeśli test przechodzi - należy zmienić kod tak, żeby był "ładny" (bo jak coś działa to należy to zmienić)
Te zasady gwarantują dobrą jakość kodu i produktu ...
http://en.wikipedia.org/wiki/Test-driven_development
W przypadku TDD myślenie jest zakazane; zasady są zbyt absurdalne żeby normalnie myślący człowiek mógł je zaakceptować.
To troszkę tak, jakby rozważać, który język jest lepszy: angielski czy niemiecki ;) Odpowiedź jest jedna: ten, którym mówi większość :)
Większość stosuje TDD / Agile :-)
Nijak się to ma do standardów kodowania, Jakub ;)
Ja miałem na myśli ten aspekt.
A ja miałem na myśli to, że standardy na prawdę mogą być "z sufitu".
Należy docenić (i zabezpieczyć się przed) kreatywność ludzi którzy nie mają o niczym pojęcia.
Np. czy otwierający nawias klamrowy dajemy w tej samej linii, co nazwa metody, czy w kolejnej? czy stosujemy nazwy w konwencji pascal/camel, czy rozdzielamy człony nazwy podkreśleniem? czy operatory otaczamy spacjami z obu stron, czy nie?
To się nazywa konwencja. I mogę podać przykłady na to, że nawet to można ustalić głupio.
czy stosujemy zagnieżdżone dziedziczenie, czy nie? czy uciekamy od klas statycznych, czy wręcz przeciwnie?
A to jest już architektura.
Piotrze, jeśli w tym temacie nie miałeś styczności z głupotą to mogę tylko zazdrościć.
O tym myślałem mówiąc, że standardy nie mają znaczenia - ważne jest jedynie ich ustalenie w podobnych aspektach, a sama treść tych ustaleń ma znaczenie bardzo wtórne, bo i tak wszystko da się zrobić na 1001 sposobów, z których większość jest wystarczająco dobra.
Przypomnę: copy paste (kiedy wspomniałeś o tym za pierwszym razem jeszcze nie wiedziałem o co chodzi) to też pewna zasada :)
A jeśli jakieś zasady wśród tych zasad są rzeczywiście idiotyczne i po prostu przeszkadzają, to w zdrowej organizacji zaczną być po prostu omijane tak, żeby nie łamać pozostałych zasad, i po prostu z czasem umrą.
Nie prawda. Po pierwsze mało kto wie które zasady są idiotyczne a które nie.
Nie prawda :) Tak źle będzie tylko wtedy, jeśli będziesz pracował ze stadem baranów - a w tym przypadku nic nie pomoże, i tak wyjdzie śmigło.
Powiedzmy że śmigło wychodzi w pewnych firmach od wielu lat i wszyscy traktują to jako pewien standard.
Żeby wiedzieć, co jest "dobre" / "złe" trzeba mieć jakiś punkt odniesienia...
Większość ludzi na prawdę uważa, że dobre pomysły biorą się z gapienia się w sufit.
Być może to prawda. Mi np. najlepsze pomysły wpadają do głowy podczas jazdy samochodem.
Mi to pachnie nową metodyką realizacji projektów IT ;)
A tak na serio - niektórym wystarczy 2-3 sekundowa obserwacja sufitu... tak, to jest sarkazm.
Ludzie, dzięki swojemu "lenistwu" (czytaj: dążeniu do mniejszego męczenia się), w takich sytuacjach naprawdę potrafią być zadziwiająco kreatywni :)
A tam jest całe stado ludzi "pracowitych" .....
Ależ nie. Lenie wymyślają sposoby ułatwiania sobie robienia różnych rzeczy, żeby móc się dalej lenić :)
Podziwiam wiarę w ludzkość i zazdroszczę doświadczeń.,
пропозиції роботи
