API design; centrale class bad en kleine classes good?

[stenvers]

Voor een klant ben ik de afgelopen tijd druk bezig geweest met de implementatie van een API die zowel een eigen database benaderd als data uit een backend systeem haalt.

Dit heb ik gedaan door een centrale class te maken die op basis van settings alles afhandeld, met een functiehook die eventuele post processing doet van de resulterende data. Mijn overweging daarbij was dat het zowel een single point of failure als succes was. Deze class bevat inmiddels filtering op het resultaat, paginering, totalen telling, en specifieke zaken als bijvoorbeeld het ophalen van profielbeelden van personen op basis van de id.
De API word door Cypress tests afgetest.

Mijn klant heeft dit laten reviewen door een bedrijf (overigens buiten mijn weten terwijl ik niet de beloofde tijd heb gekregen om de technische schuld in te lossen of de source code review klaar te maken).

Uit dat rapport kwamen diverse aanbevelingen waarvan de meeste inmiddels verwerkt zijn omdat het bekende problemen waren (de technische schuld) of gewoon zinnige aanvullingen/correcties.

Het punt wat is overgebleven is dat het advies is om van de centrale class af te stappen en kleine taakgerichte classes te maken. Dit voornamelijk met als motivatie dat dat beter onderhoudbaar zou zijn.

Ik heb daar moeite mee. Niet alleen vanwege onnodige risico’s op falen (de huidige API is in productie en draait prima), maar ook omdat de klant - met een maatschappelijke doelstelling - forse financiële tegenvallers kent en de kosten voor refactoring daar nog bovenop zouden komen. Daarnaast denk ik dat het juist meer werk is aanpassingen te doen en dat dat door het decentrale karakter ervan juist foutgevoeliger is.

Ik geef een voorbeeld van de huidige vorm en de nieuwe (dit is een simpele variant maar toont de structuur-verschillen goed):

JavaScript:

const apiretrieve = require("../classes/class_retrieve.js");
export default async (req, res) => {
    const options = {
        res: res,
        req: req,
        result_name: "gegevens",
        method: "GET",
        call: "persoon/{ID}?embed=bedrijven",
        return404: true,
        skip_userdetails: false
    }
    new apiretrieve(options);
});

Een mock-up van de voorgestelde aanpassing (dummy code, maar om het idee te duiden):

JavaScript:

const init = require("../classes/init.js");
const user = require("../classes/user.js");
const data = require("../classes/data.js");
const ret = require("../classes/ret.js");
export default async (req, res) => {
    const context = { 
        req: req, 
        res:res 
    };
    init_api( context );
    get_user_details ( context );
    fetch_data( context, "GET",   "persoon/{ID}?embed=bedrijven");
    ret_result( context, "gegevens" )
});

In mijn visie is een centrale class onderhoudbaarder want nieuwe functionaliteit op 1 plek kan worden gebouwd, getest en geimplementeerd worden met default gedrag voor backwards compatibiliteit.
Zo heb ik laatst de optie voor caching ingebouwd en de API endpoints waar caching gewenst was hoefden alleen een setting met de cache identifier op te nemen. Geen enkele regel code. Als er een bug was geweest had ik die centraal op kunnen lossen.
Bij de voorgestelde nieuwe structuur zullen die API endpoints zelf alle functionaliteit in de endpoint moeten hebben (cache id bepalen, maar ook het ophalen en bewaren)
Bij bugs of aanpassingen aan de logica moet dat dan in iedere endpoint worden gedaan.
En meer code = meer bugs.

Ik heb geprobeerd tussenwegen te bewandelen maar het advies blijft staan. Afscheid nemen van de centrale class is de enige juiste manier.

Donderdag besluit ik op basis van jullie reacties wat ik ga doen. Ik kijk daarom uit naar jullie oprechte mening (alles is welkom zolang onderbouwd) en waardeer nu al de tijd die je erin hebt gestoken om tot zover te lezen!

[farlane]

Als jij er van overtuigd bent dat jouw oplossing de beste is, laat je klant weten dat je staat voor je ontwerp/implementatie en waarom.

Als ze het advies van de derde partij zo belangrijk vinden dat ze het toch eisen, laat ze dan naar een andere partij gaan, in dat geval heb je volgens mij toch een relatieprobleem met die klant.

[Oon]

Alles dat generiek kan in de centrale class is prima, maar uiteindelijk wil je wel losse classes per entiteit, request etc om je data netjes gestructureerd op te slaan.

