De underligste programmeringsprincipper, du aldrig har hørt om

Reklame

Vi har allerede ledt dig gennem mest vigtige programmeringsprincipper 10 grundlæggende programmeringsprincipper Hver programmerer skal følgeSkriv altid kode, der kan vedligeholdes af alle, der kan ende med at arbejde på din software. Med henblik herpå er her flere programmeringsprincipper, der hjælper dig med at rydde op i din handling. Læs mere du har brug for at vide om, men der er en anden klasse programmeringsprincipper, der kan bevise endnu mere fordelagtigt end dem.

Mens ovennævnte principper lærer dig, hvordan du skal være det smart med din kode vil de følgende principper lære dig at være klog med din kode. Nogle af dem er underlige, og mange af dem er humoristiske, men de er alle lige så praktiske og vigtige. Pas på!

1. Oppustningsprincippet

Denne har så mange variationer, at det er svært at vælge en som den vigtigste. Den mest "officielle" version er måske loven om softwarekonvolutter, der ofte kaldes Zawinskis lov, opkaldt efter Jamie Zawinski og nævnt i Kunsten at UNIX-programmering:

”Hvert program forsøger at udvide, indtil det kan læse mail. De programmer, der ikke kan udvides så erstattes af dem, der kan. ”

Det taler om programmernes tendens til at tiltrække flere og flere funktioner over tid og uundgåeligt køre mod stigende kompleksitet. Du ved muligvis dette som funktion kryb, som er den løbende tilføjelse af nye funktioner, der ikke har noget at gøre med programmets hovedformål. Funktionskryp fører til oppustethed, og oppustethed er ofte uønsket.

Dette kan også gælde for softwarepræstation:

"Software udvides til at forbruge alle tilgængelige ressourcer."

Tilbage i 90'erne var harddiske og CPU'er og RAM langt mere restriktive end de er i dag, og programmerere arbejdede hårdt for at passe så meget de kunne inden for grænserne. Men nu, hvor vi har større drev og hurtigere CPU'er og mere RAM, kæmper vi stadig for at respektere grænser. Alt bliver oppustet med tiden. Det er dit job at holde det i skak.

2. Den "værre er bedre" mentalitet

Næsten som om vi har svar på oppustningsprincippet Værre er bedre mentalitet, først opfundet af Richard P. Gabriel skrev i et essay, han skrev om softwarekvalitet:

"Software, der er begrænset, men enkel at bruge, kan være mere tiltalende for brugeren og markedet end det omvendte."

Med andre ord er det klogt at finde ud af et problem din software sigter mod at løse og derefter være meget godt ved den ene ting. Hold det simpelt. Jo mere du spreder dig tynd, desto mere uhåndterligt bliver projektet, og jo mere uønsket bliver det for brugerne.

Hvad sker der, når du ignorerer dette? Du ender med Software Peter Principle:

”Et alt for komplekst projekt vil i sidste ende blive for kompliceret til at forstå, selv af dets egne udviklere.”

Det kommer fra det bredere Peter-princip, der siger, at når medarbejderne fremmes baseret på deres nuværende kompetence og ikke deres forventede kompetence på deres næste position, ender alle medarbejdere til sidst i en position inkompetence. Tag dette princip og anvend det på software, så ser du, hvorfor værre software ofte kan være bedre.

3. Eaglesons lov

"En hvilken som helst egen kode, som du ikke har set på i seks eller flere måneder, kunne lige så godt være skrevet af en anden."

Dette tilsyneladende demotiverende ordsprog er faktisk noget at omfavne. Faktum er, at ingen er perfekte. Du tror måske, du er en genial programmør lige nu, men der er altid noget mere du kan lære, altid mere plads til at vokse. Hvis du nogensinde ser tilbage på gammel kode og klirrer, betyder det sandsynligvis har du lært noget nyt siden da.

Sagt på en anden måde: Hvis du ser tilbage på et gammelt projekt, og du ikke kan se noget, du kan forbedre eller ville gøre anderledes næste gang, har du sandsynligvis stagneret som programmerer.

