Oversætterens forord: Efter at have læst denne artikel, kan du blive overrasket eller endda vred. Ja, vi var også overraskede: Forfatteren havde angiveligt aldrig hørt om hierarkiet i teamet, om at sætte opgaver med status "gør det hurtigt og uden begrundelse." Ja, det er rigtigt, det er en lidt mærkelig tekst. Forfatteren foreslår faktisk, at programmøren påtager sig rollen som systemarkitekt - hvorfor har du så brug for en arkitekt? Men alle disse indvendinger bør ikke gøre dig blind for det vigtigste - hvorfor vi alligevel tog og oversatte denne tekst. Han taler ikke om roller. Denne tekst handler om en professionel tilgang og bevidsthed. Sandheden er, at så længe du bare "gør, hvad du får besked på" uden at tænke på meningen med dine handlinger, vil du aldrig blive en god programmør.
Sig nej til unødvendig kode. Alt du skal gøre er at sætte tre bogstaver sammen og sige ordet. Lad os prøve at gøre dette sammen: "Nej!
Men vent. Hvorfor gør vi dette? En programmørs hovedopgave er trods alt at skrive kode. Men skal du skrive en kode, du bliver bedt om? Ingen! "At forstå, hvornår man ikke skal skrive kode, er nok den vigtigste færdighed for en programmør." .
Påmindelse: for alle læsere af "Habr" - en rabat på 10 rubler ved tilmelding til ethvert Skillbox-kursus ved hjælp af "Habr"-kampagnekoden.
Skillbox anbefaler: Praktisk kursus .
Programmering er kunsten at løse problemer. Og du er mestre i denne kunst.
Nogle gange, i et forsøg på at komme i gang med arbejdet så hurtigt som muligt, tænker vi ikke på andet end at færdiggøre opgaven. Og dette kan give endnu mere alvorlige problemer.
Hvad lukker programmører det blinde øje til?
Al kode du skriver skal være forståelig for andre udviklere og skal testes og fejlfindes.
Men der er et problem: Uanset hvad du skriver, vil det komplicere din software og sandsynligvis introducere fejl i fremtiden.
Ifølge Rich Skrent, . Her er hvad han skriver:
“Koden er dårlig, fordi den begynder at rådne og kræver konstant vedligeholdelse. Tilføjelse af nye funktioner kræver ofte ændring af gammel kode. Jo større den er, jo større er sandsynligheden for, at der opstår en fejl, og jo længere tid tager det at kompilere. Det tager en anden udvikler mere tid at finde ud af. Og hvis der er behov for refactoring, så vil der helt sikkert være fragmenter, der er værd at ændre. Stor kode betyder ofte reduceret fleksibilitet og funktionalitet af projektet. En enkel og elegant løsning er hurtigere end kompleks kode."
Hvordan ved du, hvornår du ikke skal skrive kode?
Problemet er, at programmører ofte overdriver antallet af funktioner, som deres applikation har brug for. Som et resultat forbliver mange sektioner af kode ufærdige, eller ingen bruger dem, men de komplicerer applikationen.
Du skal klart forstå, hvad dit projekt har brug for, og hvad det ikke gør.
Et eksempel er en applikation, der kun løser én opgave - håndtering af e-mail. Til dette formål er der indført to funktioner - at sende og modtage breve. Du skal ikke forvente, at mailmanageren bliver en task manager på samme tid.
Du skal bestemt sige "nej" til forslag om at tilføje funktioner, der ikke er relateret til applikationens hovedopgave. Dette er præcis det øjeblik, hvor det bliver klart, at der ikke er behov for yderligere kode.
Mist aldrig fokus på din ansøgning.
Spørg altid dig selv:
— Hvilken funktion skal implementeres nu?
— Hvilken kode skal jeg skrive?
Sæt spørgsmålstegn ved de ideer, der kommer til at tænke på, og vurder forslag, der kommer udefra. Ellers kan ekstra kode simpelthen dræbe projektet.
At vide, hvornår du ikke skal tilføje unødvendige ting, vil hjælpe dig med at holde din kodebase under fast kontrol.
I begyndelsen af stien har programmøren kun to eller tre kildefiler. Det er simpelt. Kompilering og lancering af applikationen kræver et minimum af tid; Det er altid klart, hvor og hvad man skal kigge efter.
Efterhånden som applikationen udvides, vises flere og flere kodefiler. De fylder kataloget, hver med hundredvis af linjer. For at organisere alt dette korrekt, bliver du nødt til at oprette yderligere mapper. Samtidig bliver det stadig sværere at huske, hvilke funktioner der er ansvarlige for hvad og hvilke handlinger der forårsager dem; Det tager også længere tid at fange fejl. Projektledelse bliver også mere kompleks; ikke én, men flere udviklere skal holde styr på alt. Derfor stiger omkostningerne, både penge og tid, og udviklingsprocessen bremses.
Projektet bliver til sidst enormt, og det kræver mere og mere indsats at tilføje hver ny funktion. Selv for noget meget ubetydeligt skal du bruge flere timer. Korrigering af eksisterende fejl fører til fremkomsten af nye, og ansøgningsfrister overskrides.
Nu skal vi kæmpe for projektets levetid. Hvorfor?
Faktum er, at du simpelthen ikke forstod, hvornår du ikke skulle tilføje ekstra kode, og svarede "ja" til alle forslag og idéer. Du var blind, ønsket om at skabe nye ting fik dig til at ignorere vigtige fakta.
Det lyder som et gyserfilmmanuskript, ikke?
Det er præcis, hvad der vil ske, hvis du bliver ved med at sige ja. Prøv at forstå, hvornår kode ikke skal tilføjes. Fjern unødvendige ting fra projektet - det vil gøre dit liv meget lettere og forlænge applikationens levetid.
"En af mine mest produktive dage var, da jeg slettede 1000 linjer kode."
- Ken Thompson.
Det er svært at lære, hvornår man ikke skal skrive kode. Men det er nødvendigt.
Ja, jeg ved, at du lige er gået ind på en udviklers vej og gerne vil skrive kode. Det er godt, mist ikke det første indtryk, men tab ikke vigtige faktorer af syne på grund af entusiasme. Vi indså alt gennem forsøg og fejl. Du vil også begå fejl og lære af dem. Men hvis du kan lære af ovenstående, bliver dit arbejde mere bevidst.
Fortsæt med at skabe, men ved, hvornår du skal sige nej.
Skillbox anbefaler:
- Anvendt online kursus .
- Online kursus .
- Praktisk årskursus .
Kilde: www.habr.com