Heeft het op jouw manier doen ooit geholpen? Was er zelfs een keer een tijd dat je gebruik maakte van indirectie en injectie en extra interfaces, en er was een last-minute uitwijking, en het werd allemaal soepel en mooi afgehandeld zonder te schelden? Zelfs bij een vorige klus, als je die code hier nooit hebt kunnen vastleggen?

ga ik ervan uit dat dat wel het geval was. Oefen met het vertellen van dat verhaal. Het is specifiek en echt. Het is niet “x zou kunnen gebeuren” of “y zou kunnen veranderen” maar, “Ooit deed ik het op deze manier en dit is hoe het werkte.” Managers (ik praat als een) zijn leermatig over het uitgeven van geld (en geloof me, je schrijft meer gecompliceerde code die anderen niet kunnen begrijpen op een eerste pas is het uitgeven van geld) voor wat mogelijks kan gebeuren. Ze willen geen speculatie financieren die misschien alleen gebaseerd is op “boeken leren” en de laatste rage volgens het internet. Maar als je gebruik maakt van je ervaring? Dat is een heel andere situatie.

Ik ben geen grote fan van fabrieken, providers, injectoren en wat dies meer zij. Ze zijn over het algemeen ingesteld op dingen die nooit echt zullen gebeuren (overstappen van MS SQL naar Oracle) of een kleine impact hebben als ze dat wel doen (het veranderen van de map waar de bestanden worden opgeslagen). Ze hebben wel een plaats in regelingen die zeer volatiel zijn, waar je in lijkt te zitten. Je moet dus laten zien dat ze die plaats hebben. Je lijkt te komen van een positie van, “Dit is de normale manier om dingen te doen, en ik heb een reden nodig om dat niet te doen.” Je manager komt van, “Dit is niet normaal. Normaal is eenvoudig en simpel. Geef me een goede reden om een andere laag in de weg te leggen.” Werk aan die reden. Werk aan een verleden tijd, echt een succesverhaal waar die extra laag dagen of weken werk heeft bespaard. Rechtvaardig je engineering of anders is het echt over-engineering.

Dit citaat uit een van uw commentaren stoort me.:

Als software-ingenieur wordt het voor mij een tweede natuur om ‘te doen-dat-mei-niet-goede-op-de-grond’, zoals de onbekenden die ik noemde, aan elkaar te rijgen. Het voortdurend op het randje moeten staan van het uitleggen van diep technische (en soms sterk eigenzinnige) onderwerpen voert me af.

Ik heb verschillende herhalingen gezien van de volgende levenscyclus:

• Vaardig programmeerteam komt met een andere benadering van programmeren.
• Het wordt een paar jaar, tot een decennium, gezien als iets dat universeel gebruikt zou moeten worden, ondanks eventuele nadelen en beperkingen. Tijdens deze fase is het voldoende om te zeggen “Ik pas methodologie X toe” zonder te analyseren of X een netto voordeel is.
• Het gaat uit de mode, maar de meest bruikbare ideeën blijven bestaan als onderdeel van de software ontwikkelingstoolkit, om uit te trekken en te gebruiken wanneer ze netto voordelen opleveren.

Volgens mij zweven zowel TDD als ontwerppatronen rond de splitsing tussen de tweede en derde fase in de levenscyclus van de programmeermethodologie. Ik ben er zeker van dat TDD en veel ontwerppatronen een lange en waardevolle levensduur zullen hebben in de toolkit, om gebruikt te worden wanneer ze meer helpen dan ze pijn doen. Ik denk ook dat ze misschien nog steeds te veel gebruikt worden, door gewoonte in plaats van opzettelijk te denken.

Je moet nooit een ontwerppatroon toepassen omdat het een tweede natuur is, of je hebt moeite om het gebruik ervan uit te leggen. Denk in plaats daarvan, voordat je een ontwerppatroon toepast, na over de kosten en baten ervan in deze specifieke situatie. Als de voordelen echt opwegen tegen de kosten, zou je precies moeten weten waarom, dus het uitleggen van de afweging zou je niet moeten aftappen. Als de voordelen niet opwegen tegen de kosten, gebruik het dan niet. Nogmaals, je eigen denken over je ontwerp moet je voorbereiden om te antwoorden als je gevraagd wordt waarom je geen mogelijk toepasbaar ontwerppatroon hebt gebruikt.

