Consistentie namen tussen domain, model, en code?

[flowerp]

Deze week ben ik een opmerkelijk probleem tegengekomen m.b.t. naamgeving.

Het zit zo dat ik normaal uitsluitend intern werk als lead developer/designer. Vanaf volgende week ga ik echter voor een korte periode werken bij een ander bedrijf, dat in feite een klant is van het bedrijf waar ik nu werk. Dit bedrijf heeft een bestaande technische afdeling en ik zal hier samenwerken met een andere lead developer en tevens wat implementatie werk doen.

Om alvast voor te bereiden ben ik vrijdag middag langs geweest en hebben we een design opzet voor het project door besproken dat ik al eerder gemailed had. De persoon die daar de designs en modellering doet bleek er (mijn inziens) nogal een opmerkelijke visie op na te houden wat betreft de naamgeving. In het kort staat hij erop dat namen uit je user/problem domain niet overeenkomen met de namen in je model en de namen in je uiteindelijke sourcecode. Zoals ik het altijd heb geleerd (zowel op school als van mensen die vroeger boven mij stonden bij vorige werkgevers) is het de bedoeling dat de namen juist wel overeenkomen.

De motivatie van deze meneer was ongeveer dat vanwege het feit dat een software product in principe taal onafhankelijk ontworpen moet worden, het geen zin heeft om de namen overeen te laten komen, daar elke overeenkomst slechts op een toevalligheid van 1 bepaalde taal is gebaseerd. B.v. voor de Engelse markt is het maar een toevalligheid dat het model/design en de sourcecode ook in het Engels is; de Engelse markt is daarbij maar 1 van de velen markten en door in de modellering bewust andere termen te gebruiken dan in het user domain van de Engelse markt gebruikelijk is, koppel je deze beter los...

Concreet gaat het om het volgende. Er dient een systeem gebouwd te worden voor het reserveren van booten. Daarbij komen diverse specifieke dingen kijken (b.v. koppeling met waarschuwing voor scheepsvaart), maar alleen het concept "reserveer boot" was al aanleiding voor de hele controverse.

Uit diverse gesprekken met stakeholders bleek dat de user domain term overduidelijk "boat" (en) is.

Mijn idee was om in het design een entiteit te modelleren die "boat" heet en deze dan uiteindelijk te implementeren d.m.v. een classe "Boat". Deze term komt uiteindelijk ook weer terug in de userinterface. Als een lijst van instanties van "Boat" op het scherm wordt afgedrukt zal een tekst gebruikt worden als "List of boats", en als iemand 1 van deze selecteert "You have selected the following boat:". In het Nederlands zou de userinterface dan de meest directe vertaling gebruiken: "boot" en in het Duits waarschijnlijk "fahrzeug".

Zijn idee was echter dat het design en de source-code perse een term moest gebruiken die juist niet overeenkomt met de Engelse user domain term. Hij wilde dan ook perse de term (synoniem) "vessel" gebruikt zien in de source-code. De motivatie was dus dat de Nederlandse en Duitse termen ook niet overeen konden komen, en we Engels niet moesten gaan voortrekken. Ook melde hij nog dat het zeer gebruikelijk was om voor user domain en implementation domain termen synoniemen te gebruiken.

Nu wil ik zeker niet stellen dat ik wijsheid in pacht heb, maar ik vind dit eigenlijk maar een beetje vreemd. De boeken en online resources die ik er op na sla lijken allemaal te zeggen dat de namen juist wel overeen moeten komen.

Nu moet ik echter nog veel leren op het gebied van modelering, dus ik vraag me af of mensen die hier wat meer ervaring mee hebben kunnen vertellen of het inderdaad zo is dat namen juist niet overeen moeten komen.

[Verwijderd]

Hoewel ik nog maar heel weinig ervaring heb is in mijn ogen die man fout bezig.

Je maakt het jezelf nodeloos ingewikkeld door een dergelijke strategie te volgen en ik vind zijn beargumentering ook kant noch wal raken.
Het is toch veel gemakkelijker om dezelfde termen te gebruiken, dat is ook voor mensen die de source en modellering na jullie bekijken erg handig, want zo ziet het er voor hen ook wat logischer uit. Het komt dus de onderhoudbaarheid zeker ten goede.

Zijn idee was echter dat het design en de source-code perse een term moest gebruiken die juist niet overeenkomt met de Engelse user domain term. Hij wilde dan ook perse de term (synoniem) "vessel" gebruikt zien in de source-code. De motivatie was dus dat de Nederlandse en Duitse termen ook niet overeen konden komen, en we Engels niet moesten gaan voortrekken. Ook melde hij nog dat het zeer gebruikelijk was om voor user domain en implementation domain termen synoniemen te gebruiken.

