De rareste programmeringsprinsippene du aldri har hørt om

De rareste programmeringsprinsippene du aldri har hørt om / programmering

Vi har allerede gått deg gjennom de mest essensielle programmeringsprinsippene. 10 Grunnleggende programmeringsprinsipper Hver programmerer må følge 10 grunnleggende programmeringsprinsipper Hver programmerer må følge Skriv alltid kode som kan vedlikeholdes av alle som kanskje ender med å jobbe med programvaren. Til dette formål er det flere programmeringsprinsipper for å hjelpe deg med å rydde opp i handlingen. Les mer du trenger å vite om, men det er en annen klasse programmeringsprinsipper som kan vise seg enda mer gunstig enn de.

Mens de nevnte prinsippene lærer deg hvordan du skal være smart med koden din, vil følgende prinsipper lære deg å være klok med koden din. Noen av dem er rart, og mange av dem er humoristiske, men de er alle like praktiske og viktige. Vær oppmerksom!

1. The Bloat Principle

Denne har så mange variasjoner at det er vanskelig å velge en som den viktigste. Kanskje mest “offisielt” versjonen er loven om programvareutvikling, mer vanlig kalt Zawinskis lov, oppkalt etter Jamie Zawinski og nevnt i Art of UNIX Programmering:

“Hvert program forsøker å utvide til det kan lese e-post. De programmene som ikke kan utvides, erstattes av de som kan.”

Det snakker om tendensen til programmer for å tiltrekke seg flere og flere funksjoner over tid og uunngåelig drift mot økt kompleksitet. Du kan kanskje dette som funksjon kryp, som er kontinuerlig tillegg av nye funksjoner som ikke har noe å gjøre med hovedformålet med programmet. Feature creep fører til oppblåsthet, og oppblåsthet er ofte uønsket.

Dette kan også gjelde for programvareytelse:

“Programvaren utvides for å forbruke alle tilgjengelige ressurser.”

Tilbake på 90-tallet var harddisker og CPUer og RAM langt mer restriktive enn de er i dag, og programmererne jobbet hardt for å passe så mye de kunne innenfor grensene. Men nå som vi har større stasjoner og raskere CPUer og mer RAM, sliter vi fortsatt med å respektere grenser. Alt blir oppblåst over tid. Det er din jobb å holde det i sjakk.

2. Den “Verre er bedre” mentalitet

Nesten som om som svar på Bloat-prinsippet, har vi Verre er bedre mentalitet, først laget av Richard P. Gabriel i et essay han skrev om programvarekvalitet:

“Programvare som er begrenset, men enkel å bruke, kan være mer tiltalende for brukeren og markedet enn omvendt.”

Det er med andre ord klokt å finne ut av ett problem Programvaren tar sikte på å løse og da være veldig bra på den ene tingen. Hold det enkelt. Jo mer du sprer deg tynn, jo mer uhåndterlig prosjektet blir, og jo mer uønsket blir det for brukere.

Hva skjer når du ignorerer dette? Du ender med Programvare Peter Prinsipp:

“Et altfor komplekst prosjekt vil etter hvert bli for komplisert for å bli forstått selv av egne utviklere.”

Det kommer fra den bredere Peter-prinsippen, som sier at når ansatte blir fremmet basert på deres nåværende kompetanse og ikke deres forventede kompetanse i neste stilling, vil alle medarbeidere til slutt komme i en stilling som inkompetanse. Ta det prinsippet og bruk det til programvare, og du vil se hvorfor verre programvare kan ofte bli bedre.

3. Eaglesons lov

“Enhver kode som du ikke har sett på i seks eller flere måneder, kan også ha blitt skrevet av noen andre.”

Dette tilsynelatende demotiverende ordtaket er faktisk noe å omfavne. Faktum er at ingen er perfekt. Du tror kanskje du er en geni programmerer akkurat nå, men det er alltid noe mer du kan lære, alltid mer plass til å vokse. Hvis du noen gang ser tilbake på gammel kode og cringe, betyr det sannsynligvis du har lært noe nytt siden da.

Sett på en annen måte: Hvis du ser tilbake på et gammelt prosjekt, og du ikke kan se noe du kan forbedre eller ville gjøre annerledes neste gang, har du sannsynligvis stagnert som programmerer.

