De konstigaste programmeringsprinciperna du aldrig hört

Vi har redan gått igenom de viktigaste programmeringsprinciperna. 10 Grundläggande programmeringsprinciper Varje programmerare måste följa 10 grundläggande programmeringsprinciper. Varje programmerare måste följa Skriv alltid kod som kan underhållas av alla som kanske hamnar på din programvara. För detta ändamål finns här flera programmeringsprinciper för att hjälpa dig att rensa upp din handling. Läs mer du behöver veta om, men det finns en annan klass av programmeringsprinciper som kan visa sig ännu mer fördelaktigt än dem.

De ovannämnda principerna lär dig hur du ska vara smart Med din kod kommer följande principer att lära dig att vara klok med din kod. Några av dem är konstiga, och många av dem är humoristiska, men de är alla lika praktiska och viktiga. Ta hand om dig!

1. The Bloat Principle

Den här har så många variationer att det är svårt att välja en som huvudman. Kanske mest “officiell” versionen är lagen om mjukvaruutveckling, vanligare kallad Zawinskis lag, uppkallad efter Jamie Zawinski och nämns i Konsten av UNIX-programmering:

“Varje program försöker expandera tills det kan läsa post. De program som inte kan expandera ersätts av sådana som kan.”

Det talar om tendensen av program för att attrahera fler och fler funktioner över tiden och oundvikligen driva mot ökad komplexitet. Du kanske vet detta som funktionen krypa, vilket är det pågående tillägget av nya funktioner som inte har något att göra med huvudsyftet med programmet. Feature creep leder till uppblåsthet, och uppblåsthet är ofta oönskad.

Detta kan också gälla programvaruprestanda:

“Programvaran expanderar för att konsumera alla tillgängliga resurser.”

På 90-talet var hårddiskar och processorer och RAM mer långtgående än de är idag och programmerare arbetade hårt för att passa så mycket som de kunde inom gränserna. Men nu när vi har större enheter och snabbare CPUer och mer RAM, kämpar vi fortfarande för att respektera gränserna. Allt blir uppblåst över tiden. Det är ditt jobb att hålla det i kontroll.

2. Den “Värre är bättre” Mentalitet

Nästan som om vi svarar på Bloat Principle, har vi Värre är bättre mentalitet, först myntad av Richard P. Gabriel i en uppsats som han skrev om mjukvarukvalitet:

“Programvara som är begränsad men enkel att använda kan vara mer tilltalande för användaren och marknaden än omvänden.”

Det är med andra ord klokt att räkna ut ett problem din programvara syftar till att lösa och då vara mycket bra på den där saken. Håll det enkelt. Ju mer du sprider dig tunn, ju mer oövervinnligt projektet blir, och ju mer oönskade det blir för användarna.

Vad händer när du ignorerar det här? Du hamnar med Software Peter Principle:

“Ett alltför komplicerat projekt blir så småningom för komplicerat att förstås även av egna utvecklare.”

Det kommer från den bredare Peter-principen, som säger att när anställda främjas baserat på deras nuvarande kompetens och inte deras förväntade kompetens i sin nästa position, hamnar alla anställda i en oförmåga. Ta den principen och tillämpa den på programvara, så ser du varför sämre programvaror ofta kan bli bättre.

3. Eaglesons lag

“Varje egen kod som du inte har tittat på i sex eller flera månader kan också ha skrivits av någon annan.”

Detta till synes demotivativa ordstäv är faktiskt något att omfamna. Faktum är att ingen är perfekt. Du kanske tror att du är en geni programmerare just nu, men det finns det alltid något mer du kan lära dig, alltid mer utrymme att växa. Om du någonsin ser tillbaka på gammal kod och cringe, betyder det förmodligen du har lärt dig något nytt sedan dess.

Sätt på ett annat sätt: om du tittar tillbaka på ett gammalt projekt och du inte kan se någonting du kan förbättra eller skulle göra annorlunda nästa gång har du antagligen stagnerat som programmerare.

4. Principen om minsta förvåning

“Om en nödvändig funktion har stor förvåningsfaktor, kan det vara nödvändigt att omforma funktionen.”