Ik blijf het een raar verhaal vinden, sowieso schrijf ik mijn code en documentatie 9 van de 10 keer in het Engels, tenzij Nederlands een verplichting is (en dan nog hou ik de code zelf in het Engels, ik vind het bijzonder lelijk om zo'n halve mix te creeren).

[ Voor 44% gewijzigd door Verwijderd op 01-12-2007 19:10 ]

[citegrene]

Ik denk wel dat je de taal van je interface los moet zien van de class namen, maar er bestaat nu eenmaal geen neutrale taal, dus kan je alleen maar uitgaan van de gemeenschappelijke taal van de ontwikkelaars/toekomstige ontwikkelaars.
Het verplichte van gebruik van class namen die niet in je interface voorkomen lijkt me een onnodige moeilijkheid. En als je zoiets wel toepast dan zie je toch eigenlijk je interface niet los van je classes

/edit
geheel irrelevant info terzijde:
fahrzeug = een auto
boat(de) = boot = boat
schiff(de) = schip = vessel
schip != boot

[ Voor 15% gewijzigd door citegrene op 01-12-2007 20:13 ]

[TERW_DAN]

Mijn insziens moet je zorgen dat je de entiteiten beschrijft zoals ze zijn. Dus een gebruiker noem je een 'user' , een boot noem je een 'boot' en zo verder. Door afwijkende entiteiten te gaan gebruiken in je applicatie en de daadwerkelijke processen ga je alleen maar inconsistenties en verwarringen in de hand brengen. Het is de bedoeling dat je je applicatie bouwt adhv een procesmodel met de daarin genoemde entiteiten en processen en die ook overeen laat komen met hetgeen wat er daadwerkelijk gebeurd. Dus niet zomaar wat gaan bedenken, dat slaat nergens op. Het is de bedoeling dat je software aansluit op de bedrijfsvoering, niet de dat bedrijfsvoering zich maar een beetje moet gaan aanpassen op wat de ontwikkelaar heeft bedacht.

Imho is dus man dus gewoon fout en ook onlogisch bezig. Taal voortrekken slaat nergens op, ik schijf zelf alles in het Engels, simpelweg omdat iedereen dat kan lezen en je dan een uniforme standaard aan kan houden. Dus persoonlijk heb ik het idee dat die man gewoon een beetje tegendraads wil doen en niet gelooft wat iedereen zegt.

Nu ben ik niet echt een software engineer, maar heb wel een beetje verstand van bedrijfsprocessen en procesmodelering en het implementeren daaromtrent.

[flowerp]

citegrene schreef op zaterdag 01 december 2007 @ 19:06:
Ik denk wel dat je de taal van je interface los moet zien van de class namen,

De taal staat sowieso losgekoppeld. Er zijn natuurlijk 2 soorten class namen:

1) Classes die entiteiten uit het user domain modelleren (Boat, Reservation, Sailor, etc)
2) Implementatie classes (FileReader, XMLTransformer, BuferredRenderer, etc)

Het gaat hier natuurlijk om 1)

Als iets in het user domain "Boat" heet, noem je de corresponderende class in je implementatie dan ook "Boat" (of iets wat hier sterk op lijkt, zoals wellicht "BoatBean"), of ga je expliciet andere termen verzinnen, zodat de user domain "Boat" in code correspondeert met de class "Vessel" of "VesselBean", "VesselEJB", etc.

[Freee!!]

Ook ik vind dat je gelijk hebt, maar gelijk krijgen kon nog wel eens een groot probleem worden.
Simpelste oplossing: Wie betaalt bepaalt. Als zijn baas de hele zaak betaalt, schik je je gewoon naar hem (na je eigen baas ingeseind te hebben). Zeker ook omdat je (zoals ik uit het verhaal begrepen heb) je bij dat andere bedrijf zit, lijkt mij dat het verstandigste.

[Confusion]

flowerp schreef op zaterdag 01 december 2007 @ 18:10:
Zijn idee was echter dat het design en de source-code perse een term moest gebruiken die juist niet overeenkomt met de Engelse user domain term.

Het lijkt me dat je je in onmogelijke bochten moet wringen om dat voor elkaar te krijgen. Er zijn altijd wel synoniemen te bedenken, maar welke meerwaarde biedt dat volgens hem dan? Het blijft een Engelse user domain term is, alleen eentje die deze users, op dit moment toevallig niet gebruiken. Het bemoeilijkt communicatie met de opdrachtgever/gebruiker, omdat jullie dan met verschillende termen hetzelfde bedoelen.

Hij wilde dan ook perse de term (synoniem) "vessel" gebruikt zien in de source-code.

'Vessel' lijkt me net zo goed een Engelse user domain term en wel eentje die je misschien voor een toekomstige superklasse zou willen gaan gebruiken, als de organisatie bijvoorbeeld besluit ook waterfietsen te gaan verhuren. Dan zou je de code moeten aanpassen op het moment dat ze ook waterfietsen gaan verhuren en over hun 'watervoertuigen'/'vessels' gaan spreken, want die term mag je dan niet meer in de code gebruiken?

Ook melde hij nog dat het zeer gebruikelijk was om voor user domain en implementation domain termen synoniemen te gebruiken.