4. Prinsippet om minste forbauselse

“Hvis en nødvendig funksjon har en stor forbauselsesfaktor, kan det være nødvendig å omforme funksjonen.”

Først publisert i IBM Systems Journal tilbake i 1984, er dette prinsippet fortsatt overraskende relevant i dag - kanskje mer enn noensinne.

Det berører i hovedsak den delikate balansen mellom innovasjon og kjennskap: hvis et program er for annerledes fra andre av sin art og ikke samsvarer med brukerens forventninger, da de vil sannsynligvis ikke vedta det. Det er bedre å streve for inkrementelle forbedringer som bare er store nok til å være imponerende, men små nok til å bli kjent.

5. Lov om cybernetisk entomologi

“Det er alltid en ekstra feil.”

Ofte kalt Lubarskijs lov om cybernetisk entomologi, Det er uklart hvem denne Lubarsky egentlig er. Men hans prinsipp ringer sant for alle programmerere: Uansett hvor rent du skriver koden din, uansett hvor robust du tester modulene dine, uansett hvor ofte du refactor dine klasser, vil det alltid være en annen feil.

På en måte er dette et frigjøringsprinsipp. Mens vi definitivt skulle strebe For feilfri kode er det også viktig å huske at perfeksjonisme er fienden til god. Se etter feil, reparer dem når de oppstår, og fortsett deretter.

6. Kernighans lov

“Feilsøking er dobbelt så vanskelig som å skrive koden i utgangspunktet. Derfor, hvis du skriver koden så smart som mulig, er du per definisjon ikke smart nok til å feilsøke den.”

Brian Kernighan, den samme som medforfatter C-programmeringsspråket Bibelen Hvorfor C Programmering er fortsatt verdt å lære Hvorfor C Programmering er fortsatt verdt å lære C er ikke et dødt språk. Faktisk rangert IEEE Spectrum Magazine som nr. 2 toppspråk i 2017. Her er fem grunner til hvorfor. Les mer, er kjent for denne innsiktige loven. Kjernen i det er dette: skriv flink kode, skriv leselig kode, skriv enkel kode, alt så lenge det ikke er det flink kode.

Forsøk å bøye programmeringsmusklene med elfenbenstårn kompleksitet er nøyaktig motsatt av hva det betyr å skrive ren og bedre kode. 10 Tips for å skrive renere og bedre kode. 10 Tips for å skrive renere og bedre kode. Skrive ren kode ser enklere ut enn det egentlig er, men fordelene er verdt det. Slik kan du begynne å skrive renere kode i dag. Les mer . Jo vanskeligere koden din er å forstå, jo vanskeligere blir det å feilsøke når det uunngåelig bryter.

Og som Robert C. Martin forklarer, handler det ikke bare om feilsøking:

“Faktisk er forholdet mellom tid brukt mot skriving godt over 10 til 1. Vi leser stadig gammel kode som en del av arbeidet med å skrive ny kode ... [Derfor] gjør det enkelt å lese gjør det lettere å skrive.”

7. Rubber Duck Debugging

Denne er ikke så mye et prinsipp som det er en teknikk, men det er så hjelpsomt og rart at vi vil være remiss for å forlate det.

Først fortalt i Den pragmatiske programmereren, gummi duck feilsøking er når du feilsøker ødelagt programvare ved å forklare koden din til et livløs objekt (for eksempel en gummidike) en linje av gangen. Det virker fordi forklaringsvirkningen utløser forskjellige deler av hjernen din, og du er mer sannsynlig å oppdage inkonsekvenser og finne ut hvor du gikk galt.

Av den grunn kan en gummiand være en overraskende fin gave til programmerere The Best Geek Gaver til programmerere: 20 ideer for kodere og nerds De beste geekgaver til programmerere: 20 ideer for kodere og nerds Leter du etter en gave til en programmerer? Her er de beste geekgaver, alt fra mekaniske tastaturer til stående skrivebord og mer. Les mer, enten du kjøper det selv eller for en programmering kompis av deg.

8. Den Ninety-Ninety Rule

“De første 90 prosent av koden står for de første 90 prosent av utviklingsperioden. De resterende 10 prosent av koden står for de andre 90 prosent av utviklingsperioden.”

