ugrás a tartalomhoz

Három halálos bűn, amit elkövethetsz a szoftvertervezés során

Trudy · 2014. Ápr. 27. (V), 12.26
A Google mérnökei szerint a leggyakoribb és legsúlyosabb tervezési hibák
 ■
1

Talán valóban

Pepita · 2014. Ápr. 27. (V), 16.52
ez a három legfontosabb hiba, de hogy ez halálos bűn lenne... - Ismét a remek Sting-féle felfújás. Szerencse, hogy kevés országban van még mindig halálos ítélet. :)
6

szerencse hogy sokan be is

blacksonic · 2014. Ápr. 28. (H), 20.47
szerencse hogy sokan be is tartjak amiket mondanak az eloadok :)
15

Sting inkvizítornak kiváló

inf · 2014. Május. 14. (Sze), 01.43
Sting inkvizítornak kiváló lenne, kár, hogy rossz korba született. :-P
2

Kb 10 percig bírtam

vbence · 2014. Ápr. 28. (H), 08.25
Kb 10 percig bírtam, de olyan tanácsok után, hogy "töröld ki a commenteket" nem hiszem hogy nekem való az anyag.

Hogy a 10 percre érdemben is reagáljak:
  • Nem hagyhatod ki a teszteket, még akkor sem, ha most az elvárás egy "biztosan jó" string értelmezése. Mi van, ha probléma lesz valamelyik upstream redszerben? Szeretnéd, hogy a hiba tovább gyűrűzzön, vagy szeretnéd minél hamarabb elcsípni, közelebb a forráshoz? (Segítek: a második).
  • Később csak arra fogsz emlékezni, hogy ez a függvény értelmezi a stringeket. Vagy - ahelyett, hogy "ez a függvény értelmezi a stringeket" a fv. dokumentációjában szerepelni fog, hogy mi ellen véd, mi ellen nem, és ezt elvárod, hogy a csapat a fejében is tartsa. (És ez minden függvényedre igaz lesz, hiszen az irányelvet nem csak egyetlen függvényre alkalmazod) .
  • Hiányos könyvtárak - az előbbi gondolat továbbvitele objektumokra és metódusokra. Ha 10-25% plusz munkával egy könyvtár teljessé tehető (vagyis biztosítja az logikusan elvárt funkcionalitást) arra voksolok, hogy két okból is megéri a pluszmunkát: 1) Kevesebb "bitnyi" információt kell róla fejben tartani a fejlesztés során; 2) Később sokkal költségesebb lesz hozzányúlni az objektumhoz, mint most, amikor a fejlesztője éppen azzal kel és fekszik.
  • Nincs olyan hogy "fölösleges comment". Ha zavarja a szemed tölts le egy extensiont az IDE-hez, mi elrejti.
3

Comment témában Uncle Bob más

H.Z. · 2014. Ápr. 28. (H), 14.16
Comment témában Uncle Bob más véleményen van, azt hiszem. ;)
16

Én egyetértek Uncle Bob-al,

inf · 2014. Május. 14. (Sze), 01.47
Én egyetértek Uncle Bob-al, de ez tényleg kód minőség függvénye. Ha valaki nem követi a clean elveket a kódja írásánál (általában nem szokták), akkor comment nélkül értelmezhetetlen lesz az egész. Akkor meg már jobb, ha mégis ír valamit arról, hogy a kód egyes részei mit csinálnak...
17

Jó comment

Pepita · 2014. Május. 14. (Sze), 08.10
Én két helyről soha nem szoktam kihagyni a kommentet:

