Onder druk gezet worden om naar de donkere kant te GAAN

We hebben een situatie op het werk waarin ontwikkelaars die aan een verouderd (kern)systeem werken, onder druk worden gezet om GOTO-instructies te gebruiken bij het toevoegen van nieuwe functies aan bestaande code die al is geïnfecteerd met spaghetticode.

Nu begrijp ik dat er argumenten kunnen zijn om ‘slechts één kleine GOTO’ te gebruiken in plaats van tijd te besteden aan refactoring naar een beter onderhoudbare oplossing. Het probleem is dat deze geïsoleerde ‘slechts één kleine GOTO’ niet zo geïsoleerd is. Minstens een keer per week of zo is er een nieuwe ‘one little GOTO’ om toe te voegen. Deze codebase is al een gruwel om mee te werken omdat code die teruggaat tot of vóór 1984 vol zit met GOTO’s die veel Pastafari’sgeloven dat het werd geïnspireerd door het Vliegende Spaghettimonster zelf.

Helaas heeft de taal waarin dit is geschreven geen kant-en-klare refactoring-tools, dus het maakt het moeilijker om de ‘Refactoring om de productiviteit later te verhogen’ te pushen, omdat kortetermijnwinsten de enige overwinningen zijn waar hier aandacht aan wordt besteed. .

Heeft iemand anders dit probleem ervaren waarbij iedereen het erover eens is dat we geen nieuwe GOTO’s kunnen toevoegen om 2000 regels naar een willekeurige sectie te springen, maar dat analisten er voortdurend op staan ​​om het deze ene keer te doen en het management het goed te laten keuren?

tldr;

Hoe kan men het probleem aanpakken van ontwikkelaars die onder druk worden gezet (gedwongen) om voortdurend GOTO-instructies toe te voegen (met toevoegen bedoel ik toevoegen om naar willekeurige secties te springen, vele regels verder) omdat het datfunctie in sneller’?

Ik begin te vrezen dat we hierdoor waardevolle ontwikkelaars kunnen verliezen aan de roofvogels…

Verduidelijking:

Gahere

alsoThere:Nee, ik heb het over het soort goto dat 1000 regels van de ene subroutine in de andere springt halverwege een while-lus. Ga naarsomewhereClose

there:ik had het niet eens over het soort gotos dat je redelijkerwijs kunt lezen en bepalen wat een programma aan het doen was. Ga naaralsoThere

somewhereClose:Dit is het soort code dat gehaktballen maakt midpoint:Als je hier voor het eerst bent Ga naarnextpointdetail:(elk bijna compleet anders) Ga naarpointlessReturn

here:In deze vraag had ik het niet over het af en toe prima gebruik van een goto. Ga naar there

tacoBell:en het is net terug naar de tekentafel. Ga naarJail

elsewhere:Als analisten weken nodig hebben om te ontcijferen wat een programma doet elke keer dat het wordt aangeraakt, is er iets grondig mis met je codebase. In feite ben ik eigenlijk tot mijn hell:indien niet up-to-date goto4weergave van de spec goto detailpointlessReturn:ga naartacoBell

Jail:Eigenlijk slechts een kleine update met een kleine overwinning. Ik heb 4 uur besteed aan het herstructureren van een deel van dit specifieke programma, één label per keer, waarbij ik elke iteratie in svn opsloeg terwijl ik bezig was. Elke stap (ongeveer 20) was klein, logisch en gemakkelijk genoeg om naarbypassnextpoint:spontaan uit je maaltijd te springen en op je te springen scherm door een raar soort spaghetti-gehaktbal-magnetisme. Ga naarelseWhere
bypass:verifieer redelijkerwijs dat het geen logische wijzigingen zou moeten introduceren. Met behulp van deze nieuwe, beter leesbare versie heb ik met de analist om de tafel gezeten en bijna al deze verandering voltooid. Ga naarend

4:eerste *als de eerste keer hier naar de hellgaat, geen tweede als de eerste keer hier naar dehellgaat , geen derde als eerste keer hier ga naarhellvierde nu up-to-date ga naarhell

end:

Antwoord 1, autoriteit 100%

Hoeveel bugs zijn er geïntroduceerd vanwege verkeerd geschreven GOTO’s? Hoeveel geld hebben ze het bedrijf gekost? Verander het probleem in iets concreets, in plaats van “dit voelt slecht”. Zodra je het door de verantwoordelijke mensen als een probleem kunt laten herkennen, verander je het in een beleid zoals, “geen nieuwe GOTO’s voor iets anders dan het vereenvoudigen van de exit-logica voor een functie”, of “geen nieuwe GOTO’s voor functies die niet hebben 100% unit test dekking”. Na verloop van tijd het beleid aanscherpen.

Antwoord 2, autoriteit 43%