Het kan best zijn dat de users consequent over 'booking' spreken, terwijl ze niet alleen reizen verkopen, maar ook verzekeringen en ik de actie in de code een 'purchase' noem, omdat een 'booking' bij mij onderdeel van een 'purchase' is. Users spreken niet altijd in de goede termen over hun eigen business. Van de User Domain termen afwijken bemoeilijkt communicatie, maar als het 'logisch' is, dan pikken ze het meestal snel genoeg op en spreken met jou in die term. Gewoon stug blijven verbeteren .

[flowerp]

Freee!! schreef op zaterdag 01 december 2007 @ 19:43:
Als zijn baas de hele zaak betaalt, schik je je gewoon naar hem (na je eigen baas ingeseind te hebben). Zeker ook omdat je (zoals ik uit het verhaal begrepen heb) je bij dat andere bedrijf zit, lijkt mij dat het verstandigste.

Inderdaad, ik ben zeker niet te beroerd om me gewoon te schikken naar de conventies die ergens anders gelden. Als ik er de kans toe krijg wil ik nog wel even vragen wat de andere programmeurs daar nou vinden van de aanpak van hun lead, maar ik kom natuurlijk niet ergens om meteen herrie te gaan schoppen

Dit topic is wat dat betreft meer theoretisch van aard. Ik weet nu al dat ik hem toch niet ga overtuigen, maar hij deed het echt voorkomen alsof ik enigszins gek was en dat -iedereen- altijd verschillende namen kiest voor entiteiten uit je user domain en de corresponderende entiteiten in model en code. Ik begon dus al wat te twijfelen aan mijn eigen aanpak zoals ik het normaal intern doe en vandaar dus dit topic.

[Verwijderd]

Volgens mij is hij zélf de enige die het op die manier wil zien.
Is het niet gewoon typisch mannelijke-koppigheid-kijk-eens-hoe-groot-mijn-piemel-is gedrag

[Freee!!]

Verwijderd schreef op zaterdag 01 december 2007 @ 20:17:
Is het niet gewoon typisch mannelijke-koppigheid-kijk-eens-hoe-groot-mijn-piemel-is gedrag

Lijkt me eerder een gevalletje van overcompensatie.

[flowerp]

Confusion schreef op zaterdag 01 december 2007 @ 20:08:
Het lijkt me dat je je in onmogelijke bochten moet wringen om dat voor elkaar te krijgen. Er zijn altijd wel synoniemen te bedenken, maar welke meerwaarde biedt dat volgens hem dan?

Wat ik er uit begreep was uiteindelijk een sterkere loskoppeling van je code en (met name) de tekst die in de interface gebruikt wordt. Als de user domain naam "boat" is, en je noemt in code je class "Boat", en je geeft dan ook in de userinterface "Boat" weer, dan staat de tekst die je in je userinterface weergeeft impliciet (voor je gevoel) gekoppeld aan code. Dat is slecht, omdat de interface tekst in een bepaalde taal (hier Engels) maar 1 mogelijke weergave is. Er zijn velen andere talen en die 'koppelen' ook niet aan de code. Koppelen is hier dan niet echt koppelen in de hardcoded zin, maar koppelen in de zin dat de programmeur ze gelijk wil houden.

Omdat de userinterface zo vluchtig is en ook nog eens vaker kan veranderen, kun je de termen maar beter vanaf het begin verschillend maken, zodat programmeurs bij het veranderen van een naam die de userinterface weergeeft (wat dus feitelijk de user domain naam is) niet geneigd zijn de code ook te gaan renamen. Aldus hem.

Het kan best zijn dat de users consequent over 'booking' spreken, terwijl ze niet alleen reizen verkopen, maar ook verzekeringen en ik de actie in de code een 'purchase' noem, omdat een 'booking' bij mij onderdeel van een 'purchase' is. Users spreken niet altijd in de goede termen over hun eigen business.

Inderdaad, en het is dan ook de taak van b.v. de requirements engineer om een heldere set van user domain termen boven water te krijgen. Daar kunnen dan termen bij zitten die de echte users nog niet of niet consequent gebruiken, maar die (in overleg met de 'domain experts') wel de meest logische termen blijken te zijn. Vanuit die set van termen ga ik dan zowel het model opstellen als de namen die in code gebruikt worden op baseren.

Als de set van termen uit het userdomain b.v. {Boat, Sailor, Harbor} is, dan begin ik ook te werken vanuit het principe dat je in de userinterface ook precies die termen gebruikt en dat je classnames ook precies die termen gebruiken voor hun naamgeving. Het kan dan zijn dat in bijzondere gevallen de namen gebruikt in code en de namen gebruikt in de userinterface (dus de domain namen) af moeten wijken. Booking en purchase is wellicht een goed voorbeeld als is gebleken dat purchase weliswaar logischer is, maar dat de gebruikers nog niet klaar zijn voor dat onderscheid.

