Af Jerrie Agunya & Geoffrey Matieso
Skift den vildfarelse, at du skal kunne C++, java dette framework, det framework osv., for at du kan lykkes med at have den bedste kodningspraksis. Du skal lære at lære, hvordan du ikke skal give op. Normalt bliver det omkring begyndelsen af rejsen for at opnå den bedste kodningspraksis rigtig svært, og det er et faktum.
Det faktum, at kode ligner bare en kode for en person, der ikke ved, hvordan man koder, er sandt, men nogle ting skiller sig ud, når man bedømmer en programmørs færdigheder. Så hvordan kan du identificere en god programmør med de bedste kodefærdigheder? Vi vil diskutere og sammenholde nogle få under følgende underoverskrift.
Kodekvalitet
Ingeniør og forfatter Martin Fowler sagde:
“Enhver tåbe kan skrive kode, som en computer kan forstå, gode programmører skriver kode, som mennesker forstår”
En god programmør bruger tid på at dokumentere sine koder, chancerne er, at han måske ikke forstår sin kode, når han ser på den igen om et par måneder. De holder deres holdkammerater tilfredse med deres kode og ikke i fortvivlelse, det er dårlig praksis at kværne kode ud, der er skrevet med fremtidig vedligeholdbarhed i tankerne. Hermed menes, at koden ikke er skrevet med henblik på vækst i kodebasen, og hvis en opdatering eller en ny funktion skal implementeres, bliver den rodet, fejlfyldt og går i stykker.
Kvalitet af kode er vigtig for skalerbarhed, kode skal være struktureret korrekt, pæn, veldokumenteret og med korrekt formatering, bygget til at være testdrevet for at undgå sårbarheder.
Snav og rodet kode er hurtig, ja! Men tænk bare på, hvor mange timer der ville gå med at fejlfinde den kode i fremtiden.
Forudsætninger.
Hvor kodningen starter, skal alle nødvendige forudsætninger være gennemført for at skabe et solidt fundament for kodning. Disse omfatter livscyklus, arkitektur, design og valg af programmeringssprog. Softwareudviklingsmetodologi hjælper med at strukturere, planlægge og kontrollere et projekts livscyklus. Softwarearkitekturen bestemmer, hvad der skal gøres, og hvilken programkomponent der skal gøre det. Den definerer effektivt grænsefladen mellem forskellige programmer, når softwaresystemet indeholder mange programmer.
Arkitekturen giver også andre interessenter mulighed for at kontrollere projektets krav. Softwareudviklingsdesignet bør være detaljeret nok til at give en god vejledning for den faktiske kodning. Det giver mulighed for at udfylde de detaljer, der er blevet overset i det arkitektoniske design. Forskellige programmeringssprog er egnede til forskellige aspekter af problemet. Programmøren bør være opmærksom på de specifikke styrker og svagheder ved det anvendte sprog. Problemet og de tilhørende programmeringskrav skal forstås for at kunne vælge det bedste sprog. Det bedste sprog vælges på grundlag af listen over krav.
Hold koden enkel.
Kodegruppering gør det muligt at anvende få kodelinjer med opgaver, der holdes inden for separate blokke af kode. Kompliceret logik for at opnå en simpel ting bør holdes på et minimum, da koden kan blive ændret af en anden programmør i fremtiden. En mindre forenkling af koden forbedrer produktiviteten, reducerer rulningsbevægelser og anstrenger øjnene. Tilføjelse af en kommentar i begyndelsen af hver kodeblok understreger også den visuelle adskillelse.
Programmører bør bruge et konsistent navngivningsskema og indrykning afhængigt af projektet. Navnene bør have ordgrænser, dvs. camelCase eller understregninger. DRY-princippet (Don’t Repeat Yourself) bør opretholdes i al kode, da de fleste programmer automatiserer gentagende opgaver. Programmøren bør også undgå dyb indlejring og begrænse linjelængden. Hvis koden holdes enkel, forbedres læsbarheden.
Portabilitet.
Programmører bør parametrisere variabler og konfigurere dem til værtsmiljøet uden for programmet. Dette kan omfatte en applikationsserver eller en database. Programkode bør ikke indeholde bogstavelige værdier, der henviser til miljøparametre som f.eks. absolutte filstier, filnavne, brugernavne, værtsnavne og IP-adresser. Dette vil ikke gøre det muligt for programmet at køre på en vært, der har et andet design.
Genanvendelighed.
Mange softwareprojekter starter med en eksisterende baseline, der indeholder projektet i dets tidligere version. Afhængigt af projektet genbruges mange af de eksisterende softwaremoduler og komponenter. Dette er med til at reducere udviklingsomkostningerne og -tiden, hvis komponenterne allerede er testet. Derfor øges sandsynligheden for at levere et softwareprojekt til tiden.
Debugging af koden og korrektion af fejl.
Programmører bør skrive den komplette kode og derefter begynde at debugge og kontrollere for fejl og ikke hele programmet. Denne fremgangsmåde sparer tid, da man ikke ender med at spilde tid på at finde fejl.
Testning.
Hvor kodningen begynder, planlægges og udvikles testcases, mens programmet designes og kodes. Enhedstests for de enkelte moduler og funktionelle tests for webtjenester og applikationer anvendes sammen med debugging.
Sammenfattende vil den bedste kodningspraksis gøre det muligt for dig som udvikler at se, hvilken værdi du kan tilføre. Især hvad du kan gøre, som andre ikke kan; ikke “at være lige så klog som de andre udviklere”, men at være unik og bringe den indre tekniker frem i dig selv.