ugrás a tartalomhoz

Mennyire legyen általános az általános?

inf · 2014. Feb. 1. (Szo), 03.34
Ü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
 
1

Elég egyszerű ökölszabályt ki

szjanihu · 2014. Feb. 1. (Szo), 14.47
Elég egyszerű ökölszabályt ki lehet mondani erre: a new kulcsszó csak és kizárólag stateful osztály példányosítása esetén megengedett, stateless esetén DI-t kell alkalmazni. Ez alól nyilván kivétel az, ha az ember épp DIC fejlesztéssel múlatja az időt, de jelen esetben nem ez a helyzet.

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.
2

Tisztában vagyok vele, hogy

inf · 2014. Feb. 1. (Szo), 14.47
Tisztában vagyok vele, hogy hogyan kell konfigurálni, a kérdés nem erről szólt.
3

Akkor esetleg írj példát,

szjanihu · 2014. Feb. 1. (Szo), 15.15
Akkor esetleg írj példát, fogalmazd át, vagy bízz abban, hogy más megérti és nem lesz rest válaszolni.
4

Ha általános programot írsz,

Hidvégi Gábor · 2014. Feb. 1. (Szo), 15.36
Ha általános programot írsz, akkor célszerű mindent parametrizálhatóvá tenni, legfeljebb idővel, a használat tükrében ki lehet venni opciókat, és bele lehet égetni a kódba.
5

Jó de elméletileg mindent ki

inf · 2014. Feb. 1. (Szo), 15.56
Jó de elméletileg mindent ki lehet tenni config fájlba és megadni paraméterként. Még az osztályok és metódusok kódját is lehet generáltatni, stb... Nem tudom, hogy hol húzzam meg a határt...
6

Egyébként valamelyest hasonló

inf · 2014. Feb. 1. (Szo), 16.32
Egyébként valamelyest hasonló összefüggés van a PHP és NodeJS között is. A PHP alapból nem foglalkozik a http szerver kérdésével, így lehetséges szinkron kóddal megoldani benne mindent, viszont ha daemonok, esemény vezérelt dolgok, websocket-es chat, stb... írására kerül a sor, akkor gondban van az ember. Ezzel szemben NodeJS eléggé esemény vezérelt, és nem okoznak gondot neki a fentiek, viszont ennek az az ára, hogy muszáj aszinkron kódot írni benne...

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...
7

Ez meg szerintem teljesen

Hidvégi Gábor · 2014. Feb. 1. (Szo), 16.47
Ez meg szerintem teljesen projekt függő.
Nekem is ez volt az első gondolatom, miután átfutottam a témaindítót.
8

Gondolom megvannak a

Joó Ádám · 2014. Feb. 1. (Szo), 17.56
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.


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) :)
9

A legjobb, amit tehetsz, az,

Joó Ádám · 2014. Feb. 1. (Szo), 18.01
A legjobb, amit tehetsz, az, hogy megírod a legkevesebbet, amire neked szükséged van, ha kell, általánosítasz rajta annyit, hogy már másnak is hasznos lehessen, majd közzéteszed, és a visszajelzések fényében általánosítod tovább ott, ahol kell, akkor, ha kell.

Ha nem így teszel, könnyen kifogyhatsz az oxigénből.
10

Haha, tetszik az analógia, ha

inf · 2014. Feb. 1. (Szo), 19.55
Haha, tetszik az analógia, ha túl magas absztrakciós szintre mész, akkor ritkul a levegő, és kifogysz az oxigénből :D