Beste antwoord
Interessante vraag. Voor mij betekent de term “vakmanschap” iets over de manier waarop de eigenlijke code is geschreven, in plaats van over het systeemontwerp op een hoger niveau. Ik zou zeggen dat goed gemaakte code het volgende doet:
- Volgt externe standaarden
- Volgt interne standaarden
- Gebruikt goede patronen
- Is leesbaar
Volgt externe normen. Als uw groep coderingsnormen heeft, volg deze dan. Als u dat niet doet ” Houdt niet van de standaarden, maar volg ze nog steeds.
Volgt interne standaarden. Dit betekent dat code intern consistent moet zijn. Methoden die soortgelijke dingen doen, moeten op dezelfde manier worden uitgelegd. Als een methode het patroon volgt:
if (success) {
doSomething();
} else {
handleError();
}
geen andere methode die begint:
if (!success)
{
handleError();
Gebruikt goede patronen. Hiermee bedoel ik codeerpatronen in plaats van ontwerppatronen. Uw code moet idiomen gebruiken die geschikt zijn voor de taal. (gebruik scoped\_ptrs bijvoorbeeld voor geheugenbeheer in C ++). objecten die niet in elk codepad worden gebruikt.
Is leesbaar. Andere technici zullen uw code lezen en u zult deze opnieuw lezen het in een jaar tijd. De code moet zo gemakkelijk mogelijk te begrijpen zijn. Alle hierboven genoemde items hebben voornamelijk betrekking op leesbaarheid en het minimaliseren van onverwachte elementen in de code. Uw lezers zouden zich zorgen moeten maken over de logica van uw code, niet proberen uit te vinden waarom een niet-standaard constructie is gebruikt. Als er een niet-standaard constructie is, moeten uw lezers weten dat deze er niet voor niets is, niet omdat je een fout hebt gemaakt. (Beschouw uw code als een meubelstuk. Het oppervlak moet glad zijn en u mag geen splinter opvangen als u er met uw hand overheen gaat. Elke onregelmatigheid zou er met een reden moeten zijn.)
De leesbaarheid wordt ook verbeterd door verstandige methoden en variabelenamen, en door gepaste commentaren. Ga niet te ver met commentaar. Als het duidelijk is, leg het dan niet uit. Maar heb wel een soort overzicht zodat de lezer de context kent. (Het mag duidelijk zijn dat de code invoer X omzet in uitvoer Y, maar het helpt als de lezer enig idee heeft waarom dit nodig is.)
Antwoord
Managers zijn zoiets als peuters. Ze willen wat ze willen en ze willen het NU ! Maar in tegenstelling tot peuters hebben managers zich Harvard Business Review -artikelen half onthouden die ze citeren (zonder referenties op te geven) om hun eisen te rechtvaardigen. Ze hebben een reeks argumenten geleerd die sommige ontwikkelaars lastig vallen.
Ze zeggen: “We kunnen het ons niet veroorloven om het goed te doen. We moeten het op de markt krijgen NU ! ”. Het is niet waar, weet je. Als ze hun spaghetticode haastig in productie nemen, krijgen ze nu de kans om hun lanceringsklanten kwaad te maken, maar de code kan niet opschalen. Het betekent gewoon dat hun bedrijf een tijdje voortschrijdt voordat ze instorten.
Ze zeggen: “We brengen een bèta uit voor onze lanceringsklanten.” Wat ze bedoelen is dat ze willen dat je sneller perfecte, klantvriendelijke code vrijgeeft dan je anders zou doen, alleen omdat ze ermee instemden het een bètatestprogramma te noemen. Het is magisch denken, zoals geloven in de kerstman.
Ze zeggen: “Ik beloof dat we de code later herschrijven als je je waardeloze, halfafgemaakte code vrijgeeft NU ! ” Klinkt dit niet als “Ik maak mijn kamer later wel schoon, vader, als ik tv kan kijken en suikerachtige snacks kan eten NU ?” Het probleem is dat later nooit komt. Elke dag heeft de manager de keuze om nieuwe functies toe te voegen of om de rommelige kamer op te ruimen die hun codebasis vormt. Raad eens waaraan ze prioriteit geven. En raad eens, de kamer wordt rommeliger en rommeliger, zodat het steeds langer zal duren om op te ruimen. Het is ook moeilijker om in te werken (om nieuwe functies te creëren) vanwege alle rommel.
Uiteindelijk zeggen ze: “We hebben te veel geïnvesteerd in deze codebasis. Het herschrijven duurt te lang. We hebben functies NU nodig! ” Alleen elke functie duurt twee of drie keer zo lang om te coderen, vanwege de rommelige kamer die softwareontwikkelaars technische schuld noemen.
Goede ontwikkelaars, zoals geduldige en liefhebbende ouders, moeten de waanzin stoppen. Ze moeten krachtig aandringen: “Sorry schat, maar uw HBR -artikel zegt: Eerdere inkomsten zijn beter, alle andere dingen zijn gelijk . ”U moet het aandachtiger lezen.Alle andere dingen zijn niet gelijk als je technische schulden opstapelt. En als we prioriteit geven aan functies, en misschien is er iets dat je eerder kunt verkopen. “
Je moet de volwassene zijn en hen vertellen dat er niet zoiets als de kerstman bestaat, en nee zoiets als perfecte, klantvriendelijke code totdat alle bugs zijn verwijderd en alle functies zijn geïmplementeerd.
Je moet ze vertellen: “We kunnen het ons niet veroorloven niet om goede praktijken te gebruiken. We leven of we sterven, maar we moeten bepaalde dingen doen om te leven, zoals het schrijven van tests en documentatie. Het is geen optie. “
Je moet glimlachen en zeggen:” We zullen deze code nooit herschrijven. Ik weet dat je het goed bedoelt, maar als het erom gaat de code te repareren of nieuwe functies toe te voegen, weet ik wat je gaat zeggen. Dat is wat u altijd zegt. “
Door een stevige ouder te zijn, helpt u uw manager op te groeien tot het soort bedrijfsleider dat u zou willen werken.