A szorny nem fuggvenynel volt hanem matrix-implementacional (amit aztan nem hasznalnak). A legvegen igy is, ugy is maradt raw type hozzarendeles, de azert hogy 1 helyen legyen nem 2 helyen (kb, lehet hogy 3-4), ettol bevezettek a rekurziv definiciot es ket type parametert... (hogy osszekossek a matrixtipust meg a utilities tipusat, holott a matrixtipus futas soran egyszer, config-bol olvasodik fel).
A fuggvenyre kedvenc peldam a Gauss-eliminacio. Azt szetszedve en biztos kevesbe ismernem fel, a korrektseghez 5 parameteresen lehetett volna a belso fuggvenyt kiemelni (kettot member-bol szamoltunk vegul), de nem lehet egy fel kepernyonyi (vizszintesen, meg nem mondom de biztos <50 LOC) fuggveny, mert tul bonyolult. Az hogy normalisan elnevezni a belsejet nem lehet, az nem baj. Az hogy egy csomot lassit egy azert hoztuk letre hogy jobb legyen sebessegben mint az ApacheCommons, az nem baj. Csak hogy jo alacsony legyen a bonyolultsag, es egysegsugarunak is oda lehessen adni (akik amugy per def nem is dolgozhatnak ebben a csapatban). DE ez az eset, amire azt mondom, hogy a kivetel ami erositi a szabalyt, es egy programozo tudja mar hogy mi az hogy Gauss-eliminacio. A tobbsegeben egyetertek azzal, hogy bontsuk le a hosszu fuggvenyeket.
Az mar egy masik kerdes, hogy ne ugy bontsuk le hogy veszunk 3 altalanositott szornyet, es a sajat sub-task-unkat nem is oldjuk meg csak felparameterezzuk a mar keszet, elotte-utana heavy konverziokkal, de mind1, mert az me'g egy sor csak a stream-ben... kozben picit odafigyelve a 2 oda-vissza megoldhato 1-bol (most egy Date meg Instant dologrol beszelek, az egyik kulso adottsag, a masik belso kenyszer mert kell a het napja).
De kb. egy eve talaltak olyan bottleneck-et, hogy mindenhol az ID nyersen ment tovabb, es minden egyes lepes kulon parsolta ki belole a neki kello reszt (mondjuk az se egy jo design ahol az id darabolhato, me'g ha van ilyen kulso forras is, de belul mi a feneert nem egybol lenyegitik at a kesobb hasznalt reszeire.