Vergeet niet dat je moet nadenken over deze afwegingen in termen van de algehele onderhoudbaarheid van het programma, niet alleen om je stuk snel te laten werken. Te veel indirectie kan het voor toekomstige programmeurs moeilijker maken om uit te vinden wat er echt aan de hand is.

Ben ik de enige die verbaasd is over de manier waarop we in Workplace zoveel aandacht besteden aan coderingspraktijken in plaats van aan het eigenlijke conflict op de werkvloer? Dus ik zal het anders aanpakken.

Hier zijn de algemene aspecten van uw probleem zoals ik het zie:

1. U bevindt zich in een vakgebied dat samenwerking vereist
2. Er zijn geen gedocumenteerde procedures die bepalen hoe deze samenwerking moet worden uitgevoerd
3. Er is onenigheid over hoe deze samenwerking moet worden uitgevoerd
4. 4. Een van degenen die het niet eens zijn is je manager

Het klinkt voor mij alsof je groep samen moet komen en het eens moet worden over welke normen en praktijken je gaat toepassen en deze wereldwijd, ten goede of ten kwade, moet overnemen. Want niets is erger voor een product dan een team dat voortdurend op gespannen voet staat, en niets is erger voor je relatie met je werkgever dan voortdurend ruzie te maken met hen.

Dus probeer je team bij elkaar te krijgen om het eens te worden over een aantal normen, en gebruik die bijeenkomst om je zaak te bepleiten voor de praktijken die je gebruikt. Als je ze krijgt, geweldig! Zo niet, dan zij het zo. Het is niet jouw taak om mooie code te schrijven. Jouw taak is om een afgewerkt product te leveren. Als je werkgever (zoals belichaamd door je manager) en een veelheid van je groep erop staat dat je het op een bepaalde manier doet, wie ben je dan om ze te winnen?

Maar het klinkt alsof het grootste deel van je team het met je eens is, dus het zou tijdens deze discussies vrij duidelijk moeten worden dat je manager de vreemde is. Als deze persoon nog steeds weigert om over te stappen op de teamconsensus, dan is dat een disfunctie die we niet kunnen oplossen (anders dan je aan te bevelen om naar een ander team over te stappen).

Helaas is hij je manager, en je schrijft geen code zoals hij wil dat je die schrijft. Als hij management is, is hij misschien niet van plan om binnen 2-3 jaar uit het bedrijf te komen, zoals de meeste ontwikkelaars van plan zijn. Je schrijft code die moeilijker te repareren zal zijn voor je vervangers, daarom is hij moeilijk voor je om het op die manier te bouwen.

Als ik hier een veronderstelling mag maken, wetende dat ik ver van het doel af zou kunnen zijn, waar schrijf je dan dit spul voor? Ik zou nogal verbaasd zijn als het iets meer is dan LOB applicaties. Ontwerppatronen zijn waarschijnlijk veel te ingewikkeld voor een LOB applicatie die niet bepaald ingewikkeld hoeft te zijn.

In mijn 10 jaar van ontwikkelen is slechts drie keer een echte strategie/fabriekspatroon nodig geweest, waarvan twee keer uit banen:

• In een applicatie die productinformatie weergaf, waarbij sommige van die producten in wezen een stel kleinere producten in een doos waren, hebben we een strategie gebruikt om te bepalen welke fabriek nodig was om de productinformatie (opgevraagd via een sleutel) om te zetten in een weergave. Niet erg glorieus, maar het deed het werk. Als ik je nederige opschepperij over bugs mag evenaren, dan hebben we in mijn hele ambtstermijn daar nooit een enkele bug gehad!
• In een applicatie die gebruikers liet zien waar ze naartoe moesten voor een les die ze bijwoonden, gebruikten we een fabriek en een abstractie om een snelle verschuiving tussen een Bing Maps API en Google Maps API mogelijk te maken. Dit was omdat beide een kosten-batenverhouding hadden en het bedrijf geen vooruitgang boekte bij het bepalen van het gebruik. Uiteindelijk hoorden we vanuit ons thuiskantoor dat we al een API-sleutel hadden voor een van hen en dat we op de laatste seconde naar die API konden draaien, vlak voor de lancering.

En een derde is een project waar ik mee zit te knoeien, dat server monitoring doet voor Windows servers:

• Ik gebruik een interface voor het uitvoeren van de monitoring data en voor de monitoren zelf. De monitoren zijn zeer configureerbaar (op basis van applicatie-instellingen). De uitvoerimplementatie varieert afhankelijk van het feit of ik een nieuwe monitor aan het testen ben of dat ik naar implementatie ga, zodat IOutputInterface ConsoleOutput en SqlOutput als implementaties heeft die kunnen variëren.

Merk op dat mijn persoonlijk project onmiddellijk vaker gebruik maakt van patronen en inversie van controle (IoC) dan mijn werkprojecten.

Als ik u toch nog advies kan geven, laat het dan dit zijn: Een baan is een baan, en als je de dingen op jouw manier wilt doen, probeer dan een gelukkig medium te vinden. Technici blijven over het algemeen niet lang op hun plaats en het is niet de moeite waard om ruzie te maken met het management over hoe het moet. Laat je persoonlijke thuisprojecten zo veel als je wilt een patroonhoop zijn.

Eenvoudige oplossing: quit.

Harde oplossing: bij een meningsverschil ligt de helft van de fout bij jou.

Neem wat tijd vrij, bestudeer hoe andere teams werken, zoek uit waar de impedantie mismatch is tussen jou en de andere partij. Praat met hen persoonlijk, vroeg en vaak. Als je dit goed doet, leer je de zorgen en geloofsbrieven van de andere partij te begrijpen, en leren ze je te waarderen voor je input, ervaring en sterke meningen. Hier zijn een paar gebieden om te overwegen:

• kwaliteitsproduct vs. time to market
• goed product vs. goede code
• slimme code vs. zelfverklarende code
• top-down bedrijfscultuur vs. bottom-up engineering cultuur

Als het niet goed werkt, overweeg dan een andere rol in het team, een ander team in het bedrijf of, ten slotte, een ander bedrijf.

Als je met deze mensen geconfronteerd wordt, krijg je de grootste weerstand, sprinkhaan. Ik ben het meest effectief geweest in het brengen van verandering als ik strategisch de juiste drukpunten raakte. Het vergt veel geduld en veel toegeven. Ik moet me eerst aanpassen aan hen voordat ik druk uitoefen op de zwakke punten.

Leeg je geest, wees vormloos. Vormloos, zoals water. Als je water in een beker doet, wordt het de beker… Nu kan het water stromen of het kan neerstorten. - Bruce Lee

Luister naar ze en stel veel vragen. Guinely luisteren naar iemand neemt hun verlangen om zich te verzetten weg. Begrijp wat hun denken motiveert en spreek dan hun taal. Aangezien je overtuigingen axiaal zijn, weerspiegelt hij op dit moment waarschijnlijk je koppigheid, minachting en frustratie. Omdat je ondergeschikt bent, is het zijn keuze om niet mee te doen aan je golflengte en is het aan jou om de brug te bouwen.

Als je hem ziet zul je jezelf zien. Als je hem behandelt zul je jezelf behandelen. Als je aan hem denkt zul je aan jezelf denken. Vergeet dit nooit, want in hem zul je jezelf vinden of verliezen. - Helen Schucman

Een Wing Chun Kung Fu meester zal zijn tegenstander naar binnen trekken en de afstand sluiten voordat hij op zoek gaat naar en aanvalt op de centrumlijn waar hij het meest kwetsbaar is. Maak geen ruzie over details alleen om te winnen, vind de middenlijn van het grotere probleem en concentreer de druk daar.

Ik heb dagelijks te maken met ingenieurs die weigeren om nieuwe programmeerparadigma’s te herprogrammeren of te leren en ik heb een of andere vorm van “Ik ben hier al sinds de punchcards” argument meer keren gekregen dan ik kan tellen. Ik schat dat ik 80% van de gevechten heb verloren, maar die 20%…woh…ik heb grote veranderingen aangebracht. Ik klink misschien vaag, maar doe wat google-onderzoek naar enkele van deze sleutelwoorden en je krijgt wat ik bedoel.

Probeer ook op een nieuw squirrel project_ te komen dat je het op jouw manier kunt doen. Als het echt werkt en tijd of geld bespaart, dan komen de mensen tot jouw manier van denken. Als er geen nieuw project is, maak er dan een in je vrije tijd om een pijnpunt van het bedrijf op te lossen en niemand is geïnteresseerd in het nemen van de tijd om op te lossen.

Wat moet ik doen?