GOTO’s maken geen goede codespaghetti, er zijn een groot aantal andere factoren bij betrokken. Deze linux-mailinglijstdiscussiekan helpen om een ​​paar dingen in perspectief te plaatsen (opmerkingen van Linus Torvalds over de grotere foto van het gebruik van gotos).

Proberen een “no goto-beleid” in te voeren, alleen maar om geen gotos te hebben, zal op de lange termijn niets opleveren en uw code niet beter onderhoudbaar maken. De wijzigingen moeten subtieler zijn en gericht zijn op het verhogen van de algehele kwaliteit van de code, denken in de trant van het gebruik van best practices voor het platform/de taal, dekking van unittests, statische analyse enz.

Antwoord 3, autoriteit 14%

De realiteit van ontwikkeling is dat ondanks alle bloemrijke woorden over het op de juiste manier doen, de meeste klanten meer geïnteresseerd zijn in het snel doen. Het concept van een codebasis die snel op het punt staat te imploderen en de daaruit voortvloeiende gevolgen voor hun bedrijf is iets dat ze niet kunnen begrijpen, omdat dat zou betekenen dat ze verder moeten denken dan vandaag.

Wat je hebt is slechts één voorbeeld. Hoe je hierop staat, bepaalt hoe je in de toekomst aan ontwikkeling doet. Ik denk dat je 4 opties hebt:

1. Accepteer het verzoek en accepteer dat je dit altijd zult doen.

2. Accepteer het verzoek en ga direct op zoek naar een nieuwe baan.

3. Weiger te doen en wees bereid om te vechten om de puinhoop op te lossen.

4. Ontslag.

Welke optie je kiest, hangt af van hoeveel je je baan en je zelfvertrouwen waardeert.

Antwoord 4, autoriteit 14%

Misschien kun je het padvinderspatroon gebruiken: laat de plek een beetje schoner achter dan je hem aantrof. Dus voor elke featurerequest: voer geen nieuwe goto’s in, maar verwijder er een.

Dit zal niet te veel tijd besteden aan verbeteringen, het zou meer tijd geven om nieuw geïntroduceerde bugs te vinden. Misschien zou het niet veel extra tijd kosten als je een goto uit het onderdeel verwijdert, dat weliswaar tijd moest besteden aan het begrijpen en het introduceren van de nieuwe functie.

Beweer dat een refactoring van 2 uur in de toekomst 20 keer 15 minuten zal besparen en snellere en diepere verbeteringen mogelijk maakt.

Antwoord 5, autoriteit 11%

Terug naar principes:

• Is het leesbaar?
• Werkt het?
• Is het te onderhouden?

Antwoord 6, autoriteit 11%

Dit is het klassieke conflict tussen ‘management’ en ‘techneuten’.

Ondanks dat ik deel uitmaakte van het “techneut”-team, heb ik in de loop der jaren de “management”-kant van dit debat stevig geregeld.

Hier zijn een aantal redenen voor:

1. Het is heel goed mogelijk om goed geschreven, gemakkelijk te lezen, goed gestructureerde programma’s te hebben met gotos! Vraag het aan een willekeurige assembler-programmeur; voorwaardelijke vertakking en een primitieve do-lus zijn alles waarmee ze moeten werken. Alleen omdat de “stijl” niet actueel is en niet betekent dat het niet goed geschreven is.

2. Als het een zooitje is, zal het lastig zijn om de bedrijfsregels te extraheren die je nodig hebt als je het programma volledig wilt herschrijven, of als je een technische refactoring van het programma aan het doen bent u zult er nooit zeker van zijn dat het gedrag van het geherstructureerde programma “correct” is, dat wil zeggen dat het precies doet wat het oude programma doet.

3. Return on investment — vasthouden aan de oorspronkelijke programmeerstijl en minimale wijzigingen aanbrengen, zal minimale inspanning vergen en snel voldoen aan het verzoek van de klant. Veel tijd en moeite besteden aan refactoring zal duurder zijn en langer duren.

4. Risico — herschrijven en refactoring zijn moeilijk goed te krijgen, uitgebreide testen van de gerefactorde code is vereist en dingen die op “bugs” lijken, kunnen “features” zijn voor zover het de klant betreft. Een bijzonder probleem met het “verbeteren” van legacy-code is dat zakelijke gebruikers mogelijk gevestigde oplossingen hebben die afhankelijk zijn van het bestaan ​​van een bug, of het bestaan ​​van bugs misbruiken om de zakelijke procedures te wijzigen zonder de IT-afdeling hiervan op de hoogte te stellen.

Dus al met al staat het management voor een beslissing — “add one little goto” test de wijziging en breng het in productie in dubbele snelle tijd met weinig risico — of — ga voor een grote programmeerinspanning en heb het bedrijf schreeuwt naar hen als er een nieuwe reeks bugs opduikt.

