Du er nødt til at overbevise ham på det sprog, han forstår.

Er du i stand til at kvantificere virkningen af ​​en "dårlig" kode?

Hvor meget teknisk gæld har du fået, hvordan det påvirker udviklerens produktivitet, kodestabilitet, kvalitet.

Er du i stand til at give ham en demo på linierne af

1. Tag det værste område af koden kan være det buggiest, ustabilt eller udvideligt på grund af dårlig kode.
2. Vælg en aktuel metric - X antal timer, der skal gennemgås kode, Y antal fejl i øjeblikket i koden på grund af at den er af dårlige standarder, Z antal timer for at udvide den aktuelle kode til implementering af funktion A
3. Refactor eller redesign det
4. Reflekter over ændring og demonstrer, hvor meget tid det tager nu ..... X1, Y1, Z1

Dette vil ikke være trivielt indsats og kunne være et miniprojekt. Men hvis du føler stærkt om situationen og ønsker at ændre den, skal du ikke bede om tilladelse og gøre det og vise ham resultaterne.

For det første er 'behov for en omskrivning' vagt. Du skal være i stand til at tegne kasser omkring fornærmende kode eller definitioner.

Hvis den gamle udvikler skrev kode, der efterlod webstedet udsat for SQL-injektionsangreb, skal du vise din chef før og efter (hvad du har, hvad det skulle være, og konsekvenserne af den gamle stil). Er applikationen simpelthen formularer uden klasser til tabeller, ingen datatjenester, ingen brugerkontroller og ingen enhedstest? Vis ham derefter, hvordan du gennemgår 50 formularer, der foretager in-situ-kodedigeringer, når en enkelt kolonne føjes til en tabel. Uoverensstemmelser - vis ham form A udført på en måde og form B gjort en anden, og hvorfor de skulle have mere til fælles.

Hvis det ikke virker, bliver du nødt til at vise ham dårligt strukturerede biologiske systemer, og forklar, hvorfor den kode, du har, svarer til global opvarmning og forsuring af havet.

Givet yderligere detaljer (Python og spredt global variabel anvendelse) vil jeg beskrive det nuværende system i følgende udtryk: 'Inden for denne 200.000 linje codebase er der definitioner, der er 'synlige' for enhver kodelinje, og disse definitioner er tilfældigt spredt i filerne. Hvis nogen ændrer eller tilføjer nogen af ​​disse definitioner, skal alle involverede i projektet vide om dem, før de foretager ændringer fra deres side. En programmør, der gør dette alene, kan holde det lige, men det er ikke sådan, vi gør det. Vi er nødt til at udpege bestemte steder for ting at være, visse regler for ting, der skal følges, og visse mønstre, som, hvis vi ved, hvordan man gør det, ved vi lidt, hvad vi kan forvente for alle lignende strukturer. '

Start med at bladre ned gennem filerne, mens din chef er fjernbetjent i eller kigger over din skulder, søger efter de globale og beder din chef om at huske hver enkelt. Fortæl derefter ham, at du bliver nødt til at bringe ham i gang, når som helst nogen af ​​programmørerne ændrer eller tilføjer nogen af ​​disse variabler. Har en form for strukturel dokumentation, der forklarer, hvad dit mål er, og den minimale omkostningsmetode for at nå det.

En anden tilgang: antyd, at du har et regneark med 100 sider. Hver side har 1000 rækker gange 100 kolonner med værdier. Inden for disse 100 sider er der 100 'primitive' celler, der ikke har nogen formel - alle andre celler beregnes ud fra disse 100 'primitiver'. Hans job er at vide, hvor alle disse 100 primitive celler er, og holde i hovedet, hvad de gør for at påvirke regnearkberegningerne. Celler er forskellige steder i hvert regneark, og ingen har særlig fremhævning, skrifttyper eller baggrunde. I betragtning af dette regneark, bed 3 personer om at foretage strukturelle ændringer (ikke blot dataelementer), som i nogle tilfælde indebærer tilføjelse af nogle få 'primitive' celler. Det er op til alle i teamet at sikre, at disse ændringer koordineres.

Jeg har været i din situation mange gange før og har haft lignende problemer med arv af dårlig arkitektur og dårligt vedligeholdt kode i fortiden og nutiden. Heldigvis i min nuværende position har min chef en programmeringsbaggrund og har opmuntret mig til at gøre hvad jeg har brug for for at forbedre kvaliteten både fra et præstations- og forandringsledelsesperspektiv.

Fordi din chef mangler den tekniske ekspertise til fuldt ud at forstå, hvad du mener, vil du aldrig få hans / hendes buy-in på at foretage engrosændringer i koden. Det bedste, du kan håbe på, er at omstrukturere en genopbygning af den stykke for stykke, når du går videre. Udarbejd en masterinfrastrukturplan og instruer de andre udviklere om, at eventuelle fremtidige tilføjelser eller revisioner skal implementeres i henhold til denne plan. På denne måde får alle det, de ønsker - din chef får vandet til at køre, og du får installeret helt nye rør, hvor de er mest nødvendige, i stedet for at skulle lappe oven på pletter. Derudover vil det give dig lidt ekstra tid til at grave dybere ned i systemets eksisterende krav og indarbejde eventuelle "nye" anmodninger, der har siddet på bagbrænderen på grund af det nuværende systems ustabilitet.

Jeg oplevede de samme problemer med min nuværende chef. Jeg sad dog med ham og forklarede ham, hvorfor jeg troede, at det var nødvendigt at ændre koden. Da din chef ikke har en programmeringsbaggrund, skal du måske prøve at forklare ham problemet med en analogi. Forklar problemet som et dagligdags problem, for eksempel: hvis vi byggede en bil, ville køretøjet ikke fungere på grund af dette og det designproblemer, derfor skulle vi redesigne. Måske med en anden tilgang vil din chef forstå mere klart hvorfor du skal omskrive koden. Jeg må understrege, at du ikke nødvendigvis skal "bebrejde" forfatteren af ​​koden for de åbenlyse mangler (selvom han skrev det dårligt i første omgang), fordi det kunne give dit chef et forkert indtryk og give dig unødvendige problemer. Foreslå i stedet måder, hvorpå du kan forbedre koden, og forklar, hvorfor du mener, at det er den rigtige vej.