Mijn motto is in dat geval een beetje: "De namen gelijk houden, tenzij er goede redenen voor zijn om daar van af te wijken". Zijn motto was meer: "De namen verschillend maken, tenzij ze toevallig wel overeen moeten komen"

[dusty]

Dan zou òòk het woord 'vessel' verkeerd zijn, immers kan ook wat er wordt verkocht veranderd worden, waardoor de juiste term volgens zijn eigen logica de naam 'item' gebruikt zou moeten worden. Als hij namelijk het systeem generiek wilt opzetten, zal hij toch echt het systeem compleet los moeten zien van wat er uiteindelijk verkocht/verhuurd word. Iets wordt verhuurd dus dat is een item.

Er zijn dus wel redenen om het redelijk los te koppelen. Maar dat is dan dat je generieke code wilt gebruiken die vaker herbruikt kan worden voor andere applicaties. Deze "lead" heeft de klok horen luiden maar weet gewoon niet waar de klepel hangt, en hangt dus ergens tussen een wal en schip in met zijn methode.

[BCC]

dusty schreef op zaterdag 01 december 2007 @ 21:48:
Dan zou òòk het woord 'vessel' verkeerd zijn, immers kan ook wat er wordt verkocht veranderd worden, waardoor de juiste term volgens zijn eigen logica de naam 'item' gebruikt zou moeten worden. Als hij namelijk het systeem generiek wilt opzetten, zal hij toch echt het systeem compleet los moeten zien van wat er uiteindelijk verkocht/verhuurd word. Iets wordt verhuurd dus dat is een item.

Ik denk dat je het beste alles Object kan noemen, dan kun je er nog alle kanten mee uit . Opzich is het bij Naming wel handig om iets generiekers te pakken als je in de toekomst wil gaan uitbreiden. Maar later een klasse hernoemen is nou ook niet bepaald rocket science. Ik vind het allemaal nogal een non-issue.

[Confusion]

flowerp schreef op zaterdag 01 december 2007 @ 21:31:
Omdat de userinterface zo vluchtig is en ook nog eens vaker kan veranderen, kun je de termen maar beter vanaf het begin verschillend maken, zodat programmeurs bij het veranderen van een naam die de userinterface weergeeft (wat dus feitelijk de user domain naam is) niet geneigd zijn de code ook te gaan renamen. Aldus hem.

Als er nu staat 'boten' en ze volgende week bedenken ze dat ze daar liever 'schepen' hebben staan, dan kan ik me voorstellen dat het object 'Boat' hernoemd wordt naar het 'Ship'. Dat lijkt me echter een zeldzame situatie, want boten in het userdomain worden niet opeens schepen. En als het dan een keer nodig is: waarom is dat een probleem? Alt-shift-R return return en het is gepiept. Dat moet je natuurlijk niet doen als de taal van de UI verandert, maar als iemand dat wel doet, dan moet je de werknemer die dat doet veranderen; niet de manier waarop je code ontwikkelt.

Het Engels heeft een bijzondere positie, omdat de code en het commentaar daar in geschreven wordt. Alle termen die je kan verzinnen, zouden als term in het user domain op kunnen treden. Wat doe je als de opdrachtgever volgende week 'vessels' wil hebben, waar nu 'boats' staat? ThingieThatAllowPassengersToBeTransportedAcrossAFluidum?

Als de set van termen uit het userdomain b.v. {Boat, Sailor, Harbor} is, dan begin ik ook te werken vanuit het principe dat je in de userinterface ook precies die termen gebruikt en dat je classnames ook precies die termen gebruiken voor hun naamgeving.

Het zorgt ervoor dat je ontwikkelaars dezelfde termen hanteren als de opdrachtgever/gebruikers, waardoor je als mediator tussen die twee niet telkens 'vertalingen' hoeft te maken. Daarmee zorgt het er ook voor dat de ontwikkelaar het user domain beter voor ogen kan houden en niet te abstract aan de slag gaat, want dat gaat mis.

Het klinkt alsof hij een keer een slechte ervaring heeft gehad en dit als Silver Bullet ziet.

[JKVA]

BCC schreef op zaterdag 01 december 2007 @ 22:07:
[...]

Ik denk dat je het beste alles Object kan noemen, dan kun je er nog alle kanten mee uit . Opzich is het bij Naming wel handig om iets generiekers te pakken als je in de toekomst wil gaan uitbreiden. Maar later een klasse hernoemen is nou ook niet bepaald rocket science. Ik vind het allemaal nogal een non-issue.

Behalve als straks andere applicaties afhankelijk zijn van jouw applicatie. Dan wil je echt niet dat zij allemaal opnieuw moeten releasen, alleen maar omdat jij slordig bent geweest in je naamgeving.

[Confusion]

JKVA schreef op zondag 02 december 2007 @ 15:06:
Behalve als straks andere applicaties afhankelijk zijn van jouw applicatie. Dan wil je echt niet dat zij allemaal opnieuw moeten releasen, alleen maar omdat jij slordig bent geweest in je naamgeving.