En als je besluit om over vijf jaar te refactoren, zal een of andere hooghartige afgestudeerde student klagen dat je gerefactorde programma niet meer voldoet aan de modewoorden en eisen dat hij wekenlang mag besteden aan het herschrijven ervan.

Als het niet kapot is, repareer het dan niet!

PS: Zelfs Joel vindt dit een slecht idee: dingen die je nooit zou moeten doen

Bijwerken!-

OK als je de code wilt refactoren en verbeteren, moet je dit op de juiste manier doen.

Het fundamentele probleem is dat u tegen de klant zegt: “Ik wil n weken aan dit programma werken en, als alles goed gaat, zal het precies doen wat het nu doet.”– – dit is op zijn zachtst gezegd moeilijk te verkopen.

U moet langetermijngegevens verzamelen over het aantal crashes en uitval, de tijd die is besteed aan het analyseren en programmeren van ogenschijnlijk kleine wijzigingen, het aantal wijzigingsverzoeken dat niet is gedaan omdat ze te moeilijk waren, zakelijke mogelijkheden die verloren zijn gegaan omdat het systeem niet snel genoeg veranderen. Verzamel ook wat academische gegevens over de kosten van het onderhouden van goed gestructureerde programma’s versus het laten zinken.

Tenzij je een waterdichte koffer hebt om aan de bonentellers te presenteren, krijg je het budget niet. Je moet dit echt aan de bedrijfsleiding verkopen, niet aan je directe bazen.

Antwoord 7, autoriteit 4%

Ik moest onlangs aan een code werken die niet per selegacy was, maar de gewoontes van de voormalige ontwikkelaars waren dat zeker en dus waren GOTO’s overal. Ik hou niet van GOTO’s; ze maken er een afschuwelijke puinhoop van en maken van debuggen een nachtmerrie. Erger nog, het is niet altijd eenvoudig om ze te vervangen door normale code.

ALS u uw GOTO’s niet kunt afwikkelen, raad ik u zeker aan ze niet langer te gebruiken.

Antwoord 8, autoriteit 4%

Helaas heeft de taal waarin dit is geschreven geen kant-en-klare refactoringtools

Heeft u geen editors met macromogelijkheden? Heb je geen shellscripts? Ik heb in de loop der jaren heel veel refactoring gedaan, heel weinig met refactoring-browsers.

Antwoord 9, autoriteit 4%

Het onderliggende probleem hier lijkt te zijn dat je ‘analisten’ hebt die, vermoedelijk noodzakelijke, functionele veranderingen beschrijven in termen van het toevoegen van een goto aan een code. En dan heb je ‘programmeurs’ wiens taak beperkt lijkt te zijn tot het typen van die wijziging en er vervolgens over klagen.

Om iets anders te maken, moet die disfunctionele toewijzing van verantwoordelijkheden tussen die mensen veranderen. Er zijn veel verschillende manieren om het werk op te splitsen: de klassieke, conventionele (dat is zeer waarschijnlijk het officiële, maar genegeerde beleid in uw werk) is om analisten een implementatie-onafhankelijk specificatiedocument te laten schrijven en programmeurs dit te laten implementeren als zo goed mogelijk onderhouden.

Het probleem met die theoretische benadering is dat het in veel voorkomende situaties eigenlijk onwerkbaar onrealistisch is. Om het ‘op de juiste manier’ te doen, moeten werknemers die als junior worden beschouwd een ruzie winnen met collega’s die senior zijn, betere sociale contacten op kantoor hebben en zakelijker zijn. Als het argument ‘goto is niet implementatie-onafhankelijk, dus als analist kun je dat woord gewoon niet zeggen’ niet op je werkveld vliegt, dan is dit vermoedelijk het geval.

Veel beter zijn in veel gevallen alternatieven zoals:

1. analisten schrijven klantgerichte code en ontwikkelaars schrijven infrastructuur.
2. Analisten schrijven uitvoerbare specificaties die worden gebruikt als referentie-implementaties voor unit-tests.
3. Ontwikkelaars creëren een domeinspecifieke taal waarin analisten programmeren.
4. Je laat het onderscheid tussen de een en de ander vallen, met alleen een hybride.

Antwoord 10

Als een wijziging aan het programma “slechts één kleine stap” vereist, zou ik zeggen dat de code zeer goed te onderhouden was.

Dit is een veelvoorkomend probleem bij het omgaan met verouderde code. Houd vast aan de stijl waarin het programma oorspronkelijk is geschreven of “moderniseer” de code. Voor mij is het antwoord meestal om bij de originele stijl te blijven, tenzij je echt een grote verandering hebt die een volledige herschrijving zou rechtvaardigen.

Houd er ook rekening mee dat verschillende “moderne” taalfuncties, zoals Java’s “throw”-instructie of SQL’s “ON ERROR” in feite vermomde “GO TO”s zijn.