- függvény lezáró } után a fv nyitósora (pl. public function akarmi($parameter1, $parameterN);
- és ugyanez az osztály végén.

Ezen kívül a fájl végén, hogy mit tartalmaz (általában csak egy osztályt) és melyik könyvtárban a helye.

Ezek szerintem hasznos kommentek.
18

Tök érdekes, mindenki osztály

inf · 2014. Május. 14. (Sze), 13.55
Tök érdekes, mindenki osztály meg függvény előtt szokott kommentálni, meg az annotációk is csak úgy működnek. Eszembe sem jutott volna, hogy így is lehet.
4

Nem hagyhatod ki a teszteket,

BlaZe · 2014. Ápr. 28. (H), 20.44
Nem hagyhatod ki a teszteket, még akkor sem, ha most az elvárás egy "biztosan jó" string értelmezése. Mi van, ha probléma lesz valamelyik upstream redszerben? Szeretnéd, hogy a hiba tovább gyűrűzzön, vagy szeretnéd minél hamarabb elcsípni, közelebb a forráshoz? (Segítek: a második).
Nem hallgattam meg (nem is akarok most erre fél órát szánni), de nem azt mondta, hogy azokra ne írj tesztet, amik nem fordulhatnak elő? A "ne írj tesztet"-nek valóban semmi értelme. De annak sincs, hogy olyan inputra teszteljek, ami nem jöhet. Validációs teszteket írunk, de ott a jellegéből adódóan nincs megbízható, meg megbízhatatlan input. A validáció mögött minden input megbízható kell legyen. Ha nem az, rossz a validáció. Ha jól értem, lényegében ezt írtad.

Nincs olyan hogy "fölösleges comment". Ha zavarja a szemed tölts le egy extensiont az IDE-hez, mi elrejti.
A programozók által leírt commentek kb 90%-a teljesen felesleges zaj, és kifejezetten zavaró. De lehet nagyon alábecsültem. Én megfordítanám: néha van, hogy van értelme commentezni. Egy objektumot, metódust 2 dolog ír le:
- a kód maga, a nevek, szervezés, tartalom, a benne lévő hívási lánc stb,
- a mögötte lévő teszt.
Az a kód, aminek emellé még comment is kell, hogy érthető legyen, az rossz. Az csak a helyet foglalja, és nem élő része a kódnak, a karbantartása plusz erőforrást igényel, ezért általában meg se történik.
7

teszt

vbence · 2014. Ápr. 28. (H), 21.35
A tesztnél itt nem unit tesztelésről van szó, hanem elsősorban input validációról. Az ellenérve pedig az, hogy a specifikációban leírják, hogy a cucc valid inputot fog kapni:
Your input doesn't currently include years, months or days that are out of range.


Extrém példával: egy i += 2; kommentje is lehet értékes, ha az van fölé írva, hogy "i növelése eggyel". Kevésbé sarkítva: hacsak nem egy 10 sor alatti függvényről beszélünk, ott valami algoritmus fog végrehajtódni, amihez sosem árt a fő gondolat ismertetése.
8

A tesztnél itt nem unit

BlaZe · 2014. Ápr. 28. (H), 22.14
A tesztnél itt nem unit tesztelésről van szó, hanem elsősorban input validációról. Az ellenérve pedig az, hogy a specifikációban leírják, hogy a cucc valid inputot fog kapni:

Your input doesn't currently include years, months or days that are out of range.
Ez gyakorlatilag egy "rules of engagement". Ha valaki garantálja neked a jó inputot, akkor azt valóban nem kell ellenőrizni. Azt se ellenőrzöd, hogy a 2+2 az 4 egy adott nyelven, hanem megbízol abban, hogy a dokumentáció alapján működik.

Extrém példával: egy i += 2; kommentje is lehet értékes, ha az van fölé írva, hogy "i növelése eggyel".
Ez egy tipikus példája a rossz/dead commentnek. Nem azt írja le, ami a valós működés, és eléggé félrevezető.

Kevésbé sarkítva: hacsak nem egy 10 sor alatti függvényről beszélünk, ott valami algoritmus fog végrehajtódni, amihez sosem árt a fő gondolat ismertetése.
Ezért nem (sem) írunk hosszú metódusokat. Amit egyben átlátsz, azt általában meg is érted. Nyilván 25 sorban pl elég bonyolult matematikai képleteket meg lehet fogalmazni :) De ez bőven kimeríti azt a 10%-ot, amit az előző hozzászólásomban említettem. Bár ebben az esetben már inkább valami wiki/dokumentáció szerű helyen szokás leírni és megindokolni a mitmiértet.
9

