Renoverare
· Stockholm
· 20 199 inlägg
Inversion of control är ju ett måste i ett stort komplext system.G guggen skrev:[
Att få jobba med c idag är tyvärr en ynnest. Slippa alla jävla mediator, dependency injection skit o bara skriva solid rak kod
Det var och är en konst i sig att strukturera ett större rent c system.
Skulle aldrig vilja vara utan dependency injection i stora komplexa system. Det är ju ett helvete att hantera utan och blir sällan bra eller lätthanterligt.G guggen skrev:[
Att få jobba med c idag är tyvärr en ynnest. Slippa alla jävla mediator, dependency injection skit o bara skriva solid rak kod
Det var och är en konst i sig att strukturera ett större rent c system.
Renoverare
· Stockholm
· 20 199 inlägg
Någon som kan maintainability har talat menar du.G guggen skrev:
Håller med.4 40talshuset skrev:
Eller, det beror på, folk använder DI hur som helst. Folk använder det ju som en global stor massiv factory med massa fina features. Men på rätt plats är det fint, särskilt för test.
Problemet ofta med tex DI är att man kommer undan med ostrukturerad kod för bakomliggande system tar hand om det. Resulterar ofta i dålig performance.
Men jag brukade bygga "smarta" factories Ala DI själv förr i tiden, så klart det har sin plats i hundra k+ projekt.
Renoverare
· Stockholm
· 20 199 inlägg
Som vanligt inget är en silver bullet. Men utan DI går det ju knappt få till ett stort system.G guggen skrev:
Ok. Så använde man IoC så är det maintainable per automatik menar du
Nyfrälst?
Det finns en uppsjö av sätt att göra saker bra, i en flera hundra k monolit så kan väl IoC vara kanon, Men tyvärr ser man för mkt Net o java frälsta bygga microservices och annat avgränsat som om de vore monoliter på 100kloc+.
Keep it simple.
Renoverare
· Stockholm
· 20 199 inlägg
Jag skrev ju precis att inget är en silver bullet. Jag använde ioc tom i jättesmå system. Men inget pattern eller practices gör ett system bra per automatik. Men om man alltid har SOLID i bakhuvudet så brukar slutprodukten faktiskt bli vettig.G guggen skrev:Ok. Så använde man IoC så är det maintainable per automatik menar du
Nyfrälst?
Det finns en uppsjö av sätt att göra saker bra, i en flera hundra k monolit så kan väl IoC vara kanon, Men tyvärr ser man för mkt Net o java frälsta bygga microservices och annat avgränsat som om de vore monoliter på 100kloc+.
Keep it simple.
Edit: tom i vårt spel använder vi det. Dock ingen klassisk DI pga prestandakrav.
Lyckas man få en bra mentor kan språket vara vilket som helst. Det är otroligt värdefullt att få kunskapen om varför man gör på ett visst sätt snarare än hur man gör det. Att lära sig programmera går ganska snabbt bara man är bra på logiska problem. Men för att undvika att man lär sig ett felaktigt tänkande är det bäst att ha någon som lär en. Och inte akademiskt, utan av någon som jobbar med det och har lärt sig fallgroparna.
Annars skulle jag säga att ett relativt nytt språk är att föredra. Många äldre språk har tvingats lösa nya "features" på ett inte allt för vackert sätt pga bakåtkompabilitet. Som Java och lamdba tex. Go är väldigt intressant på många sätt och går att testa direkt på deras hemsida.
Annars skulle jag säga att ett relativt nytt språk är att föredra. Många äldre språk har tvingats lösa nya "features" på ett inte allt för vackert sätt pga bakåtkompabilitet. Som Java och lamdba tex. Go är väldigt intressant på många sätt och går att testa direkt på deras hemsida.
Jodå. Det görs hela tiden utanför .Net världen
Finns tex inte ens i go mm och hela k8 och väldigt mkt annat som är högpresterande, stort och reliable är byggt med sådant. Det finns många sätt att abstrahera system.
År andra sidan brukade iaf jag skriva egna smarta factories Ala DI förr i tiden (när det handlade om stora .Net projekt), men använde dem inte så som DI ofta används Idag, som kärnan i hela mjukvaran utan snarare som stöd.
Jag tror dock skillnaden idag är att man är fler devs per projekt och kanske med skiftande erfarenhet och kvalitet, då behöver man ett allmänt känt och vedertaget sätt att abstrahera delsystem. I en monolitvärld med tex .Net eller Java har då DI säkerligen given plats.
Renoverare
· Stockholm
· 20 199 inlägg
Du behöver inte ha monolit tänkt med DI. Jag låter varje modul själv hantera sin DI configG guggen skrev:Jodå. Det görs hela tiden utanför .Net världen
Finns tex inte ens i go mm och hela k8 och väldigt mkt annat som är högpresterande, stort och reliable är byggt med sådant. Det finns många sätt att abstrahera system.
År andra sidan brukade iaf jag skriva egna smarta factories Ala DI förr i tiden (när det handlade om stora .Net projekt), men använde dem inte så som DI ofta används Idag, som kärnan i hela mjukvaran utan snarare som stöd.
Jag tror dock skillnaden idag är att man är fler devs per projekt och kanske med skiftande erfarenhet och kvalitet, då behöver man ett allmänt känt och vedertaget sätt att abstrahera delsystem. I en monolitvärld med tex .Net eller Java har då DI säkerligen given plats.
Ser ut som klassik .Net.
Missförstå mig inte, har skrivit mkt sånt där och gör det fortfarande, motvilligt. Det är så man bygger med .Net idag. Plus att man lägger till 5 partterns till för att få extra mkt kod.
Men min inställning är att en stor del av kodkvalitet handlar om att minimera mängden kod, minimal komplexitet, prestanda samt att kunna följa exekvering. Det förlorar man mkt av. å andra sidan får man en enkel separation, dvs behovet av mjukvaru arkitektur minskar, nybakade .nättare vet hur det funkar och grymma möjligheter till testning.
Lite som macdonald's i mjukvara.
Renoverare
· Stockholm
· 20 199 inlägg
Fast du får ju bort sjuka mängder med boiler plate kod och kan koncentrera dig på domänen.G guggen skrev:
Prestandaförlusten är ju dessutom försumbar jämfört andra kostander som I/O osv
Exempel: 100% domänkod
Redigerat:
Fast nae, håller inte med dig. Det är nog antagligen du som är väldigt omodern om du motvilligt arbetar med DI och liknande. Varför skulle man lägga till flera patterns för att få mer kod? Vem vill ha mer kod än nödvändigt?G guggen skrev:
Behovet av arkitektur finns alltid och man bygger istället en arkitektur med DI, det ser alltså lite annorlunda ut, men behovet lär väl knappast minska direkt.
Varför skulle det vara svårare att följa koden när man använder DI? Tycker det blir betydligt mer komplext när man inte använder DI. Bara för att en instansiering av en klass inte exakt sker exakt på ett visst ställe så ger väl inte det direkt någon mer komplex kod om man vet hur det funkar? Satt i ett projekt där man inte använde DI alls och jag avskydde det alla dagar i veckan.
Har med några undantag levt på C++ de senaste 15åren men skulle jag rekommendera ett språk att starta med till någon skulle det vara som flera nämnt innan, Python, det är lättare att komma igång med och finns superkul bibliotek med lätta tutorials för att gör spel med och det går att använda till det mesta, skulle jag hoppa på något annat själv skulle det nog vara Rust, tyckte de hade en skön take på saker o ting. Gjorde en liten tå-dipp på Scala men det var inte för mig.