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

• #10518 floatr veterán disy68 #10517

  Új Válasz 2019-07-04 14:10:11 #10518

  Új hozzászólás

  Összes hozzászólása itt Válaszok az összes hozzászólására itt Válaszok erre a hozzászólásra

  Privát üzenet küldése

  

  floatr

  veterán

  válasz disy68 #10517 üzenetére

  Lehet, hogy neked a kontextus neked nem konfiguráció, nekem még mindig az, kezdve a legpitiánerebb dolgokkal, amit változtatni kellene egy production környezetben adott esetben. De ez a jó, hogy különbözőek vagyunk. Amúgy nem fétis, talán észrevetted, hogy egy kombinált megoldást említettem. Szerintem a Java config a típus-fetisiszták fertője Olvashatóság tekintetében valóban jobb lenne egy JSON vagy YAML context definíció, de amikor kódból maszatol valaki, az agyhalál.

  A generált kóddal kapcsolatban rettenetesen álszent a hozzáállás. A hibernate és spring által generált 60 tonnányi (cglib, asm, miegymás) kód ok, a lombok @Getter/@Setter nem, hagyjuk már. A kotlin által generált JVM kód megint ok, bár többszörösen megerőszakolja az egész rendszert, de a @NoArgsConstructor/@AllArgsConstructor az csúnyarossz... vicc. Meg lehet nézni, hogy mekkora buglistája van ezeknek a rendszereknek már csak a kódgenerálás okán is, de attól nem félünk
  Egy @Builder/@Getter annotáció átláthatatlan az osztály elején, de a húszmillió sornyi extra kód nyilván karbantarthatóbb, ha valami változik... Szerintem az a veszélyes, hogy ezt valaki nem meri használni. Ugyanaz a probléma, mint amikor az 1.5-ös iterációk és enumok tartották rettegésben az említett projektet.

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