Första publicerad i IBM Systems Journal tillbaka 1984, är denna princip fortfarande överraskande relevant idag - kanske mer än någonsin tidigare.

Det handlar i huvudsak om den känsliga balansen mellan innovation och förtrogenhet: om ett program är för annorlunda från andra av sitt slag och överensstämmer inte med användarens förväntningar då de kommer sannolikt inte att anta det. Det är bättre att sträva efter stegvisa förbättringar som bara är stora nog för att vara imponerande men små nog att vara bekanta.

5. Cybernetisk Entomologins lag

“Det finns alltid ytterligare en bugg.”

Ofta kallad Lubarskijs lag för cybernetisk entomologi, Det är oklart vem det här Lubarsky faktiskt är. Hans princip gäller dock för alla programmerare: oavsett hur rent du skriver din kod, oavsett hur robust du testar dina moduler, oavsett hur ofta du refactor dina klasser kommer det alltid att finnas en annan bugg.

På ett sätt är detta en frigöringsprincip. Medan vi definitivt skulle sträva för felfri kod är det också viktigt att komma ihåg att perfektionismen är fienden av gott. Leta efter buggar, fixa dem när de uppstår och fortsätt sedan.

6. Kernighans lag

“Debugging är dubbelt så svårt som att skriva koden i första hand. Därför är du, enligt definition, inte smart nog att felsöka den om du skriver koden så smart som möjligt.”

Brian Kernighan, samma som medförfattare C-programmeringsspråkbibeln Varför C-programmering är fortfarande värt att lära sig Varför C-programmering är fortfarande värt att lära C är inte ett dödsspråk. Faktum är att IEEE Spectrum-tidningen rankade det som toppmålet nr 2 i 2017. Här är fem skäl till varför. Läs mer, är känd för denna insikterande lag. Kärnan i det är detta: skriv Bra kod, skriv läsbar kod, skriv enkel koda, allt så länge det inte är det duktig koda.

Att försöka böja programmeringsmusklerna med elfenbenstornkomplexiteten är det exakta motsatsen till vad det innebär att skriva rent och bättre kod 10 Tips för att skriva renare och bättre kod 10 Tips för att skriva renare och bättre kod Skriva ren kod ser lättare ut än det faktiskt är, men fördelarna är värda det. Så här kan du börja skriva renare kod idag. Läs mer . Ju svårare din kod är att förstå, desto hårdare blir det att felsöka när det oundvikligen bryts.

Och som Robert C. Martin förklarar handlar det inte bara om att felsöka antingen:

“Faktum är att förhållandet mellan tidspensionering och skrivning är väl över 10 till 1. Vi läser hela tiden gammal kod som en del av ansträngningen att skriva ny kod ... [Därför] gör det lätt att läsa gör det enklare att skriva.”

7. Rubber Duck Debugging

Det här är inte så mycket en princip som det är en teknik, men det är så bra och konstigt att vi skulle vara remiss att lämna den ut.

Först berättade i Den Pragmatiska Programmeraren, gummibandspårning är när du debuggar bruten mjukvara genom att förklara din kod till ett livligt objekt (t.ex. en gummiband) en rad i taget. Det fungerar eftersom förklaringshandlingen utlöser olika delar av din hjärna, och du är mer benägna att upptäcka inkonsekvenser och ta reda på var du gick fel.

Av den anledningen kan en gummiband vara en överraskande snygg present till programmerare The Best Geek Gifts för Programmerare: 20 Idéer för kodare och nördar De bästa Geek presenterna för Programmerare: 20 Idéer för kodare och nördar Letar du efter en present till en programmerare? Här är de bästa geekgåvorna, allt från mekaniska tangentbord till stående skrivbord och mer. Läs mer, oavsett om du köper det själv eller för en programmering kompis av din.

8. Den Ninja Ninja Regeln

“De första 90 procenten av koden står för de första 90 procenten av utvecklingstiden. De återstående 10 procenten av koden står för de övriga 90 procenten av utvecklingstiden.”

