Hvordan man er en produktiv og glad fyr (eller team).

Efter 13 års udvikling ved jeg nøjagtigt, hvad der gør softwareudvikling til en produktiv, effektiv og glad aktivitet. Og det er: at holde antallet af fejl, regressioner og forvirring så lavt som muligt, tæt på nul for at være præcis.

Jeg tror, ​​jeg personligt har opnået det. Jeg brugte cirka 80% af min tid på at rette bugs, blive forvirret og deprimeret. Hver gang jeg skriver kode, fungerer det som næsten øjeblikkeligt. Jeg er også i stand til at skrive store projekter alene. Naturligvis spiller min store oplevelse en stor rolle, men der er noget, der hjælper mig sandsynligvis endnu mere end min oplevelse. En metode, som jeg har brugt et par år på at gennemgå. Jeg vil dele det med dig, og jeg vil også dele med dig VSCode-udvidelsen, der understøtter denne metode.

Som mange mennesker plejede jeg at kode i JS, og det var fint. Indtil jeg begyndte at arbejde på større og større projekter, og en dag nåede jeg det punkt, hvor jeg ikke længere ville løse alle de fejl, der skyldes systemet med svag type. Det var tidspunktet, da jeg skiftede til TypeScript. Og det var jeg utrolig glad for. TypeScript forhindrede fortsat så mange fjollede fejl, at jeg var i stand til at skrive endnu større projekter. Jeg tænkte, at fra det tidspunkt kunne jeg skrive projekter af enhver størrelse, fordi du ved, hver gang jeg glemte noget ville TypeScript venligt minde mig om det.

Så jeg begyndte at skrive mit mest komplekse projekt til tiden alene. Alt var cool, TypeScript mindede mig om alle de typer, jeg havde. Men snart begyndte jeg at føle noget angst og hovedpine. Den følelse kendte jeg mig fra de tidspunkter, hvor jeg prøvede at forstå nogle spaghetti JS-koder.

Men vent, det var min kode, og den blev skrevet på et typisk sprog, så hvorfor følte mit hoved så dårligt? Det er svært at tro, men det viste sig, at midt i projektet begyndte jeg at glemme ting som: hvad handlede projektet om, hvorfor skrev jeg det overhovedet, hvad var dets formål, og hvad gjorde koden, jeg allerede havde skrevet gør på højt niveau.

Disse problemer var chokerende for mig, men jeg havde fundet en enkel og intuitiv løsning på dem - dokumentation. Meget af det. Og det hjalp. Indtil det tidspunkt, hvor dokumentationen begyndte at rådne. Det var en katastrofe. En dokumentation, der begynder at rådne, gør meget mere skade end overhovedet ingen dokumentation. Det forvirrer, det vildleder, og det multiplicerer fejl.

Jeg har skrevet kun et par stykker, men jeg skriver om ganske lange og elendige perioder i mit liv. Jeg mistede tilliden og tilliden til, at jeg er i stand til at skrive noget markant alene, selvom jeg havde alle disse års erfaring. I denne depression begyndte jeg at tænke, hvad der kunne gøres. Er det endda muligt at skrive dokumentation på en sådan måde, at den ikke roter?

De næste par måneder var jeg kommet med tusinder af ideer, jeg tænkte dem igennem, filtrerede, testede dem. I sidste ende er alt dette krystalliseret i HyperComments

Jeg har ikke sovet i aften, fordi jeg endelig ønskede at rette de mest kritiske fejl, så denne artikel kan være lidt rå, kaotisk og lav. Det er også grunden til, at jeg kun vil vise et eksempel på brug, men du kan følge linket (nedenfor) og se meget mere.

“Plan” -teknikken

Når du har en meget kompleks opgave, det er svært at planlægge helt i dit hoved, så skriv den ud som en plan:

/ * # Opgave 1 # # Opgave 2 # # Opgave 3 #… * /

Når du skriver denne plan, vil du naturligvis opdele opgaven i mindre, og du får et mere og mere detaljeret billede af, hvordan hele systemet skal fungere.

Når du omsider har opdelt den store opgave i mindre, og du er overbevist om, at der ikke er nogen eller lidt uklarhed tilbage, kan du begynde at udføre den første opgave (Opgave 1). Start det med denne kommentar:

@ Opgave 1 @

Hvad der lige er sket er, at din plan nu er forbundet med kodeimplementeringen. Hvis du nu ønsker at få det store billede, kan du se på planen, og når du vil gå ned i detaljerne, kan du søge `@ Opgave 1 @` ved hjælp af din kodeditor. Hvis du bruger VSCode, kan HyperComments dog hjælpe meget: bare klik på et planelement, så navigeres du automatisk til implementeringskoden. Udvidelsen gør mere end det! Det vil også understrege med røde farver de planelementer, der ikke har tilsvarende implementeringskoder (ankre). Så du ikke glemmer at implementere nogen af ​​trinnene!

Igen, det er kun en teknik af mange, jeg vil fortsætte med at skrive om dette emne, men jeg har virkelig brug for din feedback! Understøtt mig ved at lide denne artikel, prøve udvidelsen, arkivere fejlrapporter, hvilket som helst af disse vil blive værdsat meget.

Jeg håber, at dette vil hjælpe nogen!