Als je een publieke API ter beschikking stelt, dan wordt het inderdaad lastiger. Maar dat is meer uitzondering dan regel; de meeste applicaties zijn self contained en dan heb je de vrijheid om het iedereen makkelijker te maken door een klasse gewoon te hernoemen.

Het wel of niet aanwezig zijn van een publieke API verandert in ieder geval niet het vraagstuk: is het in een applicatie voor een organisatie die zeilboten verhuurt beter om een object 'Vessel' te hebben, dan een object 'Boat'?

[Orphix]

Ik vind de argumentatie die hij aangeeft ook vreemd. Wat voor zin heeft het om een synoniem te gebruiken.. dit geeft per definitie hetzelfde aan? Het maakt het enkel complexer.

Ik probeer zelf zoveel mogelijk aan te sluiten bij de vocabulaire van het user domain, maar er zijn een aantal situaties waarbij het in mijn ogen geen probleem is, of zelfs beter, om hiervan af te wijken. Dit zijn:

1. Abstractie. Je ziet een oplossing die generieker opgelost kan worden en introduceert een naam die de abstractie voorstelt. Dus bv bij een reserverings systeem dat je ipv 'truck' het meer abstracte woord 'carrier' gebruikt aangezien je beseft dat voor de gebruiker het wellicht altijd een truck is, maar dat de applicatie ook 'airplane' en 'boat' moet ondersteunen.

2. Functie-specifiek domein. Je hebt niet enkel te maken met het domain van de gebruiker, maar ook met de domeinen die specifiek voor bepaalde functies zijn. Zo heb je binnen de accountancy wereld een eigen terminologie. Net zo zeer voor operations management (scheduling). In dat geval wil je 'carrier' vertalen naar 'resource' en 'transportorder' naar 'job', om zo beter aan te sluiten bij de terminologie van de scheduling.
.

[flowerp]

Orphix schreef op zondag 02 december 2007 @ 17:03:
1. Abstractie. Je ziet een oplossing die generieker opgelost kan worden en introduceert een naam die de abstractie voorstelt. Dus bv bij een reserverings systeem dat je ipv 'truck' het meer abstracte woord 'carrier' gebruikt aangezien je beseft dat voor de gebruiker het wellicht altijd een truck is, maar dat de applicatie ook 'airplane' en 'boat' moet ondersteunen.

Daar zit zeker wat in, maar zou je in dat geval niet gewoon een inheritance hiërarchie introduceren? In zo'n geval kun je misschien beter "carrier" modelleren met als child "truck". Ik kan me zo voorstellen dat je anders later problemen krijgt in gevallen dat je nu lijsten afdrukt van "carriers" (die eigenlijk "trucks" zijn), maar later een keertje alleen "trucks" of alleen "airplanes" wilt afdrukken.

[Orphix]

flowerp schreef op zondag 02 december 2007 @ 19:49:
Daar zit zeker wat in, maar zou je in dat geval niet gewoon een inheritance hiërarchie introduceren? In zo'n geval kun je misschien beter "carrier" modelleren met als child "truck". Ik kan me zo voorstellen dat je anders later problemen krijgt in gevallen dat je nu lijsten afdrukt van "carriers" (die eigenlijk "trucks" zijn), maar later een keertje alleen "trucks" of alleen "airplanes" wilt afdrukken.

Oh absoluut, heb je helemaal gelijk in. Mijn punt was meer dat je het concept, en dus ook het woord, 'carrier' toevoegd aan je vocabulaire. In zekere zin maakt dat het iets lastiger om te communiceren met de klant omdat die het continu heeft over 'truck' en in de code staat veelal 'carrier'. En er moet dus continu die vertaalslag worden gemaakt. Van user->developer zal dat nog wel gaan, immers de invoering van het concept carrier is juist door de developer geintroduceerd. Belangrijker is dat je bij het terugcommuniceren van developer->user weer aansluit in de belevingswereld van de user en dus niet 'carrier' moet zeggen maar 'truck'.

Of om het in programmeurs termen te benoemen: voor de developer is de software een classe, maar voor de user is het een object; een specifieke instantie wat voor de user van toepassing is. Dit brengt (communicatie)problemen met zich mee, maar dat is de prijs die we betalen om tot een meer generieke oplossing te komen.

[Herko_ter_Horst]

In mijn ervaring werkt het afwijken van terminologie tussen user en code verwarring in de hand: er moet steeds een mentale conversieslag worden gemaakt als de user "boat" zegt of de programmeur "vessel". Ik zou dus zeker kiezen voor het gelijk houden van terminologie, tenzij dat niet kan.

Je kan bijvoorbeeld in een automatiseringssysteem voor een lingeriewinkel beter "String" niet gebruiken

[Verwijderd]

Ik zou er ook voor kiezen om het gelijk te houden, met een enkele uitzondering.