jó input

vbence · 2014. Ápr. 28. (H), 23.56
Ha valaki garantálja neked a jó inputot, akkor azt valóban nem kell ellenőrizni.

Szerintem az inkább a kivétel, amikor megbízhatsz a konvenciók betartásában - legalább is abban a világban ahol én dolgozom. :) Persze, minden környezetnek/területnek megvannak a maga sajátosságai, hatékony stílusa, ezt nem vitatom. Általános példának még mindig rossznak tartom, azt már leírtam, miért.

Nem azt írja le, ami a valós működés, és eléggé félrevezető.

Itt az volt a szándék, hogy egy redundánsnak látszó helyzet is rávilágythat egy hibára - vagyis minél több információ áll rendelkezésre annál jobb.

Ezért nem (sem) írunk hosszú metódusokat. Amit egyben átlátsz, azt általában meg is érted.

Értem én az elvet, követném is nagyon szivesen, viszont ez azt feltételezi, hogy kiforrott könyvtárakkal/eszközökkel dolgozol, amikből nem "csak azt írtuk meg ami most kell".

Példa: egy XML alapú formátumból kell 2-3 féle kérdést megválaszolnod. A) Megírod a funkciókat amik a DOM-ban mászkálva kikeresik az információt: hosszú, rosszul tesztelhető metódusok; B) Írsz egy értelmezőt a formátumhoz: soksok kód, amire nem biztos, hogy szükséged lesz.

Lehet ezüst golyókat keresni, de a jó döntés az lesz, amit az idő is igazol - vagyis ha sikerül megsejtened a jövő követelményeit. Lesz amikor az a megoldás lesz a nyerő, ami magán hordozza az éppen kárhoztatott jegyeket.
11

Szerintem celravezetobb az,

blacksonic · 2014. Ápr. 29. (K), 12.31
Szerintem celravezetobb az, hogy eloszor megirod hogy mukodjon, aztan a jol szetvalaszthato dolgokat atmozgatod ha mashol is szukseg van ra. A lenyeg hogy mindig csak annyi absztrakciot es annyi plusz kodot raksz bele amennyi az uj funkcionalitashoz es konnyu atlathatosaghoz kell. Se tobbet se kevesebbet.
Ha ezt sikerul szem elott tartani es betartani gyorsabban fogsz haladni es szep kodot fogsz magad mogott hagyni (nem tokeletes de kelloen letisztult kodot).
Nem kell megsejtened a jovot, csak ugy megirnod a jelenlegi kovetelmenyekhez levo kodot, hogy bovitheto legyen.
12

Egyetértek

Hidvégi Gábor · 2014. Ápr. 29. (K), 12.41
Így van, és a google is pont ezt ajánlja.
13

Az a kód, aminek emellé még

tgr · 2014. Május. 1. (Cs), 09.20
Az a kód, aminek emellé még comment is kell, hogy érthető legyen, az rossz. Az csak a helyet foglalja, és nem élő része a kódnak, a karbantartása plusz erőforrást igényel, ezért általában meg se történik.


A kommentek nem arra valók, hogy megértsd, mit csinál a kód, hanem hogy megértsd, mi volt a szándéka annak, aki írta, ez pedig a függvénynevekből nem fog kiderülni. Előfordul, hogy mást következne a kommentből, és mást csinál a kód valójában, és akkor tudod, hogy ez egy javítható hiba, míg ha nem lenne ott a komment, akkor nem tudnád mihez viszonyítani a helyességét, és nem mernéd kijavítani. A unit és egyéb tesztek bizonyos fokig át tudják venni ezt a funkciót, de megvannak a korlátaik.
14

Válasszuk ketté a dolgot. Van