Als jouw klant bij het advies van een willekeurige derde partij blijft dan kun je een nieuwe inschatting doen en een nieuwe offerte sturen voor dit werk, want dat heeft niks met wat al staat te maken.

Ik zou hier echt niet alles voor aan omschrijven, jij hebt je werk gedaan en je kunt nu gewoon de factuur sturen, dat zij er zelf op eigen houtje voor kiezen om een andere partij in te huren voor een audit is niet jouw probleem tenzij dat ook deel was van de overeenkomst.

[ID-College]

In essentie gaat het er niet echt om of optie A beter is dan optie B. Voor veel cases zijn er meerdere wegen naar Rome, met ieder zijn voor- en tegens. Wat hier vooral belangrijk is, is hoe jij naar je relatie met de klant kijkt.
Uiteindelijk adviseer jij, maar het is aan de klant om te bepalen wat hij/zij wil, en welke argumenten daarbij zwaarder wegen.

Ik ben hier makkelijk in: als het niet pertinent fout is en weg B ook prima is, dan wil ik het best aanpassen met daarbij een offerte. In the end gaat het om een tevreden (=blije) klant. Ik ga alleen voor oplossingen liggen die echt gegarandeerd niet goed zijn. Als je zo wordt overruled, dat je dus in de situatie komt dat je iets moet bouwen wat echt verkeerd is, dan doe ik het niet. Voor dat soort klanten werk ik niet, en dat pad moet je ook niet in willen gaan als je weet waarvoor je staat

[RobIII]

Het klinkt alsof je de S in SOLID in ieder geval "schendt". Zoals jij je class beschrijft heeft 'ie veel te veel verantwoordelijkheden (data ophalen, sorteren, pagineren, filteren, totalentelling, "ophalen van profielbeelden van personen op basis van de id" ...).

Afgaand op de (vrij summiere, we zien natuurlijk maar een topje van een topje van een ijsberg) informatie die we hebben, waarbij de topictitel eigenlijk al de toon zette bij mij, denk ik dat bij een review mijn conclusie hetzelfde zou zijn geweest. Het advies "om van de centrale class af te stappen en kleine taakgerichte classes te maken", met de motivatie "dat dat beter onderhoudbaar zou zijn" klinkt als iets wat ik ook zou zeggen en is plausibel.

stenvers schreef op zondag 16 april 2023 @ 09:20:
Bij de voorgestelde nieuwe structuur zullen die API endpoints zelf alle functionaliteit in de endpoint moeten hebben (cache id bepalen, maar ook het ophalen en bewaren)

Je kunt toch een "centrale" cache class hebben die al die endpoints gebruiken? Als je, bijvoorbeeld, (een) DI (framework) gebruikt en die cache class injecteert in de endpoint constructors ben je er. Ik kan 't niet zien, maar afgaand op wat ik lees denk ik dat je dergelijke dingen (nog) niet doet. En het is maar één van de vele manieren waarop je 't kunt doen.

Algemeen zijn "kleine classes good" volgens velen; en daar sluit ik me bij aan. Er zijn (altijd) uitzonderingen, en het is verre van een harde regel, maar op 't moment dat classes de, zeg, 100+ regels benaderen is 't meestal tijd om eens te gaan kijken of 't niet anders/beter kan. Nu verschilt dat natuurlijk ook een beetje van taal tot taal en is het zoals gezegd echt geen harde regel. Maar wel een "rule of thumb" in mijn boekje

Verder wel eens met voorgaande posters; als de klant 't niet aan staat en jij achter je code staat dan zul je of moeten buigen (en bijbehorende factuur sturen) of je poot stijf moeten houden. Welke van de twee opties je kiest hangt af van jou, de relatie met je klant (die je wel-of-niet wil opgeven), tijd, geld enz. enz. Daar kun je codevoorbeelden tegenaan gooien tot je een ons weegt, maar dat is niet de basis waarop je die beslissing neemt

[ Voor 38% gewijzigd door RobIII op 16-04-2023 11:27 ]

[Merethil]

Het lijkt me ook voor de testability handiger om kleinere classes te maken, al is het maar omdat je niet onnodige dingen moet injecteren bij het bouwen van je grote class. Waarom zou ik bv een "CustomerRepository" moeten injecteren als ik alleen een stukje code wil testen dat slechts gebruikmaakt van een "OrderRepository" (voorbeelden volledig uit de lucht gegrepen).