Ik heb graag het liefste het geheel in het Engels, dit omdat dit in de sourcecode het beste leest (Nederlands gemixed met Engels van de programmeurtaal leest niet prettig), daarnaast is het Engels vaak bij mensen met verschillende afkomsten de taal die het grootste deel wel (gedeeltelijk) onder de knie heeft. Niets zo erg als werken met een Duitser die vervolgens de helft van z'n comments en varnamen in het Duits doet zodat je er geen hout van snapt, of erger nog met Indiers bijvoorbeeld.

Devies is dus alles in het Engels.

Probleem daarmee is dat de documentatie vaak wel in het Nederlands is (de opdrachtgever moet het immers ook voor het grootste deel kunnen begrijpen), ik gebruik hierbij dan meestal Nederlandse vertalingen voor de Engelse termen en voeg een nomenclatuur toe waarin ik de vertalingen zet.

Op die manier is de documentatie dus goed leesbaar en worden overal consequent de Engelse termen gebruikt.

Dit alles staat natuurlijk los van de interface, deze is veelal meertalig en dan laat ik de vertalingen over aan een vertaalbedrijf. Programmeurs moeten in mijn ogen ook zo min mogelijk te maken hebben met interface aangezien je dat beter aan designers en front-end coders kunt overlaten.

[Fish]

je kan iets reserveren bij een bedrijf .. mooi.

de moet je code zoveel mogelijk universeel houden, goed
Maar noem het dan geen vessel ... noem het dan een resource, aangezien je meerdere resources hebt kun je deze nummeren, en linken naar een tabel met je resource eigenschappen

als je alles gelijkende namen geven kan dat wel een voor interpertatiefouten zorgen.
maar ja als het niet uitmoet makene dan moet hij ook niet zueren

puntje bij paaltje, blijft hij je opdrachtgever, en vraagt hij iets specifieks waarvoor hij betaald.
dus adviseren, en als hij het dan toch niet wil, gewoon doen wat hij vraagt.

[flowerp]

Orphix schreef op zondag 02 december 2007 @ 20:02:
Van user->developer zal dat nog wel gaan, immers de invoering van het concept carrier is juist door de developer geintroduceerd. Belangrijker is dat je bij het terugcommuniceren van developer->user weer aansluit in de belevingswereld van de user en dus niet 'carrier' moet zeggen maar 'truck'.

Inderdaad, ik snap helemaal wat je bedoeld. Er zijn zeker een aantal (soms meer dan minder) termen die je als developer bedenkt. Ik probeer dan wel zelf die termen die dan hoofdzakelijk in de code gebruikt gaan worden toe te voegen aan het lijstje van user domain names en deze toch te overleggen met de domain experts. Dit kan natuurlijk niet altijd, want het kan zijn dat de namen die jij verzint gewoon niet bekend zijn bij de domain experts. Domain experts klinkt gewichtig, maar zijn dikwijls ook maar gewone gebruikers

In het geval van 'carrier' zou ik dat dus bedenken als algemenere term voor "truck". Vervolgens ga ik naar de domain expert / opdrachtgever, en leg de situatie voor dat ik voor mijn code een generiekere term nodig heb dan "truck", en of "carrier" ok is. Misschien heeft men allang al een meer generieke term en dan neem ik die over. Zo niet, dan heb ik dus het user domain potentieel beïnvloed door een term te introduceren.

Nu kan het in dat laatste geval wel eens fout gaan; jij introduceert een meer generieke term en gebruikt die in je code, maar geeft deze nog nergens weer aan de user. Later gaan de users ook meer generiek over de dingen denken en introduceren zelf een generieke term die afwijkt van wat al in de code gebruikt wordt, zeg "transporter". Als je nu de code uitbreidt door de "carriers" weer te geven, zul je misschien de term "transporter" gebruiken terwijl het in de code dus "carriers" heet.

In mijn ervaring zijn dat echter eerder uitzonderingen dan de regel. Als de code helemaal in je eigen beheer is kun je er nog voor kiezen om die naam dan gewoon in je code te updaten.

Verwijderd schreef op zondag 02 december 2007 @ 20:14:
Dit alles staat natuurlijk los van de interface, deze is veelal meertalig en dan laat ik de vertalingen over aan een vertaalbedrijf.

Het is natuurlijk een grote vraag of dat losstaan inderdaad zo is.

Stel je hebt met je opdrachtgever afgesproken dat de user domain term "boat" is. Jij baseert je code op deze term (m.a.w. je gebruikt classes als b.v. Boat, BoatManager, etc). Echter, de interface moet dan natuurlijk ook weer de term "boat" gebruiken, dat is namelijk de term die je had afgesproken met de opdrachtgever.

Beetje in schema:

code:

user domain: "boat"  <-----------------------------------------
       |                                                      |
       |                                                      |
model/design: "boat"                                          |
       |                                                      |
       |                                                      |
business code: "Boat", "BoatManager", "BoatRetriever"         |
       |                                                      |
       |                                                      |
UI interface: "selected boat", "List of boats", "new boats" --|