Dette frekk, lille ordsprosjektet av Tom Cargill blir sentralt i hvorfor programmering kan være så frustrerende: uansett hvor nært du tror du skal ferdig, er du mye lenger unna enn til og med dine beste estimater. Når du tror du er ferdig, er du bare halvveis der.

Det går hånd i hånd med Hofstadters lov:

“Det tar alltid lengre tid enn du forventer, selv når du tar hensyn til Hofstadters lov.”

9. Parkinsons lov

“Arbeidet utvides for å fylle tiden som er tilgjengelig for ferdigstillelse.”

Dette prinsippet, laget av Cyril Northcote Parkinson, er et bredere prinsipp som absolutt gjelder for programmering og går hånd i hånd med nitti og nitti regelen ovenfor: hvor mye tid du må fullføre et prosjekt, er nøyaktig hvor lenge det skal ta. I programvareutvikling, “Etterbehandling tidlig” er ganske mye en myte.

Parkinsons lov er grunnen til at riktige frister er avgjørende hvis du vil fullføre og sende din programvare. Derfor anbefaler moderne profesjonelle programmerere ofte agile prosjektstyringsprinsipper. Hvordan bruke Agile Project Management prinsipper for å organisere livet. Hvordan bruke Agile Project Management prinsipper for å organisere livet ditt. Agile, best kjent som en prosjektledelsesmetode, er et godt rammeverk for å administrere din personlige liv. Vi vil vise deg hvilke prinsipper du kan låne - gratis regneark nedlasting inkludert! Les mer og prosjektstyringsverktøy som Asana Trello vs Asana: Det beste gratis prosjektstyringsverktøyet er ... Trello vs Asana: Det beste gratis prosjektstyringsverktøyet er ... Å velge mellom Trello og Asana er vanskelig. Her sammenligner vi de gratis planene og hjelper deg med å bestemme hvilket prosjektstyringsverktøy som passer best for teamet ditt. Les mer .

10. Brooks lov

“Å legge til arbeidskraft til et sent programprosjekt gjør det senere.”

Neste gang du er forsinket på et prosjekt, noe som er sannsynlig siden de fleste programmeringsprosjektene trenger mer tid enn tildelt, må du huske at å legge til kodere ikke vil løse det noe raskere.

Faktisk vil det nok ta lenger å fullføre. Ikke bare trenger du å bringe den nye koderen (e) opp i fart, de vil trolig kollidere med eksisterende kodere. Flere ting må dokumenteres, mer byråkrati vil være nødvendig for å holde alle på samme side, og mer friksjon vil komme ut av hele crunch-time-opplevelsen.

Går frem som programmerer

Nå som du kjenner disse prinsippene, er du faktisk bedre egnet for virkelige verden programmering, ikke bare det du har møtt på skolen, i et nettkurs eller i en bootcamp. Disse prinsippene kommer fra mange års erfaring og feil.

Med denne nyskapede visdom kan du nå sette opp til en høy etterspørsel programmering karriere 10 Computer Programmering Jobb som er i etterspørselen akkurat nå 10 Computer Programming Jobs som er i etterspørselen akkurat nå Siden landing en programmeringsjobb kan være tøft i dagens landskap, vurdere å fokusere på en av følgende konsentrasjoner for å forbedre sjansene for suksess. Les mer med mer realistiske forventninger. For det, lær hvordan du maksimerer programmerings karrieremuligheter. Slik forbedrer du programmerings Karrieremuligheter. Slik forbedrer du programmerings Karrieremuligheter Hvis du håper å starte, starte på nytt eller på annen måte forbedre programmeringskarrieren, er det ikke lett. Hvis du er på college, er tiden nå. Her er noen tips som kan ta deg langt. Les mer . Og hvis du bestemmer deg for at programmering ikke er for deg, ikke vær redd - vurder en av disse ikke-kodende tech jobbene i stedet. Koding er ikke for alle: 7 Tekniske jobber du kan få uten det, koding er ikke for alle: 7 Tekniske jobber du kan få uten det Ikke bli motløs hvis du vil være en del av teknologifeltet - det er mange jobber for folk som ikke vet hvordan man skal kode! Les mer .

Hvilke av disse prinsippene ringer deg mest? Vet om noen andre rare programmeringsprinsipper som vi savnet? Gi oss beskjed ned i kommentarene nedenfor!