Daar zijn ook weer oplossingen voor maar als je bv de DI gaat opdelen in je grote class dan kan je alles net zo goed omzetten naar kleinere classes, ook voor de leesbaarheid.

Daarnaast wil je misschien alleen classes inladen zodra je ze nodig hebt - waarom een db-connectie open laten staan voor een repository die eens per dag gebruikt wordt, of een stukje cache bouwen dat nooit geraakt wordt omdat het alleen in 1% van de gevallen nuttig is (om maar wat te noemen).

Bij de voorgestelde nieuwe structuur zullen die API endpoints zelf alle functionaliteit in de endpoint moeten hebben (cache id bepalen, maar ook het ophalen en bewaren)
Bij bugs of aanpassingen aan de logica moet dat dan in iedere endpoint worden gedaan.

Ik zou dan ook niet zo snel businesslogica opnemen in je endpoint/view maar dat opnemen in een herbruikbare generieke service/controller voor dat specifieke stuk logica/object/endpointtype/noem-een-andere-samenhangende-factor. Dan zit al die logica maar op één punt en is de herbruikbaarheid een stuk hoger.

[ Voor 25% gewijzigd door Merethil op 16-04-2023 12:02 ]

[Haan]

Wat de TS beschrijft klinkt als een zogenaamde 'God class', zoek daar eens info over op zou ik zeggen

[Lethalis]

Mijn ervaring is over het algemeen dat functionaliteit opsplitsen in meerdere classes, zodat elke class in principe 1 verantwoordelijkheid heeft, de betere oplossing is.

In grote projecten is het alleen erg belangrijk dat die kleine classes goed getest zijn en nooit of iig zo min mogelijk qua functionaliteit / werking veranderen. Dat is de O van SOLID (open zijn voor uitbreiding, maar gesloten voor verandering).

Heb je malloten in het team zitten die aan die classes gaan knutselen zonder dat er uitgebreide tests zijn etc dan wordt het systeem in zijn geheel onvoorspelbaar en instabiel. En dan zie je dus dat "God classes" na 20 jaar nog steeds werken en doen wat ze moeten doen, omdat in principe niemand het sloopt tenzij ze echt bewust met die class bezig zijn.

Maar goed, dat is wel een issue dat organisatorisch opgelost hoort te zijn. Als in: schrijf altijd unit tests, ontwerp ze volgens het open/closed principe, etc.

Is die discipline niet aanwezig in het team om wat voor reden dan ook, dan heb ik zelf iig begrip ervoor dat mensen hun eigen code afschermen. Ik programmeer zelf dus dingen weleens op een manier waar ik het eigenlijk niet eens mee ben, maar omdat ik ervan schijt dat anderen mijn programmatuur om zeep kunnen helpen (en regelmatig hebben gedaan) - en ik dan nog de schuld krijg ook * - ben ik soms geneigd de code die ik schrijf zelfvoorzienend te maken.

Dit is echter wel in een suboptimale situatie, werkend aan een groot legacysysteem. In projecten waar ik zelf meer controle over heb, splits ik het zoveel mogelijk op in kleine classes (SRP).

* De bekende "jij maakt alles ook zo complex dat niemand het begrijpt", "door jou weet ik niet in welke van de 20 bestanden ik moet zijn", etc.

[ Voor 9% gewijzigd door Lethalis op 16-04-2023 14:48 ]

[com2,1ghz]

Lethalis schreef op zondag 16 april 2023 @ 14:35:
Mijn ervaring is over het algemeen dat functionaliteit opsplitsen in meerdere classes, zodat elke class in principe 1 verantwoordelijkheid heeft, de betere oplossing is.

Nou ja het is immers een industrievoorschrift geworden. Helaas zijn er teveel ontwikkelaars in de praktijk die het fout aangeleerd hebben. Of van die ontwiikkelaars die het zelf via een tutorial geleerd hebben en eigenlijk het vak "software development" compleet hebben overgeslagen.

In grote projecten is het alleen erg belangrijk dat die kleine classes goed getest zijn en nooit of iig zo min mogelijk qua functionaliteit / werking veranderen. Dat is de O van SOLID (open zijn voor uitbreiding, maar gesloten voor verandering).

Heb je malloten in het team zitten die aan die classes gaan knutselen zonder dat er uitgebreide tests zijn etc dan wordt het systeem in zijn geheel onvoorspelbaar en instabiel. En dan zie je dus dat "God classes" na 20 jaar nog steeds werken en doen wat ze moeten doen, omdat in principe niemand het sloopt tenzij ze echt bewust met die class bezig zijn.