In elk geval zorg je dus dat de user domain term en de interface term overeenkomen. Die zijn eigenlijk ook hetzelfde (je geeft de UI namelijk weer aan de user).

In het geval dat de code Engels is (meestal dus), dan zou dat inhouden dat de Engelse user domain term (en dus ook de interface term) eigenlijk automatisch overeenkomt met de term die je in je code gebruikt, tenzij er natuurlijk zwaarwegende redenen zijn om hiervan af te wijken.

[LauPro]

Wat je even duidelijk moet hebben is of het hier de beste man puur om de terminologie gaat of dat het daarwerkelijk ook technisch wat uit moet maken.

Want zoals eerder gezegd, een boot is geen schip (boat <> vessel). En dit soort nuances liggen in sommige bedrijven heel gevoelig. Het is een beetje hetzelfde als een auto <> vrachtauto, dat is ook niet hetzelfde. Een vrachtwagenverhuurbedrijf zou er dan ook moeite mee hebben als zijn vrachtwagens als 'auto's' in het systeem zijn ondergebracht.

Verder lijkt het me geen probleem om synoniemen te gebruiken omdat deze vaak ook wat meer nuances toevoegen.

Storm in een glas water dus wat mij betreft.

[flowerp]

LauPro schreef op zondag 02 december 2007 @ 21:40:
Want zoals eerder gezegd, een boot is geen schip (boat <> vessel). En dit soort nuances liggen in sommige bedrijven heel gevoelig.

[...]
Verder lijkt het me geen probleem om synoniemen te gebruiken omdat deze vaak ook wat meer nuances toevoegen.

Nou, het geval is dat "vessel" geen enkele nuance toevoegt die op de een of andere manier beter is. Het gaat er in dit geval enkel om dat het iets anders is dan de term die in het userdomain voorkomt: "boat".

Dat is wat anders dan de uitzonderingsgevallen die enkele tweakers hier boven noemen, b.v. een meer generieke term gebruiken.

[LauPro]

flowerp schreef op zondag 02 december 2007 @ 22:25:
Nou, het geval is dat "vessel" geen enkele nuance toevoegt die op de een of andere manier beter is. Het gaat er in dit geval enkel om dat het iets anders is dan de term die in het userdomain voorkomt: "boat".

Laat ik het anders zeggen: het is mij nog nooit gelukt om na 1 bespreking een volledig beeld te krijgen wat een klant precies wil. Natuurlijk wel de hoofdlijnen maar ik zou nooit zo snel al van dit soort details al een punt maken, zoals eerder gezegd kan je met een beetje refactoring dit soort dingen snel wegwerken eventueel. De klant heeft jouw hulp ingeschakeld, dat betekent dus dat ze zelf op zekere hoogte het ook niet weten anders was het geen discussiestuk.

Het komt op mij iig een beetje over als een discussie over de kleur buitenlamp bij het bouwen van een nieuwbouwwoning terwijl er nog geen tekening is.

Wat je zelf ook al constateert is dat de redenvoering van de persoon in kwestie kant nog wal raakt. Alleen het feit dat bepaalde ideeën worden verworpen met 'dat het geen zin heeft' zegt al genoeg. Zorg ervoor dat je het volledige model in kaart hebt (over de verschillende lagen) en bespreek het dan nogmaals. Je kan dan inzichtelijk maken waarom die consistentie nodig is of waarom het beter zou zijn. Als het dan alsnog een eis is dat er daadwerkelijk synoniemen worden gezocht om taalconflicten te vermijden maak er een notitie van en schrijf op dat het een 'design choice' is van de persoon in kwestie.

[BCC]

JKVA schreef op zondag 02 december 2007 @ 15:06:
[...]

Behalve als straks andere applicaties afhankelijk zijn van jouw applicatie. Dan wil je echt niet dat zij allemaal opnieuw moeten releasen, alleen maar omdat jij slordig bent geweest in je naamgeving.

Nee. Mijn interne naming en externe naming houd ik altijd gescheiden. In basis zijn ze natuurlijk wel hetzelfde. Als je dat niet doet kun je nooit meer je eigen code refactoren zonder alle externe applicaties te breken. Dat lijkt mij echt een onwerkbare situatie.

[ Voor 6% gewijzigd door BCC op 03-12-2007 08:49 ]

[Verwijderd]

flowerp schreef op zondag 02 december 2007 @ 21:03:
[...]
Het is natuurlijk een grote vraag of dat losstaan inderdaad zo is.

Helaas is dat anno 2007 nog steeds de vraag inderdaad

In mijn boek is het in ieder geval per definitie zo: UI en de achterliggende code staan los van elkaar.

[Alarmnummer]

Ik zou zelf ook gaan voor naamgeving die in het domein wordt gebruikt. Voor zoiets helders als een boot/schip zullen verschillende namen wellicht niet zo veel problemen opleveren (mensen kunnen zelf wel nagaan dat ze nagenoeg hetzelfde zijn), maar het gaat zeker voor problemen zorgen als de concepten uit het domein complexer zijn en niet direct voor zichzelf spreken. Je kunt dan nog heel lastig met een klant communiceren omdat je dus niet in dezelfde termininologie kunt uitdrukken en je overal met een vertaalslag moet werken.

