Mennyire legyen általános az általános?
Üdv.
Az utóbbi néhány évben szinte kizárólagosan abba a problémába futok bele, hogy valami config fájlból beállítható legyen-e, és általános kódot írjak hozzá, vagy konkrét kódot írjak, szóval hardcodoljam a rendszerbe. Ez a probléma nagyon megnehezíti pl az általános célú rendszerek írását, mert nem tudod eldönteni, hogy mi kerüljön bele a rendszeredbe, és mit bízz a fejlesztőre, aki használni fogja. Van ilyen téren bármi tapasztalatotok, tanácsotok?
Jelenleg egy REST API generátort írok, ami egy alkalmazás leíró fájlból dolgozik, és képtelen vagyok eldönteni, hogy mennyire mélyen menjek bele a dolgokba. Nekem annyi a tapasztalatom az ilyen jellegű problémákkal, hogy sokszor konkrét feladat függvénye hogy mi kerüljön az adatbázisba/config-ba, és mi maradjon hardcodolva osztályokban vagy bootstrap fájlban. Az általános alkalmazásoknál pont az a probléma, hogy nincs konkrét feladat, hanem az van, hogy alkoss valamit a témában, ami jól használható. Két stratégiám van az ilyen jellegű feladatok megoldására. Az egyik, hogy egy vagy több konkrét példa refaktorálásával alkotom meg az általános oszályokat, a példák megoldása során pedig látom, hogy mi az, amire ténylegesen szükség van, és mi az amire nem. A másik megoldás, hogy kitalálok egy nekem tetsző application interface-t, aztán TDD-vel implementálom azt. Ennél a projektnél eddig mindkét stratégia csődöt mondott, nem adja meg magát a rohadék... :D
■ Az utóbbi néhány évben szinte kizárólagosan abba a problémába futok bele, hogy valami config fájlból beállítható legyen-e, és általános kódot írjak hozzá, vagy konkrét kódot írjak, szóval hardcodoljam a rendszerbe. Ez a probléma nagyon megnehezíti pl az általános célú rendszerek írását, mert nem tudod eldönteni, hogy mi kerüljön bele a rendszeredbe, és mit bízz a fejlesztőre, aki használni fogja. Van ilyen téren bármi tapasztalatotok, tanácsotok?
Jelenleg egy REST API generátort írok, ami egy alkalmazás leíró fájlból dolgozik, és képtelen vagyok eldönteni, hogy mennyire mélyen menjek bele a dolgokba. Nekem annyi a tapasztalatom az ilyen jellegű problémákkal, hogy sokszor konkrét feladat függvénye hogy mi kerüljön az adatbázisba/config-ba, és mi maradjon hardcodolva osztályokban vagy bootstrap fájlban. Az általános alkalmazásoknál pont az a probléma, hogy nincs konkrét feladat, hanem az van, hogy alkoss valamit a témában, ami jól használható. Két stratégiám van az ilyen jellegű feladatok megoldására. Az egyik, hogy egy vagy több konkrét példa refaktorálásával alkotom meg az általános oszályokat, a példák megoldása során pedig látom, hogy mi az, amire ténylegesen szükség van, és mi az amire nem. A másik megoldás, hogy kitalálok egy nekem tetsző application interface-t, aztán TDD-vel implementálom azt. Ennél a projektnél eddig mindkét stratégia csődöt mondott, nem adja meg magát a rohadék... :D
Elég egyszerű ökölszabályt ki
Ez a szabály hatványozottan igaz, ha libet készítesz. Ha túl sok konfiguráció szükséges egy objektum, objektum-hierarchia létrehozásához, akkor készíthetsz factory metódust, amivel létrehozható egy általános, legtöbb esetben megfelelő objektum, de ez nem helyettesítheti, inkább kiegészíti az előbbi szabályt.
Az általad említett téma esetén (ha nem értem félre a dolgot) például remekül megoldató annotációval is a konfiguráció, de ha valaki valami oknál fogva mégse így akarja használni a libet, lehetősége legyen máshogy konfigurálni azt (tetszőleges DIC, vagy akár egyedi konfig. implementáció felhasználásával).
Ja, és stateless osztályokhoz készíts iterfészt.
Tisztában vagyok vele, hogy
Akkor esetleg írj példát,
Ha általános programot írsz,
Jó de elméletileg mindent ki
Egyébként valamelyest hasonló
Szóval ha nagyobb szabadságot ad a keretrendszer, akkor annak mindig az az ára, hogy bonyolultabb kódot kell írnia a fejlesztőnek. Valahol meg kell találni az egyensúlyt a fejlesztői igények és a fejlesztő illetve az én általam befektetendő energia terén. Ez meg szerintem teljesen projekt függő. Gondolom megvannak a tudományos módszerek, hogy hogyan érdemes kideríteni, hogy mi az, amit neked kell leprogramozni, és mi az, amit a keretrendszered használójának. (Én sajnos nem ismerek ilyeneket, csak egy kevés gyakorlati tapasztalatom van a témában.)
Most jelenleg azt csinálom, hogy írok néhány példát REST-es HTTP kommunikációra, aztán megnézem, hogy a küldött adatok közül mi az, amit egyszerűen le tudok írni általánosan, és mi az, ami ezer féle lehet. Valószínűleg az utóbbiakat teljes mértékben rábízom a fejlesztőkre. Eddig azzal próbálkoztam, hogy a lehető legtöbb dolgot általánosan leírjak, de van egy határ, ami után ez már inkább hátrány, mint előny, mert korlátozza a fejlesztői szabadságot...
Ez meg szerintem teljesen
Gondolom megvannak a
Mindig megmosolygom, hogy mindenről úgy gondolod, hogy létezik rá kész elmélet, csak te még nem ismered (aztán, amikor úgy érzed, hogy megértettél valamit, akkor úgy gondolod, hogy most már megismerted) :)
A legjobb, amit tehetsz, az,
Ha nem így teszel, könnyen kifogyhatsz az oxigénből.
Haha, tetszik az analógia, ha