Detta fräcka lilla proverb av Tom Cargill blir kärnan i varför programmering kan vara så frustrerande: oavsett hur nära du tror att du ska vara klar, du är mycket längre bort än till och med dina bästa uppskattningar. När du tror att du är klar är du bara halvvägs där.

Det går hand i hand med Hofstadters lag:

“Det tar alltid längre tid än du förväntar dig, även om du tar hänsyn till Hofstadters lag.”

9. Parkinsons lag

“Arbetet expanderar för att fylla den tid som är tillgänglig för dess slutförande.”

Den här principen, som utarbetats av Cyril Northcote Parkinson, är en bredare princip som helt och hållet gäller programmering och går hand i hand med nittiohalvtio stycket ovan: hur mycket tid du måste slutföra ett projekt är exakt hur länge det kommer att ta. I mjukvaruutveckling, “avslutar tidigt” är ganska mycket en myt.

Parkinsons lag är anledningen till att korrekta tidsfrister är avgörande om du vill avsluta och skicka din programvara. Därför rekommenderar moderna professionella programmörer ofta agila projekthanteringsprinciper. Hur man använder Agile Project Management-principer för att organisera ditt liv. Hur man använder Agile Project Management-principer för att organisera ditt liv. Agile, mest känt som en projekthanteringsmetod, är en bra ram för hantering av ditt privatliv. Vi visar vilka principer du kan låna - gratis kalkylark nedladdning ingår! Läs mer och projekthanteringsverktyg som Asana Trello vs Asana: Det bästa kostnadsfria projekthanteringsverktyget är ... Trello vs Asana: Det bästa gratis projekthanteringsverktyget är ... Att välja mellan Trello och Asana är svårt. Här jämför vi de fria planerna och hjälper dig att bestämma vilket projekthanteringsverktyg som är bäst för ditt team. Läs mer .

10. Brooks Law

“Att lägga till arbetskraft till ett sent mjukvaruprojekt gör det senare.”

Nästa gång du är sen på ett projekt, vilket är troligt eftersom de flesta programmeringsprojekt behöver mer tid än tilldelas, kom ihåg att lägga till kodare inte löser det snabbare.

Faktum är att det antagligen tar längre att slutföra. Inte bara behöver du ta med den nya kodaren (er) snabbt, de kommer sannolikt att kollidera med befintliga kodare. Fler saker måste dokumenteras, mer byråkrati kommer att behövas för att hålla alla på samma sida, och mer friktion kommer att komma ut ur hela crunch-time-upplevelsen.

Kommer framåt som programmerare

Nu när du känner till dessa principer är du faktiskt bättre lämpad för verkliga världen programmering, inte bara vad du har stött på i skolan, på en webbkurs eller i en bootcamp. Dessa principer kommer från år och år av erfarenhet och misslyckanden.

Med denna nyfunna visdom kan du nu lägga fram en högkvalitativ programmeringskarriär 10 Datorprogrammeringsjobb som är i efterfrågan just nu 10 Datorprogrammeringsjobb som är i efterfrågan just nu Eftersom landning kan ett programmeringsjobb vara tufft i det nuvarande landskapet, överväga att fokusera på en av följande koncentrationer för att förbättra dina chanser att lyckas. Läs mer med mer realistiska förväntningar. För att lära dig hur du maximerar dina karriärmöjligheter för programmering Hur man förbättrar din programmering Karriärmöjligheter Hur man förbättrar dina karriärmöjligheter för programmering Om du hoppas att starta, starta om eller på annat sätt förbättra din programmeringskarriär är det inte lätt. Om du är på college, är tiden nu. Här är några tips som kan ta dig långt. Läs mer . Och om du bestämmer dig för att programmeringen inte är för dig, var inte orolig - överväga en av dessa icke-kodande tech jobb istället Kodning är inte för alla: 7 Tekniska jobb du kan få utan att kodning är inte för alla: 7 Tekniska jobb som du kan få utan att inte bli avskräckt om du vill vara en del av teknikområdet - det finns gott om jobb för personer som inte vet hur man kodar! Läs mer .

Vilka av dessa principer ringer dig mest? Känna till några andra konstiga programmeringsprinciper som vi missade? Låt oss veta ner i kommentarerna nedan!