Dåliga vanor är svåra att bryta och ännu svårare om du inte inser att det du gör underminerar ditt arbete. Om du vet men inte bryr dig – det skulle vara det värsta. Men du är ju här, eller hur?
Som programmerare har jag sett många dåliga vanor, inte bara när det gäller kod, utan också när det gäller färdigheter i lagarbete. Jag har själv gjort mig skyldig till att praktisera många av dessa dåliga vanor. Här är mina 35 främsta dåliga programmeringsvanor, indelade i fyra kategorier: kodorganisation, lagarbete, kodskrivning samt testning och underhåll.
Kodorganisation
1. Att säga: ”Jag fixar det senare”
Vanananan att skjuta upp kodfixar är inte bara ett problem med prioriteringar. Att organisera din problembokföring kan generera vissa framsteg, men du måste också ha ett sätt att spåra mindre problem som dyker upp. Att lägga till ”TODO”-kommentarer är ett snabbt sätt att se till att du inte missar något.
2. Att insistera på en enlinjig lösning
Att vara besatt av att skriva effektiva, eleganta kodstycken är ett vanligt drag hos programmerare. Det är som att lösa ett pussel – du hittar en kombination av funktioner och reguljära uttryck som förvandlar 20 kodrader till 2 eller 3. Tyvärr resulterar det inte alltid i läsbar kod, och det är i allmänhet det mycket viktigare resultatet. Gör din kod tillgänglig först, sedan smart.
3. Gör meningslösa optimeringar
Ett annat ställe där vi ofta missbrukar våra ansträngningar är optimeringar. Det låter bra att minska storleken på din webbplats med några bytes, men kommer inte gzip att kompensera för det ändå? Och är inte förfrågningar viktigare? Ta itu med optimeringar i slutet av ett projekt, för oftast kommer kraven att ändras och din tid kommer att ha varit bortkastad.
”För tidig optimering är roten till allt ont.”
-Donald Knuth
4. Övertyga dig själv om att stilfrågor inte är så viktiga
Om jag har lärt mig något genom att i åratal titta på andras kod så är det att hantera kodningsstilsproblem är det som utvecklare är mest benägna att skjuta upp. Kanske är det svårt för oerfarna kodare att se vad som kommer att bli bra av att ta itu med stilfrågor, men med tiden kommer det att bli uppenbart att när kodkvaliteten väl spårar ur kommer en snöbollseffekt att förvandla vilket projekt som helst till en fullständig röra. Var strikt när det gäller bästa praxis även om de verkar försumbara. Sätt upp verktyg för kodkontroll och linting för att ge dig själv utrymme att oroa dig för de viktigare sakerna.
5. Sopa saker under mattan
Det finns många sätt att sopa saker under mattan, antingen genom att fånga och ignorera undantag eller genom att använda bibliotek som inte rapporterar fel (t.ex. jQuery). Men när ett av dessa fel blir en prioritet blir utmaningen att åtgärda det många gånger större, med tanke på att du inte har en aning om var du ska börja. Ett enkelt sätt att undvika detta är att logga dessa ignorerade fel så att du kan studera dem senare.
6. Använd namn som inte tillför information
Namngivning är svårt, men det finns ett enkelt sätt att se till att dina variabel- och funktionsnamn åtminstone är av hyfsad kvalitet. Så länge namnen lägger till någon form av information som resten av koden inte förmedlar kommer andra utvecklare att ha lättare att läsa din kod. Anledningen till att namngivningen är så viktig är att namnen kan ge en allmän uppfattning om vad koden gör. Det tar mer tid om du måste gräva i beräkningarna för att ta reda på vad en kodbit gör, men ett bra namn kan hjälpa dig att förstå vad koden gör på några sekunder.
7. Ignorera beprövade bästa metoder
Kodgranskningar, testdriven utveckling, kvalitetssäkring, automatisering av driftsättning – dessa metoder, och flera andra, har bevisat sitt värde i oräkneliga projekt, vilket är anledningen till att utvecklare ständigt bloggar om dem. En bra referens för dessa bästa metoder är boken Making Software: What Really Works, and Why We Believe It. Ta dig tid att lära dig att göra dem på rätt sätt och din utvecklingsprocess kommer att förbättras i alla dina projekt på ett sätt som kommer att överraska dig.
Lagarbete
8. Överge planer för tidigt
Ett säkert sätt att göra ditt system outgrundligt är att inte binda sig till en plan. Du kan alltid säga, när din kod kritiseras, att planen inte är fullständig. Att ha halvfärdiga moduler kommer dock att leda till tätt kopplad kod så snart du försöker få dessa ofärdiga moduler att fungera med varandra. Den här typen av komplikationer uppstår också när ledarrollerna i ett projekt ändras och de nya ledarna bestämmer sig för att det är viktigare att ha det på sitt sätt än arkitektonisk konsistens.
9. Att insistera på en plan som har liten chans att fungera
Samma som att överge sina planer kan orsaka problem, kan det också leda till problem att hålla fast vid en plan som inte fungerar. Det är därför du bör dela dina idéer med ditt team för att få feedback och råd när det blir knepigt. Ibland kan ett annat perspektiv göra hela skillnaden.
10. Arbetar på egen hand hela tiden
Du bör sträva efter att dela dina framsteg och idéer med teamet. Ibland tror du att du bygger något på rätt sätt, men det gör du inte, så ständig kommunikation är mycket värdefull. Det är också fördelaktigt för andra människor när du arbetar tillsammans med dem. Deras arbete förbättras ofta när du diskuterar idéer med dem och fungerar som mentor för de mindre erfarna medlemmarna i teamet, som är mer benägna att fastna.
11. Vägra skriva dålig kod
Det kommer en tid i varje utvecklares liv då deadlines tvingar dig att skriva hemsk kod, och det är okej. Du har försökt varna din kund eller chef om konsekvenserna, men de insisterar på att hålla sig till tidsfristen, så nu är det dags att koda. Eller kanske finns det ett brådskande fel som inte kan vänta på att du ska komma med en ren lösning. Därför är det viktigt att vara mångsidig som programmerare och att kunna skriva dålig kod mycket snabbt såväl som bra kod. Förhoppningsvis kan du se över koden igen och betala tillbaka den tekniska skulden.
12. Skylla på andra
Det är ingen hemlighet att arrogans är ett alltför vanligt drag bland utvecklare och andra tekniska yrkesgrupper. Att ta ansvar för dina misstag är en dygd som får dig att glänsa bland dina kollegor. Var inte rädd för att erkänna att du har gjort ett misstag. När du väl är okej med det kan du fokusera på att lära dig varför du gjorde det misstaget och hur du kan undvika det. Om du inte erkänner det blir lärandet omöjligt.
13. Delar inte med ditt team vad du har lärt dig
Ditt värde som utvecklare är inte bara placerat på den kod du skriver, utan också på vad du lär dig när du skriver den. Dela med dig av dina erfarenheter, skriv kommentarer om det, låt andra veta varför saker och ting är som de är och hjälp dem att lära sig nya saker om projektet och dess förvecklingar.
14. Att vara för långsam med att ge feedback till chefer/klienter
En av de mest värdefulla karaktärsdragen hos en hantverkare ligger i att se till att alla är på samma sida om arbetet, så mycket som möjligt. Anledningen till detta är inte för att din chef ska kunna fylla kalkylblad. Det är också för din egen skull: Du kommer att ha mindre osäkerhet och minska osäkerheten om projektets livslängd och framtid.
15. Du använder inte Google tillräckligt mycket
Det bästa sättet att snabbt lösa ett komplext problem är att inte behöva lösa det alls. När du är osäker, googla det. Naturligtvis kan du störa ingenjören bredvid dig i stället, men han kommer sällan att kunna ge ett så detaljerat svar som Stack Overflow, för att inte tala om att du också avbryter hans arbete.
16. Övervärdera din personliga stil
Syft alltid till att samordna din arbetsstil och miljöuppsättning med ditt team. Helst ska alla i ditt team arbeta under liknande förhållanden och följa samma kodningsstil. Att göra saker på ditt sätt kan vara roligare, men arbetskamraterna kanske inte är vana vid din kodningsstil, och om den är ovanlig blir det svårare för nästa utvecklare att arbeta med det du har byggt.
17. Att ha en personlig anknytning till din kod
När någon kommenterar din kod ska du inte ta det personligt. Din kod ska stå på fast grund, det vill säga du ska kunna förklara varför du skrev den på det sättet. Om den behöver förbättras är det bara en återspegling av kodens korrekthet, inte av dig själv.
Skriva kod
18. Att inte veta hur man optimerar
En bra optimeringsstrategi kräver en del erfarenhet för att bli rätt. Det krävs utforskning, analys och att man känner till varje system som är involverat i en process. Informera dig om dessa saker. Lär dig om algoritmisk komplexitet, utvärdering av databasförfrågningar, protokoll och hur man mäter prestanda i allmänhet.
19. Att använda fel verktyg för uppgiften
Du kan bara veta så mycket, men anledningen till att du måste fortsätta att lära dig är att varje nytt problem ger ett annat sammanhang och kräver ett annat verktyg – ett som är mer tillämpbart för uppgiften. Var öppen för nya bibliotek och språk. Ta inte beslut som strikt baseras på vad du vet.
20. Bry dig inte om att behärska dina verktyg och IDE
Varje ny snabbtangent, genväg eller parameter som du lär dig när du använder de verktyg som du arbetar med varje dag kommer att ha en mer positiv effekt på din kodningshastighet än du tror. Det handlar inte om att spara några sekunder genom att använda en snabbknapp, utan om att minska kontextbytet. Ju mer tid du lägger ner på varje liten åtgärd, desto mindre tid har du till förfogande för att tänka på varför du gör det och på vad som kommer härnäst. Om du behärskar genvägar kan du frigöra ditt sinne.
21. Ignorera felmeddelanden
Anta inte att du vet vad som är fel med din kod utan att ens läsa ett felmeddelande, eller att du kommer att lista ut det tillräckligt snabbt. Att ha mer information om ett problem är alltid bättre, och om du tar dig tid att samla in den informationen sparar du mer tid i det långa loppet.
22. Att romantisera din utvecklarverktygslåda
Ibland är din föredragna editor eller kommandoradsverktyg inte det bästa verktyget för det aktuella jobbet. Visual Studio är bra för att skriva IDE, Sublime är bra för dynamiska språk, Eclipse är bra för Java och så vidare. Du kanske älskar vim eller emacs, men det betyder inte att det är det rätta verktyget för varje uppgift.
23. Hårt kodade värden i stället för att göra dem konfigurerbara
Tänk alltid på vilka förändringar som kan komma och hur du ska hantera dem. Den tekniska skulden kommer att växa i en monstruös takt om du inte separerar de rörliga delarna från resten av ditt arbete. Använd konstanter och konfigurationsfiler när det är lämpligt.
24. Uppfinna hjulet på nytt hela tiden
Skriv inte kod som du inte behöver. Kanske har någon annan redan ägnat en hel del tid åt ditt problem, och han eller hon kanske har en väl beprövad lösning som du kan återanvända. Spara dig själv lite problem.
25. Blint kopiera/klistra in kod
Förstå kod innan du återanvänder den. Ibland märker man inte omedelbart allt som koden gör vid första anblicken. Du lär dig också mer om ett problem när du tar dig tid att läsa koden i detalj.
26. Att inte ta sig tid att lära sig hur saker och ting verkligen fungerar
Anta alltid möjligheten att utöka dina kunskaper genom att tänka på hur saker och ting fungerar och läsa om deras underliggande problem. Du kanske sparar tid genom att inte bry dig just nu, men vad du lär dig i ett projekt kommer att vara viktigare på lång sikt än att faktiskt få det gjort.
27. Att ha överdrivet förtroende för din egen kod
Det är farligt att anta att bara för att du har skrivit något måste det vara bra. Du lär dig mer om programmering när du arbetar med nya saker och får erfarenhet, så ta en titt på din gamla kod då och då och reflektera över hur du har gjort framsteg.
28. Att inte tänka på kompromisserna med varje design, lösning eller bibliotek
Alla produkter har sina finesser som du bara lär dig om genom att använda och analysera dem. Att se några användningsexempel för ett bibliotek gör dig inte till en mästare på det, och det betyder inte heller att det passar perfekt för varje situation som kommer att uppstå i ditt projekt. Var ständigt kritisk till allt du använder.
29. Att inte få hjälp när du har kört fast
Att hålla en kort återkopplingsslinga kommer alltid att vara mindre smärtsamt för dig. Att be om hjälp betyder inte att du är inkompetent. Rätt personer kommer att se din ansträngning och ditt erkännande av okunskap som en drivkraft att lära sig, och det är en stor dygd att ha.
Testning och underhåll
30. Att skriva tester för att klara sig
Att skriva tester som du vet kommer att klara sig är nödvändigt. De gör det mycket säkrare att refaktorisera och omorganisera ett projekt. Å andra sidan måste du också skriva tester som du vet inte kommer att klara sig. De är nödvändiga för att föra projektet framåt och hålla reda på problem.
31. Att bortse från prestandatestning i kritiska fall
Förbered en automatisk prestandatestning ungefär i mitten av projektets utvecklingsprocess så att du kan försäkra dig om att du inte har eskalerande prestandaproblem.
32. Kontrollerar inte att din build fungerar
Det är sällsynt att en build godkänns men inte riktigt fungerar, men det kan hända, och det kan bli besvärligt att åtgärda problemet ju längre du väntar med att undersöka det. Att snabbt testa varje build är en viktig vana att ha.
33. Att driva stora ändringar sent, eller att lämna efter att ha gjort en stor push
Det är här överdrivet självförtroende kommer att få dig, och det kan krävas att du blir bränd flera gånger för att lära dig varför du inte ska göra det här, så ta mitt råd nu och se till att du alltid finns där när din build så småningom går sönder.
34. Att avfärda kod som du har skrivit
Var villig att stödja kod som du har skrivit. Du är den mest lämpade personen för att hjälpa andra att förstå den. Du bör sträva efter att din kod ska förbli läsbar för dig själv och andra många år framöver.
35. Ignorera de icke-funktionella kraven
När du försöker leverera något kan det vara lätt att glömma bort vissa viktiga områden som prestanda och säkerhet. Håll en checklista för dessa. Du vill inte att de ska förstöra din fest för att du drog upp dina deadlines utan att tänka på dessa icke-funktionella bekymmer.
Vilka är dina värsta programmeringsvanor?
Som det ofta sägs är vi vanemänniskor. Att förbättra ditt arbetssätt genom vanor är ett utmärkt sätt att undvika att behöva tänka för mycket på varje enskild situation. När du väl har tillgodogjort dig ett bra sätt att göra något blir det enkelt.