[edit]
Naast naamgeving probeer ik de code zo dicht mogelijk tegen het probleem domein aan te laten liggen. Het is geweldig als de klant over je schouder meekijkt en je kunt hem daarin heel eenvoudig de workflow laten zien ipv dat het volledig geintegreerd is in je Java code. Ik denk ook dat DSL's daar een belangrijke rol kunnen spelen.

[edit2]
We zien regelmatig problemen doordat we de software in het engels schrijven (ivm samenwerking india) en de klant in het nederlands werkt. Dit maakt communicatie al een stuk lastiger.

[ Voor 41% gewijzigd door Alarmnummer op 03-12-2007 14:28 ]

[Verwijderd]

Alarmnummer schreef op maandag 03 december 2007 @ 14:21:
[edit2]
We zien regelmatig problemen doordat we de software in het engels schrijven (ivm samenwerking india) en de klant in het nederlands werkt. Dit maakt communicatie al een stuk lastiger.

Inderdaad, dat was ook mijn ervaring.

Daarom is de documentatie in het Nederlands met een nomenclatuur toegevoegd.

[JKVA]

Alarmnummer schreef op maandag 03 december 2007 @ 14:21:
[...]
[edit2]
We zien regelmatig problemen doordat we de software in het engels schrijven (ivm samenwerking india) en de klant in het nederlands werkt. Dit maakt communicatie al een stuk lastiger.

Eensch, om die reden zie je bij veel (niet internationaal georienteerde) bedrijven dat de voertaal (ook in de code) Nederlands is.

Vaak wordt ook het argument aangedragen dat bepaalde termen moeilijk te vertalen zijn, vooral als het juridische of branchspecifieke termen zijn.

Bovendien wordt het zo moeilijker om werk naar India te verplaatsen dus mij hoor je niet klagen.

[BCC]

JKVA schreef op maandag 03 december 2007 @ 16:16:
[...]
Vaak wordt ook het argument aangedragen dat bepaalde termen moeilijk te vertalen zijn, vooral als het juridische of branchspecifieke termen zijn.
Bovendien wordt het zo moeilijker om werk naar India te verplaatsen dus mij hoor je niet klagen.

Volgens mij kun je ook sommige dingen niet uitbesteden aan India. Ga jij maar eens uitleggen/specificeren hoe het zorgstelsel hier inelkaar steekt. In de tijd dat het je kost om 1 iemand het daar te laten begrijpen heb je zelf al 3x de oplossing inelkaar gezet.

Extreme programming is iig per definitie niet uit te besteden... en laat daar idd nu steeds meer vraag naar komen. Ik klaag ook niet

[ Voor 9% gewijzigd door BCC op 03-12-2007 16:51 ]

[flowerp]

Verwijderd schreef op maandag 03 december 2007 @ 10:29:
[...]

Helaas is dat anno 2007 nog steeds de vraag inderdaad

In mijn boek is het in ieder geval per definitie zo: UI en de achterliggende code staan los van elkaar.

Ik snap nou niet helemaal waar je 't over hebt. Bedoel je nu qua code of qua termen? Wat code betreft is dat natuurlijk zo gebruikelijk dat het amper een discussie waard is. MVC, multi-tier, etc... tis al zo oud als dat we programmeren ongeveer

Wat termen betreft is het dus de rode draad van dit topic. Als je in de UI de term "boat" gebruikt, puur en alleen omdat "boat" de overlegde en geaccepteerde user domain term is, gebruik je dan ook in de code de term "boat" om je classnames op te baseren. Om het conceptueel makkelijker te maken, kun je stellen dat we in beginsel alleen voor de Engelse markt programmeren en de sourcecode ook in het Engels is.

[Voutloos]

Als de verzameling woorden binnen het user domain gegeven is, maak daar dan gewoon gebruik van.

Als je een synoniem gebruikt, trek je alsnog een taal voor, namelijk de taal waar je het synoniem uit kiest. Dus als je echt objectief wil werken mag je alle vars x, y, z gaan noemen.

Dat users meerdere talen gebruiken is al complex genoeg, dus zorg gewoon niet voor een extra uitdaging door het toevoegen van nog een vertaalslag.

[mOrPhie]

fish schreef op zondag 02 december 2007 @ 20:25:
de moet je code zoveel mogelijk universeel houden, goed
Maar noem het dan geen vessel ... noem het dan een resource, aangezien je meerdere resources hebt kun je deze nummeren, en linken naar een tabel met je resource eigenschappen

Dat moet je alleen doen als je veel verschillende typen resources denkt te gaan onderhouden. Als het aantal typen (redelijk) vast ligt, is het juist goed om zo dicht mogelijk bij de user domein te blijven. Dat ontwikkelt prettiger en sneller. Generaliseren van resources kan later altijd nog.