Bare fordi. Jeg er av den oppfatning at tusen små ns’er er en PITA, så jeg begynner heller med et utils.clj som man da kan/bør/må følge med på og splitte opp. Typisk tegn på at man bør splitte opp er når man begynner med banner-comments a-la:

;;;
;;; File-utils
;;;

Ser den — jeg liker heller ikke 100 små navnerom. Man kan putte utils-funksjonen sammen med der den skal brukes. Men da kan det bli vanskelig å vite når man bør trekke ut et nytt navnerom. Tror også dette er veldig sensitivt til erfaring, vanskelig å vite når/hvordan man bør splitte uten å ha gjort det noen ganger.

Jeg tror kanskje jeg ville startet med et stort navnerom, så kanskje etterhvert splitta ut i et utils og så når utils blir stort og uoversiktlig, splitta det opp i under-utils.

Jeg har ikke vært så bevisst på det men det føles naturlig for meg å gjøre alt i én fil/ett navnerom i starten. Jeg bruker bare core.clj ganske lenge og når et "tema" viser seg oppretter jeg en ny fil/et nytt navnerom. Men det er kanskje en ganske naiv måte å gjøre ting på? Fordelen er at jeg tvinger meg selv til å ikke tenke så mye på det store og abstrakte i begynnelsen før det blir litt mer konkret, men baksiden er at det virker litt tilfeldig og kanskje går på bekostning av designet/arkitekturen.

Om jag skriver en app från scratch börjar den alltid med ett enda ns.

Jeg er forøvrig av den oppfatning at det store problemet er at man ikke klarer å splitte koden slik at man får funksjoner som burde bo i utils 🙂

Hva mener du får funksjoner?

Jeg mener at hvis man ikke tenker seg om, så skriver man store funksjoner som gjør alt for mye.

Som med fordel kunne vært delt opp i mindre funksjoner, der noen av de funksjonene typisk etterhvert burde havne i util eller core eller noe.

@U3X7174KS Jag är nyfiken på vad i Tonskys artkel och cjohansen’s föredrag är så lika. Jag har inte sett föredraget, men på beskrivningen verkar det handla om olika saker?

@U0ETXRFEW Tonsky skiller mellom “reusable libraries” og “business code”. > It also makes thinking about dependencies somewhat easier. You have a two-part graph: reusable libraries and business code. The bottom half can depend on the top half, but not vice versa. Here’s how it looks in Grumpy right now (arrows means “depends on”) […] I vedlagt skjermbilde viser Tonsky et eksempel fra egen kode. Cjohansen skiller mellom “ui-komponenter som ikke vet noe om domenet, som kun heter feks knapp” og “domenekode”. Fra https://www.kodemaker.no/blogg/2020-01-enkel-arkitektur/ (som jeg ser er signert av Magnar og ikke Christian, men jeg klarer ikke skille ideene til Magnar og Christian fra hverandre): > UI-komponentene er uavhenging av domene og kontekst. Jeg mener at Christian argumenter for samme prinsipp i Javazone-presentasjonen også. Jeg leser tonsky sin “reusable libraries” som Christians/Magnars “UI-komponenter uavhengig av domene og kontekst”, og “business code” som “domenekode”.

Når jeg leser kommentaren min på nytt, innser jeg at det slett ikke var åpenbart hva jeg mente 😅

Tack. Jag uppfattade Tonskys inlägg som att det mer handlade om att bryta isär sitt utilities-namespace, men jag var kanske snål i min läsning. 😃

Ja, enig, Tonsky snakket mest om utils. Jeg tolket en del!

I #C013B7MQHJQ drar man library-tänket ett steg längre uppfattar jag det som. Och man begränsar det inte till icke affärskod.

Spennende. jeg er interessert i å kunne behandle mer av koden min som “bibliotekskode”.

Jeg tenker umiddelbart på Functional core, imperative shell. Ikke 1:1 overlapp, men der handler det om å ha så mye forretningslogikk som mulig uttrykt med pure functions. Hvis disse i tillegg jobber på generiske datastrukturer så kan mange av dem være “biblioteksfunksjoner”