Maar goed, dat is wel een issue dat organisatorisch opgelost hoort te zijn. Als in: schrijf altijd unit tests, ontwerp ze volgens het open/closed principe, etc.

Is die discipline niet aanwezig in het team om wat voor reden dan ook, dan heb ik zelf iig begrip ervoor dat mensen hun eigen code afschermen. Ik programmeer zelf dus dingen weleens op een manier waar ik het eigenlijk niet eens mee ben, maar omdat ik ervan schijt dat anderen mijn programmatuur om zeep kunnen helpen (en regelmatig hebben gedaan) - en ik dan nog de schuld krijg ook * - ben ik soms geneigd de code die ik schrijf zelfvoorzienend te maken.

Dit is echter wel in een suboptimale situatie. In projecten waar ik zelf meer controle over heb, splits ik het zoveel mogelijk op in kleine classes (SRP).

* De bekende "jij maakt alles ook zo complex dat niemand het begrijpt", "door jou weet ik niet in welke van de 20 bestanden ik moet zijn", etc.

Als iemand dit zegt dan zegt dat meer over die persoon dan over jou. Ik zit ook in een organisatie nu waarbij unit testen achteraf worden geschreven(als ze uberhaupt geschreven worden) en men raar aankijkt als je zegt dat dit een verkeerde aanpak is. Ook overal en nergens god classes "omdat het echt niet anders kan". Testcoverage van 1 cijfer en dat is dat de applicatie classe die automatisch gegenereerd wordt als je een nieuw project start.
Echter wat ik zie bij al deze personen is dat merendeels geen IT achtergrond heeft maar er zo binnen is gerold en eigenlijk een aangeleerd truukje herhaalt.

[Lethalis]

com2,1ghz schreef op zondag 16 april 2023 @ 14:46:
[...]
Echter wat ik zie bij al deze personen is dat merendeels geen IT achtergrond heeft maar er zo binnen is gerold en eigenlijk een aangeleerd truukje herhaalt.

True. En daardoor heeft iedereen zijn eigen sterke maar ook zwakke punten. Collega van mij kan zich beter inleven in de klant dan ik, omdat hij nota bene zelf eenzelfde soort bedrijf heeft gehad als onze klanten. Maar qua programmeren is hij meer van de praktijk dan de theorie, om het zo maar te zeggen.

Ik ben dan weer iemand die eigenlijk teveel puur programmeur is. Ik vind het prachtig om mij te verdiepen in allerlei principes zoals SOLID, design patterns etc. Maar ik vind wat er bij de klant speelt eigenlijk niet zo interessant Hierdoor voel ik mij soms compleet nutteloos, "wat ben ik nou eigenlijk aan het doen?", en moet ik zelf op zoek naar bepaalde (technische) aspecten van mijn werk om ergens nog plezier uit te halen etc.

Programmeren is altijd mijn hobby en passie geweest. De dingen die ik programmeer voor de klanten en de klanten zelf niet zo zeer. Na 20 jaar werken als developer zit ik wel een beetje in een developer midlifecrisis

[DonJunior]

@Lethalis Ik heb echt precies hetzelfde als jij.. in de detachering, meerdere klanten al gehad. Begint een beetje herhaling van zetten te worden. In de categorie: Same shit different company.

Om ontopic te blijven: @stenvers Als de klant dit wenst en jij hebt jouw voorkeur uitgesproken en toegelicht dat het meer geld gaat kosten dan denk ik datbje duidelijk bent geweest. De keuze van de klant zou ik dan aanhouden. Je kan ook aangeven dat jij het dan niet gaat doen, dat ze dat een andere ontwikkelaar mogen laten doen en ga jij lekker op zoek naar een andere opdracht. Daar deze klant/werkgever toch al codereviews achter je rug om gaat doen lijkt het er op dat het vertrouwen niet echt tweeledig is.

[stenvers]

farlane schreef op zondag 16 april 2023 @ 10:16:
Als jij er van overtuigd bent dat jouw oplossing de beste is, laat je klant weten dat je staat voor je ontwerp/implementatie en waarom.

Als ze het advies van de derde partij zo belangrijk vinden dat ze het toch eisen, laat ze dan naar een andere partij gaan, in dat geval heb je volgens mij toch een relatieprobleem met die klant.

Dat relatieprobleem heb ik rechtstreeks gevraagd, maar daar zou geen sprake van zijn en alleen in dit soort besprekingen voel ik het.. grijs gebied zeg maar..