In de software engineering is de mate waarin code wordt geschreven (of overgeschreven) altijd onderhevig aan een zekere mate van interpretatie (mening). Voor mij neemt u de stappen die ik in uw functie zou zetten, maar uiteindelijk is uw manager degene die het licht moet zien…blijf het hem tonen.

Ik zou doorgaan, _ hoe pijnlijk het ook is, om precies te doen wat u doet en _aanwijzing van de investering in het gebruik van het ontwerppatroon waar u kunt, zonder uw manager te laten kijken bad.

Verander niet wat u doet onmogelijk voelt u zich risicodrager dan een berisping. Blijf ze de voordelen van het gebruik van het patroon laten zien, en uiteindelijk zouden ze zich moeten bewijzen.

Terwijl je de strijd voortzet, proberen om een aantal andere bondgenoten in het team te krijgen. Op deze manier ben je niet de enige stem die zich uitspreekt voor het patroon.

Op een gegeven moment weigeren ze echter dat je een keuze kunt maken of deze omgeving wel goed voor je is. Ik denk dat je er nog niet bent, maar het kan zijn dat je moet overstappen naar een omgeving die acceptabeler is voor goede coderingspraktijken.

Onthoud dat de strijd die je voert een marathon is. Als je de codeercultuur wilt veranderen, is het aan jou om de waarde van het patroon aan te tonen.

Ten eerste kunnen we aan de gegeven informatie niet zien wie er gelijk heeft. In feite zou ik, als ik wordt opgeroepen om het project te controleren, nog steeds moeite hebben om te beslissen wie er gelijk heeft, omdat u misschien ontwerpt met andere doelstellingen voor ogen. Maar ik denk dat de baas de doelstellingen beter kent dan u.

Ten tweede, uw vraag: “Hoe kan ik mijn baas overtuigen?” Het antwoord is, dat kan je waarschijnlijk niet. Uiteindelijk is hij de baas. De enige keer dat ik mijn baas overtuigde om zijn ideeën over software engineering te veranderen was nadat we een jaar lang een onbetrouwbaar stuk software hadden gepatcht dat was geschreven zoals hij het wilde, en we vertelden hem dat we het niet betrouwbaar konden maken, behalve door het anders te ontwerpen.

We weten niet wie er hier technisch gezien thuishoort - het kan een manager zijn die diep in het verleden vastzit, of een nieuwe ontwikkelaar die blindelings alle hype gelooft.

Maar hij is je manager, en je gaat niet om met de manager, je gaat om met zijn weigering om te doen wat je denkt dat het beste is, en staat erop om te doen wat je denkt dat het beste is. En dat is de normale gang van zaken, dat je manager de beslissing neemt. Het is ook de normale gang van zaken dat hij uiteindelijk verantwoordelijk is voor succes of falen, en niet jij. Hij heeft he het gezag. En hij heeft gelijk, je moet zijn autoriteit niet in twijfel trekken. Je kunt je afvragen of hij gelijk heeft, maar niet zijn gezag. Dus ofwel ga je ermee om ofwel verander je naar een bedrijf dat de dingen op jouw manier doet.

Ondertussen, in plaats van te denken dat de dingen niet gaan zoals je wilt, denk je na over hoe je de beste kwaliteitscode kunt produceren die je binnen je beperkingen kunt krijgen. Veel dingen kunnen op verschillende manieren worden gedaan. Er is “ongecompliceerd, slecht ontworpen” en “ongecompliceerd, goed ontworpen”. Ga voor het laatste.

De ervaring maakt het mogelijk om te beoordelen of de voordelen van het ontwerppatroon mogelijk en waarschijnlijk zijn in de toekomst. Als de toezichthouder _het patroon kent en het toch weigert, herkent hij waarschijnlijk het geval wanneer het toepassen van dit of een soortgelijk patroon niet loont. Soms is de ervaring in tegenspraak met de regels of is de kans groter dat ze worden geïnterpreteerd.

Er is een bekende opvatting dat kortere en meer eenvoudige code gemakkelijker te begrijpen is en meer openstaat voor belangrijke wijzigingen.

Ik stel voor om de programmering en de collegiale toetsing te koppelen. Dit zal uw collega’s helpen om uw code beter te begrijpen, want u moet waarom en hoe uitleggen zoals u het doet in tegenstelling tot achteraf.

Ofwel leren ze van u en zien ze waarom het slim is, ofwel leert u dat de beste programmeurs code schrijven die anderen kunnen onderhouden.