4. Princip for mindst forundring

"Hvis en nødvendig funktion har en stor forbavselsesfaktor, kan det være nødvendigt at redesigne funktionen."

Først offentliggjort i IBM Systems Journal tilbage i 1984 er dette princip stadig overraskende relevant i dag - måske mere end nogensinde før.

Det berører i det væsentlige den delikate balance mellem innovation og fortrolighed: hvis et stykke software er det for anderledes fra andre af sin art og ikke i overensstemmelse med brugerens forventninger de vil sandsynligvis ikke vedtage det. Det er bedre at stræbe efter trinvise forbedringer, der er lige store nok til at være imponerende, men små nok til at forblive fortrolige.

5. Law of Cybernetic Entomology

"Der er altid endnu en fejl."

Ofte kaldet Lubarskys lov om cybernetisk entomologi, det er uklart, hvem denne Lubarsky faktisk er. Imidlertid rækker hans princip for alle programmerere: uanset hvor rent du skriver din kode, uanset hvordan robust du tester dine moduler, uanset hvor ofte du refaktorerer dine klasser, vil der altid være en anden fejl.

På en måde er dette et frigørelsesprincip. Mens vi bestemt skulle stræbe for fejlfri kode er det også vigtigt at huske, at perfektionisme er det gode fjende. Kig efter fejl, rett dem, når de opstår, og gå derefter videre.

6. Kernighans lov

“Fejlsøgning er dobbelt så hård som at skrive koden i første omgang. Derfor, hvis du skriver koden så smart som muligt, er du per definition ikke smart nok til at debugge den. ”

Brian Kernighan, den samme, der var medforfatter C-programmeringssprogsbibelen Hvorfor C-programmering stadig er værd at læreC er ikke et dødt sprog. Faktisk rangerede IEEE Spectrum magasin som det største sprog i 2017. Her er fem grunde. Læs mere , er berømt for denne indsigtsfulde lov. Kernen i det er dette: skriv godt kode, skriv læselig kode, skriv enkel kode, noget så længe det ikke er dygtig kode.

At prøve at flexere dine programmeringsmuskler med elfenbenstårnens kompleksitet er det nøjagtige modsætning til, hvad det betyder for skriv ren og bedre kode 10 tip til skrivning af renere & bedre kodeAt skrive ren kode ser lettere ud, end det faktisk er, men fordelene er det værd. Her er, hvordan du kan begynde at skrive renere kode i dag. Læs mere . Jo sværere din kode er at forstå, desto sværere vil det være at fejlsøge, når den uundgåeligt går i stykker.

Og som Robert C. Martin forklarer, det handler heller ikke kun om fejlsøgning:

”Faktisk er forholdet mellem brug af tid og læsning kontra skrivning godt over 10 til 1. Vi læser konstant gammel kode som en del af indsatsen for at skrive ny kode... [Derfor] gør det let at læse gør det lettere at skrive. ”

7. Debugging af gummiand

Denne er ikke så meget et princip, som det er en teknik, men det er så nyttigt og mærkeligt, at vi bliver overladt til at udelade det.

Først fortalt i Den Pragmatiske Programmer, debugging af gummiand er, når du fejler ødelagt software ved at forklare din kode til et livløst objekt (f.eks. en gummiand) en linje ad gangen. Det fungerer, fordi forklaringshandlingen udløser forskellige dele af din hjerne, og du er mere tilbøjelig til at se uoverensstemmelser og finde ud af, hvor du gik galt.

Af denne grund kan en gummiand være en overraskende flot gave til programmerere De bedste nørdegave til programmerere: 20 ideer til kodere og nørderLeder du efter en gave til en programmør? Her er de bedste nørdegaver, lige fra mekaniske tastaturer til stående skriveborde og mere. Læs mere , uanset om du køber det til dig selv eller til en programmand til dig.

8. Ninety-Reginet

”De første 90 procent af koden tegner sig for de første 90 procent af udviklingstiden. De resterende 10 procent af koden tegner sig for de øvrige 90 procent af udviklingstiden. ”