[stenvers]

Bedankt allemaal voor de reacties. Ben ik serieus blij mee! Ook al zijn jullie kritisch, dat is prima.

Ik ben inderdaad auto-didact en eerder pragmatisch dan dogmatisch.
Ook meer klant-gericht dan code-gericht zoals @Lethalis ook aangaf. Maar ik wil niet puur voor uurtje-factuurtje gaan, anders had ik deze kans wel aangegrepen om weer een factuurtje te kunnen sturen.

Dat wil dus niet zeggen dat ik niet netjes wil programmeren, vandaar dat ik het topic heb geopend.

Dat ik me niet aan SOLID hield was me bekend. De pragmaticus in had inderdaad de overhand.

Alles dat generiek kan in de centrale class is prima, maar uiteindelijk wil je wel losse classes per entiteit, request etc om je data netjes gestructureerd op te slaan.

Mijn gedachte was die classes te maken inderdaad en die vanuit de god-class (ja gegoogled) aan te roepen.
Ik zie dat een monolitische class zijn potentiele problemen heeft maar ook voordelen biedt. Als je die class als wrapper-class gebruikt voor onderliggende classes met ieder 1 taak zijn de onderdelen ervan prima te onderhouden. En dan centraliseer je wel intelligentie/functionaliteit, wat mijn uiteindelijke streven was.

Wat ik nog wel mis aan de reacties is de onderhoudbaarheid. Alleen houden aan principes is een nobel streven maar kan wel tot meer onderhoud leiden. De software development theorie gaat naar mijn mening daar wel aan voorbij. Ze zeggen wel dat het onderhoudbaarder is, maar ik mis onderbouwing daarvan. Of ik google verkeerd, links zijn welkom.

[dusty]

stenvers schreef op zondag 16 april 2023 @ 20:05:
[...]
Wat ik nog wel mis aan de reacties is de onderhoudbaarheid. Alleen houden aan principes is een nobel streven maar kan wel tot meer onderhoud leiden. De software development theorie gaat naar mijn mening daar wel aan voorbij. Ze zeggen wel dat het onderhoudbaarder is, maar ik mis onderbouwing daarvan. Of ik google verkeerd, links zijn welkom.

De code zal toch ergens moeten bestaan; In kleinere klassen is het echter beter te bepalen waar iets gebeurd; en kan je dus sneller je focus op de juiste code kunnen zetten. (want door de S van SOLID weet je wie er verantwoordelijk is; dus dan weet je (normaal) ook waar.)

[The Eagle]

@stenvers ik denk dat je blikveld te beperkt is

Code zal prima werken, of je hem nou opdeelt in subclass of niet. Kleinere classes zijn inderdaad makkelijker onderhoudbaar. Toen we nog Pascal en C deden en zelfs daarvoor wist iedereen dat je dingen in losse procedures in libs zette, juist daarom. Verschil was alleen dat je dan meteen een los bestand had, en al jouw code staat in Git dus zie je dat niet echt

Verder moet je je ook bedenken dat je niet weet wat je klant verder met die api wil, waar het ding (toekomstig) onderdeel van uit moet (gaan) maken en wat er verder voor plannen in de organisatie zijn. Dat kan prima een driver zijn om nu voor een iets andere oplossing te kiezen.

Verder zal er ongetwijfeld ook een budget zijn, wat nu op kan. Vanuit een dergelijk oogpunt kan het ook een prima reden zijn om te zeggen: pak nu de pijn maar even, nu kan het.

Als je jezelf capabel genoeg acht om over dergelijke zaken in een soort van architectuur rol mee te denken, vraag ze er dan gewoon naar. Wil je het niet weten (of acht je jezelf geen architecten rol) geef ze dan gewoon advies op basis van jouw kennis en laat de klant bepalen.

[eric.1]

stenvers schreef op zondag 16 april 2023 @ 20:05:
Wat ik nog wel mis aan de reacties is de onderhoudbaarheid. Alleen houden aan principes is een nobel streven maar kan wel tot meer onderhoud leiden. De software development theorie gaat naar mijn mening daar wel aan voorbij. Ze zeggen wel dat het onderhoudbaarder is, maar ik mis onderbouwing daarvan. Of ik google verkeerd, links zijn welkom.

