Keresés

Új hozzászólás Aktív témák

  • cucka

    addikt

    válasz pmonitor #17990 üzenetére

    Először is - a komplexitás fogalmát ott érdemes tárgyalni, ahol nagy méretű kódbázisról van szó. Egy tök átlagos, jávában/c#-ban írt céges ügyviteli szoftverben lesz több száz, vagy akár több ezer osztály, amit éveken át írt több csapat, ilyen-olyan tudásszinttel, folyamatosan változó üzleti igényekkel.

    Az essential complexity főleg tervezésnél fontos. Tudod, mi tartozik ide, tudod, hogy ideálisan ez stateless van implementálva, tudod, hogy erre akarsz tuti 100% test coverage-et, akár más tesztek kárára is. Ha DDD-t csinálsz, akkor ezt a komplexitást definiálod. Ha BPMN-t akkor szintén. Arra is jó, hogy rájöjj, ha a juniorabb kolléga refaktorálási ötletei valóban hasznosak-e, vagy csak arra jók, hogy a komplexitást átrakd az egyik zsebedből a másikba.

    Ciklomatikus komplexitást arra használod, hogy jelzi, melyik részei tesztelhetetlenek a programodnak. Ezek azok a részek, amelyek sürgős refaktorra szorulnak, mielőtt bárki azon gondolkozna, hogy teszt lefedettség.

    Kognitív komplexitás metrika szintén a problémás részek azonosítására szolgál.

    LOC esetenként lehet hasznos, ugye megmondja, hol vannak hosszú függvények a kódban. De ugye önmagában ha hosszú a kód, az nem jelent gondot. Az jelent gondot, hogy várhatóan ha hosszú a kód, akkor nehéz lesz tesztelni.

    Aszimptotikus komplexitást jól mérni nem nagyon lehet, ott jön elő nagyon, amikor nagy mennyiségű adattal dolgozol. Mittomén, minden éjjel ütemezettem riportokat gyártasz. Ha 5 perc egy riport legyártása, az nem gond, ha 3-at kell megcsinálj, de gond, ha 3000-et.

    Vannak más szempontok és technikák is, de meghagyom mindenkinek az örömöt, hogy olvassa el magának a Clean Architecture-t.

Új hozzászólás Aktív témák