Dette fræk lille sprog fra Tom Cargill får kerne i hvorfor programmering kan være så frustrerende: uanset hvor tæt du tror, ​​du er ved at være færdig, så er du meget længere væk end end dine bedste skøn. Når du tror, ​​du er færdig, er du kun halvvejs der.

Det går hånd i hånd med Hofstadter's Law:

"Det tager altid længere tid, end du forventer, også når du tager højde for Hofstadter's Law."

9. Parkinsons lov

”Arbejdet udvides for at udfylde den tilgængelige tid til dens færdiggørelse.”

Dette ene princip, opfundet af Cyril Northcote Parkinson, er et bredere princip, der absolut gælder for programmering og går hånd i hånd med Ninety-Ninety-reglen ovenfor: uanset hvor lang tid du har til at afslutte et projekt er nøjagtigt hvor lang tid det vil tage. I softwareudvikling er ”færdigbehandling” temmelig en myte.

Parkinsons lov er grunden til, at korrekte tidsfrister er afgørende, hvis du vil afslutte og sende din software. Derfor anbefaler moderne professionelle programmører ofte agile projektstyringsprincipper Sådan bruges agile projektstyringsprincipper til at organisere dit livAgile, bedst kendt som en projektledelsesmetode, er en god ramme for styring af dit personlige liv. Vi viser dig hvilke principper du kan låne - gratis download af regneark inkluderet! Læs mere og projektstyringsværktøjer som Asana Trello vs. Asana: Det bedste gratis projektstyringsværktøj er ...Det er vanskeligt at vælge mellem Trello og Asana. Her sammenligner vi de gratis planer og hjælper dig med at beslutte, hvilket projektstyringsværktøj der er bedst for dit team. Læs mere .

10. Brook's Law

"At tilføje arbejdskraft til et sent softwareprojekt gør det senere."

Næste gang du kommer sent med et projekt, hvilket sandsynligvis er, da de fleste programmeringsprojekter har brug for mere tid end tildelt, skal du huske, at tilføjelse af kodere ikke løser det hurtigere.

Faktisk vil det sandsynligvis tage længere at færdiggøre. Ikke kun har du brug for at bringe de nye kodere (r) op på hastighed, de vil sandsynligvis komme i konflikt med de eksisterende kodere. Flere ting skal dokumenteres, mere bureaukrati vil være nødvendigt for at holde alle på samme side, og mere friktion kommer ud af hele crunch-tiden oplevelse.

Fremad som programmerer

Nu hvor du kender disse principper, er du faktisk bedre egnet til virkelige verden af programmering, ikke kun hvad du har stødt på i skolen, på et webkursus eller i en bootcamp. Disse principper kommer fra mange års erfaring og fiaskoer.

Med denne nyvundne visdom kan du nu angive en høj-efterspørgsel programmering karriere 10 Computerprogrammeringsjob der er i efterspørgsel lige nuDa landing af et programmeringsopgave kan være hårdt i det aktuelle landskab, kan du overveje at fokusere på en af ​​følgende koncentrationer for at forbedre dine chancer for succes. Læs mere med mere realistiske forventninger. For at lære, hvordan man gør det maksimere dine programmerings karrieremuligheder Sådan forbedres dine programmeringsmuligheder for programmeringHvis du håber på at starte, genstarte eller på anden måde forbedre din programmeringskarriere, er det ikke let. Hvis du er på college, er tiden nu. Her er nogle tip, der kan tage dig langt. Læs mere . Og hvis du beslutter, at programmering ikke er noget for dig, skal du ikke bekymre dig - overvej en af ​​disse ikke-kodende tech-job i stedet Kodning er ikke for alle: 9 tekniske job, du kan få uden detBliv ikke afskrækket, hvis du vil være en del af det tekniske felt. Der er masser af job for mennesker uden kodningsevner! Læs mere .

Hvilke af disse principper ringer bedst for dig? Kender du til andre underlige programmeringsprincipper, som vi har savnet? Fortæl os det i kommentarerne nedenfor!