Ik denk dat je daarvoor eigenlijk even uit je eigen perspectief van nu moet stappen. Jij kent de code nu precies, weet waar alles zit, wat alles doet en waar de afhankelijkheden zitten. Iets aanpassen? Geen probleem. Draag dit over (of kijk je er een half jaar niet naar om) dan zal jij of iemand anders dan, bij een change, een significant deel van die god-class moeten doorspitten om het goed aan te passen. Anders kun je gewoon de relevante classes aanpakken zonder je druk te maken over de rest - scheelt in alle gevallen tijd (en frustratie).

Als het een beetje meezit zal het schrijven van specifieke test-cases ook makkelijker zijn.

Features toevoegen, dan is het toch wel makkelijk dat een class gewoon een enkele verantwoordelijkheid heeft.

Dan kom je nog bij de praktischere zaken uit, wanneer bijvoorbeeld meerdere personen aan een project werken. Ga je allebij in zo'n god-class zitten te porren dan krijg je binnen de kortste keren conflicts die niet altijd even makkelijk op te lossen zijn.

Zelf ben ik actief in een open-source project waar er veel te veel verantwoordelijkheden in één file/class zijn gegooid. Dat werkte 15 jaar geleden prima, nu is iedere gerelateerde change een zoektocht en zijn bepaalde verzoeken gewoon niet binnen een degelijke tijd te implementeren en worden dus aan de kant geschoven. Dit zal dus nu moeten worden herschreven, iets wat natuurlijk niet had gehoeven indien het degelijk was opgezet. Maar goed, dat is zo gegroeid. It happens. Dit wil je natuurlijk gewoon voorkomen.

[Anoniem: 80910]

ik mis het volgende in je vraag, verwacht je in de toekomst zaken te doen met de klant. Er is een wens en die kan je vervullen door dit voor bijvoorbeeld de helt van de prijs te doen. ik denk dat je er een middagje druk mee bent.

Daarnaast is het topic eerder monolith vs micro service. Je kan ook vragen omdat met de database te doen (als ze groeien kun je meerdere servers van een db voorzien en hoef je geen krachtpatser aan te schaffen maar verdeel je het over meerdere servers). Jou app connect dan naar die verschillende servers toe ipv 1 server. dat is hetzelfde met code. je moet niet te veel opsplitsen maar net genoeg. opsplitsen van code in meerdere bestanden kost processor tijd en disk tijd. houdt daar rekening mee dat je niet te kleine classes gaat maken, maar voeg ze anders samen (performance winst van afhankelijk van de autoloader toch 3 msec per bestand). Ik weet nu niet of je node gebruikt of wat anders, maar een beetje opslitsen kan geen kwaad. ik heb nu een framework gebouwd en net even gekeken: 634 files in 111 folders zonder de vendor directory. Daarvan heb ik functies die gebruikt worden in mijn programmeertaal (R3m) allemaal in aparte bestanden gedaan. Dat was een design keuze net zoals je wordt aangeleerd om 1 class per file te gebruiken, meerdere kan wel maar is eigenlijk een bad practice. Daarnaast over class groottes is het verschillend. dat ligt eraan. zo heb ik een Token class en die is 2092 regels groot. De reden dat ik dat niet op splits is performance en tijd. Het zijn ook geen kleine functies maar als het kan splits je die ook op zo klein mogelijk maar ik kan je vertellen dat er grote functies zijn, kijk maar eens naar parsers, tokenizers.

[stenvers]

De berichten zijn duidelijk. Dank voor jullie bijdragen! Ik ga mijn 'zonden' overwegen en meewerken aan de refactoring om de alternatieve aanpak te beleven en te kijken of ik er ook enthousiast over word.

[farlane]

stenvers schreef op zondag 16 april 2023 @ 19:16:
Dat relatieprobleem heb ik rechtstreeks gevraagd, maar daar zou geen sprake van zijn en alleen in dit soort besprekingen voel ik het.. grijs gebied zeg maar..

Ah okay, volgens mij een positief signaal dat je klant en jij dat bespreekbaar hebben. In dat geval zou je natuurlijk aan de wens van de klant kunnen voldoen, als ze dat willen betalen.

[stenvers]

farlane schreef op maandag 17 april 2023 @ 20:51:
[...]

Ah okay, volgens mij een positief signaal dat je klant en jij dat bespreekbaar hebben. In dat geval zou je natuurlijk aan de wens van de klant kunnen voldoen, als ze dat willen betalen.

Ja precies. En nu ik lees dat het 'good practice' is kan ik daar alleen maar van leren, dus win-win.