BlaZe · 2014. Május. 1. (Cs), 15.04
Válasszuk ketté a dolgot. Van az a comment, ami egy adott függvény/metódus felhasználójának szól, és van az, ami annak, aki később megpróbál belenyúlni. Előbbi az apidoc, utóbbi az inline comment (nagyjából). Mindkettőnek lehet értelme, de az esetek legnagyobb részében csak felesleges zaj, főleg az inline comment. Ezt sokan arra használják, hogy elválasszák/megtageljék vele az egyes kódblokkokat, összetett feltételeket magyarázzanak stb. Mindezt azért, mert a kód olvasójának értelmezni kell a kódot annak megértéséhez. Pl az ifet, ciklust stb. Ezért inkább leírja a jövőben arra tévedő programozónak, hogy itt valójában mit akart. Ez egy egyértelmű jel arra, hogy a kód nem olvasható, és a commenttel jelölt részek megkívánják a kiemelést. Vagyis keverednek az absztrakciós szintek, felelősségi körök stb. Ez a baj velük. És mivel nem részei az élő kódnak, idővel elkezdenek külön életet élni, és előáll az a helyzet, amit említesz is, hogy az eredeti fejlesztőnek más volt a szándéka, mint ahogy a kód működik. Vagy valaha úgy működött, ahogy a commentben van, de már nem úgy működik. Vagy soha nem is működött úgy. És a fejlesztő már elment, vagy rég volt, már nem emlékszik, különben is jött rá 50 commit... Ergo tökmindegy mi van odaírva. Lényegtelen. Illetve nem, mert ha valaki azt olvassa el a kód helyett, akkor bement az erdőbe...

Ezek miatt írunk rövid metódusokat, szeparáljuk a felelősségi köröket stb. Így tudjuk biztosítani, hogy kifejező metódusneveket tudjunk választani, a kód olvasható és tesztelhető legyen, ami a létező legjobb dokumentáció. Az ilyen elvek mentén szerveződő kód nem igényel plusz commenteket.

Vagyis a comment az utolsó eszköz kell legyen a programozó számára, amivel ki tudja fejezni hogy működik az algoritmusa. Vagy hogy mi volt vele a szándéka, egyre megy. Amikor ehhez kell nyúlni, az jellemzően valami nem triviális eset. Pl amikor egy külső függőség paraméterezését kell indokolni (pl XY rendszer itt 42-t vár). Vagy ahol tényleg nagyon komplex algoritmust kell megvalósítani. De ezek az esetek egy átlagos programnak igen kis részét teszik ki.

És akkor van az apidoc, ahol szintén igen ritka, hogy nagyon magyarázni kéne.

A kulcs az SRP. Ahol ez teljesül, ott nem nagyon van mit magyarázni. Ellenpéldákat lehet erre hozni, én is tudnék, de a téma indító általánosságokról szólt.
5

Ajanlok neked egy konyvet:

blacksonic · 2014. Ápr. 28. (H), 20.45
Ajanlok neked egy konyvet: Clean Code
A sok komment azt jelzi, hogy ben eleg egyertelmu es magyarazo a fuggveny vagy osztaly neve, lehet hogy tul sok mindent csinal.
A szelso ertekek kezelesenek leirasara meg ot vannak a tesztek, amik dokumentaljak a mukodest, es sosem lesznek outdatedek, mint pl a kommentek.
Annal nincs koltsegesebb ha olyan dolgokat fejlesztesz le amik nem is kellenek...ha jol van megirva, nem lesz sokkal tobb energia megirni a maradekot ha tenyleg kell...altalaban nem
A jol megirt teszteknel nem gyuruzik tovabb a hiba, ha unit tesztekrol beszelunk, mert azokat izolacioban teszteljuk. Integracios teszteknel ez elofordulhat.
10

Ezekkel mind

vbence · 2014. Ápr. 28. (H), 23.59
egyetértek. Kivéve a kommentekkel kapcsolatban, azt feljebb kifejtem.