[Javalist] RegExp probléma: nem aposztrófok közé zártak felismerése

[Peter Verhas]

Én éppen pénteken vágtam ki egy ilyen helper class-t a kukába. Igaz, hogy fél napig írtam, és pont olyan volt, ahogy én szeretem, de aztán bevillant, hogy ennek a funkcionalitásnak meg kell lennie apache common- ban vagy guavaban. És fél óra alatt meg is találtam. 




Nem pont olyan. Egy kicsit nehézkesebb a használata, de talán mert általánosabb, meg aki írta nem úgy gondolkodott ahogy én (naná).




És a másik oldalról: nem tudott mindent amit a saját. Ezért a sajátot kidobtam es elkezdtem használni ami az apacheban van. Es közben rájöttem, hogy ami nincs meg az apache-ban az nem is kellett nekem. (Ezt ők honnan tudták?)




Az a jó programozó, aki a funkcionalitást kevesebb kóddal tudja megvalósítani. 

—
Dipl. Ing. Peter Verhas

On Sun, Dec 8, 2013 at 8:33 AM, Auth Gábor <auth.gabor at javaforum.hu>
wrote:

> Hi,
> Suller Andras a következőt írta ekkor: 2013. december 8. 07:52:06
>> Nem ertem ezeket a reakciokat. Rajtam es Joe-n kivul senkinek
>> sincsenek statikus helper osztalyai?
> Amire van kész és dobozos megoldás, mondjuk elterjedt és népszerű 
> csomag, ami mondjuk nyílt forrású is: azt célszerű használni. Csak és 
> kizárólag arra a problémára legyen saját fejlesztésű Utility csomag 
> (szigorúan külön csomag), ami nincs közismerten elterjedve, tehát mondjuk 
> rákeresünk a feladatra és az első tíz találatban csak panaszt látunk arra, 
> hogy nincs rá jó megoldás.
> Akkor lehet még szó saját megoldásokról, ha nagyon idő vagy teljesítmény 
> kritikus a fejlesztés és az általános megoldások túl lassúak vagy több 
> erőforrást igényelnek, mint a specializált megoldások, de általános 
> esetben az ilyen saját fejlesztések mindig drágábbak, mint a megspórolt 
> idő vagy erőforrás.
> A fejlesztés jel/zaj (üzletileg hasznos kód / üzletileg haszontalan kód) 
> viszonyában minden helper, utility, hack, workaround és a többi kiszolgáló 
> osztály a zajt növeli. Lehet okosan is csinálni az OOP paradigma 
> használatával, illetve JavaEE használatával, de lehet úgy is, hogy a hasznos 
> kódbázis töredéke a kiszolgáló kódbázisnak, mert a fejlesztő alapvetően 
> nem szeret üzleti problémákat megoldani, helyette keretrendszeri 
> fejlesztéseket csinál, mert az sokkal érdekesebb... csak nem azért fizetik.
>> En copy-paste-eltem a projektjeim kozott ezeket a helper osztalyokat.
>> Ami most mar tudom, hogy balgasag volt, de akkor megfelelo 
> megoldasnak
>> tunt.
> Kicsit később már azt is balgaságnak fogod tartani, hogy írtál ilyen helper 
> osztályokat... az ember előbb-utóbb belátja ezt. Mindenki úgy kezdi, hogy 
> túl nagynak, összetettnek, nehézkesnek tartja az összes utility csomagot, 
> ezért megírja a sajátját, aztán napról-napra kiderül, hogy mit nem tud a 
> saját csomagja, jó esetben hozzá lesz ragasztva egy új metódus, rossz 
> esetben ilyenkor kiderül, hogy az egész koncepció hibás és nulláról újra 
> kell írni az új körülményeknek megfelelően. A szokásos stációk:
> - valamelyik komponens újabb verziójával nem működik, mert van benne 
> deprecated függőség, mert az egyszerűbb volt
> - másik futtató környezetben nem működik, mert más a JVM, más a web 
> konténer, más az operációs rendszer
> - másik fejlesztésben nem működik, mert tulajdonképpen nem általános 
> utility, hanem specializált, ettől meg az első fejlesztésben nem működik jól
> - másik fejlesztővel nem működik, mert nem érthető a működése, illetve 
> késhegyre menő viták vannak folyamatosan, mert nem várt hibák vannak 
> benne, amit csak az ismer, aki fejlesztette
> - nem működik együtt szabványos vagy elterjedt utility osztályokkal, mert 
> azok "nem jól működnek"
> - nem működik elosztott környezetben, mert nem volt szempont a 
> kifejlesztésénél
> - lelépett vagy kirúgták a fejlesztőt és itt hagyta a sok "szart", amihez csak 
> ő értett, ezért kidobják az egyedi fejlesztést
> Bye,
> Auth Gábor
> http://www.javaforum.hu/web/10/authgabor
--------- következő rész ---------
Egy csatolt HTML állomány át lett konvertálva...
URL: <http://lists.javaforum.hu/pipermail/javalist/attachments/20131208/4fc72833/attachment.html>