Kõige veidramad programmeerimispõhimõtted, mida te kunagi kuulnud pole

Reklaam

Oleme juba kõndinud teid läbi kõige olulisemad programmitöö põhimõtted 10 peamist programmeerimispõhimõtet, mida iga programmeerija peab järgimaKirjutage alati kood, mida saavad hooldada kõik, kes võivad teie tarkvaraga töötada. Selleks on siin mitu programmeerimispõhimõtet, mis aitavad teil oma tegevust puhastada. Loe rohkem peate teadma, kuid on veel üks programmeerimispõhimõtete klass, mis võib tõestada veelgi kasulikum kui need.

Arvestades, et eelnimetatud põhimõtted õpetavad teid olema nutikad oma koodiga õpetavad sind olema järgmised põhimõtted tark oma koodiga. Mõned neist on kummalised ja paljud neist on humoorikad, kuid nad on kõik ühtviisi praktilised ja olulised. Võtke arvesse!

1. Paistetuspõhimõte

Sellel variatsioonidel on nii palju variante, et seda on raske peamiseks valida. Võib-olla kõige “ametlikum” versioon on tarkvara arendamise seadus, mida sagedamini nimetatakse Zawinski seadus, nimetatud Jamie Zawinski järgi ja mainitud UNIX-i programmeerimise kunst:

„Iga programm üritab laieneda, kuni see suudab kirju lugeda. Need programmid, mis ei saa nii laieneda, asendatakse nendega, mis saavad. "

instagram viewer

See räägib programmide kalduvusest meelitada aja jooksul üha rohkem funktsioone ja triivima paratamatult üha keerukamaks. Võite seda teada funktsiooni pugemine, mis on pidev uute funktsioonide lisamine, millel pole programmi peamise eesmärgiga mingit pistmist. Funktsiooni pugemine põhjustab puhitus ja puhitus on sageli ebasoovitav.

See kehtib ka tarkvara jõudluse kohta:

"Tarkvara laieneb, et tarbida kõiki saadaolevaid ressursse."

90-ndatel olid kõvakettad, protsessorid ja muutmälu palju piiravamad kui praegu ning programmeerijad tegid kõvasti tööd, et mahutada oma piiridesse nii palju kui suutsid. Nüüd, kus meil on suuremad draivid, kiiremad protsessorid ja rohkem RAM-i, näeme endiselt vaeva, et piiridest kinni pidada. Kõik aja jooksul puhkeb. Teie ülesanne on seda kontrolli all hoida.

2. Mentaliteet “Hullem on parem”

Peaaegu justkui vastusena paistetuspõhimõttele on meil olemas Halvem on parem mentaliteet, esmakordselt loonud Richard P. Gabriel kirjutas essees tarkvara kvaliteedist:

"Piiratud, kuid lihtsasti kasutatav tarkvara võib olla kasutajale ja turule pigem veetlev kui vastupidine."

Teisisõnu, on mõistlik välja mõelda: üks probleem teie tarkvara eesmärk on lahendada ja siis olla väga hea selle ühe asja juures. Hoidke see lihtne. Mida rohkem hajutate ennast, seda juhitamatumaks projekt muutub ja seda ebasoovitavamaks see muutub kasutajatele.

Mis juhtub, kui seda eirata? Sa lõpuks Tarkvara Peetri põhimõte:

"Liiga keerukas projekt muutub lõpuks liiga keerukaks, et sellest aru saaks isegi selle arendajad."

See tuleneb laiemast Peetri põhimõttest, mis ütleb, et kui töötajaid edutatakse nende praeguse olukorra põhjal kompetentsuse ja mitte eeldatava kompetentsi järgmisel ametikohal, satuvad lõpuks kõik töötajad ametikohale ebakompetentsus. Võtke seda põhimõtet ja rakendage seda tarkvara suhtes ning näete, miks halvem tarkvara võib sageli olla parem.

3. Eaglesoni seadus

"Kõik teie enda koodid, mida te pole vähemalt kuus kuud uurinud, võis olla ka kellegi teise kirjutatud."

See näiliselt motiveeriv ütlus on tegelikult millegi omaks võtmine. Tegelikult pole keegi täiuslik. Võite arvata, et olete praegu geeniusprogrammeerija, kuid on olemas alati veel midagi õppida, alati rohkem ruumi kasvada. Kui vaatate kunagi vanale koodile tagasi ja kisendate, siis see ilmselt tähendab sellest ajast olete õppinud midagi uut.

Teisisõnu: kui vaatate tagasi vanale projektile ja te ei näe midagi, mida saaksite paremaks muuta või mida teeksite järgmisel korral teisiti, siis olete tõenäoliselt programmeerijana stagneerunud.

4. Vähima imestuse põhimõte

"Kui vajalikul funktsioonil on suur hämmastus, võib olla vaja funktsiooni ümber kujundada."

Esmakordselt avaldatud IBM Systems Journal 1984. aastal on see põhimõte üllatavalt asjakohane ka tänapäeval - võib-olla rohkem kui kunagi varem.

Põhimõtteliselt puudutab see delikaatset tasakaalu innovatsiooni ja tuttavuse vahel: kui mõni tarkvara on liiga erinev teiste omataolistega ja ei vasta siis kasutaja ootustele tõenäoliselt nad ei võta seda omaks. Parem on püüelda järkjärguliste paranduste poole, mis on lihtsalt piisavalt suured, et muljetavaldavad, kuid piisavalt väikesed, et jääda tuttavaks.

5. Küberneetilise entomoloogia seadus

"Alati on veel üks viga."

Sageli kutsutakse Lubarsky küberneetilise entomoloogia seadus, on ebaselge, kes see Lubarsky tegelikult on. Tema põhimõte kehtib aga kõigi programmeerijate jaoks: ükskõik kui puhtalt oma koodi kirjutate, ükskõik kuidas testite oma mooduleid kindlalt, hoolimata sellest, kui sageli te oma klasside ümberkorraldusi teete, on alati mõni teine ​​viga.

Mõnes mõttes on see vabastav põhimõte. Kuigi me peaks kindlasti püüdma vigadeta koodi jaoks on oluline meeles pidada, et perfektsionism on hea vaenlane. Otsige üles vead, parandage need tekkimisel ja liikuge siis edasi.

6. Kernighani seadus

„Silumine on kaks korda raskem kui koodi kirjutamine. Seetõttu, kui kirjutate koodi nii nutikalt kui võimalik, pole te definitsiooni kohaselt piisavalt tark, et seda siluda. ”

Brian Kernighan, sama kaasautor C-programmeerimiskeele piibel Miks tasub C-programmeerimist ikkagi õppida?C ei ole surnud keel. Tegelikult reastas ajakiri IEEE Spectrum selle 2017. aastal populaarseima keelena nr 2. Siin on viis põhjust, miks. Loe rohkem , on kuulus selle mõistva seaduse poolest. Selle tuum on see: kirjutage hea kood, kirjuta loetav kood, kirjuta lihtne kood, ükskõik mida seni, kuni seda pole kaval kood.

Programmeerimislihaste painutamine elevandiluust torni keerukusega on täpselt vastupidine sellele, mida see tähendab kirjuta puhas ja parem kood 10 näpunäidet puhtama ja parema koodi kirjutamiseksPuhta koodi kirjutamine tundub lihtsam kui see tegelikult on, kuid eelised on seda väärt. Siit saate teada, kuidas saate juba täna puhtamat koodi kirjutama hakata. Loe rohkem . Mida raskem on teie koodist aru saada, seda raskem on seda siluda, kui see paratamatult puruneb.

Ja nagu Robert C. Martin selgitab, et see ei tähenda ainult silumist:

„Tõepoolest, lugemiseks kulutatud aja ja kirjutamise suhe on tublisti üle 10: 1. Uue koodi kirjutamise osana loeme pidevalt vana koodi... [Seetõttu] muudab lugemise hõlpsaks kirjutamine. ”

7. Kummi pardi silumine

See ei ole mitte niivõrd põhimõte, kuivõrd see on tehnika, kuid see on nii kasulik ja kummaline, et meil oleks vaja jätta see tegemata.

Esmalt öeldi sisse Pragmaatiline programmeerija, kummist pardi silumine on siis, kui debugite katkist tarkvara, seletades oma koodi elutule objektile (nt kummipard) üks rida korraga. See töötab, kuna seletusjuhtimine käivitab teie aju erinevad osad ja tõenäolisem on, et märkate vastuolusid ja saate aru, kus te valesti läksite.

Sel põhjusel võib kummist part olla a üllatavalt vahva kingitus programmeerijatele Parimad Geeki kingitused programmeerijatele: 20 ideed kodeerijatele ja nohikuteleKas otsite kingitust programmeerijale? Siin on parimad geekingitused, alates mehaanilistest klaviatuuridest kuni seisvate töölaudadeni ja palju muud. Loe rohkem , kas ostate selle endale või oma programmeerimisõbrale.

8. Üheksakümne üheksakümne reegel

„Esimene 90 protsenti koodist moodustab arenduse aja esimesed 90 protsenti. Ülejäänud 10 protsenti koodist moodustab ülejäänud 90 protsenti arendusajast. ”

See Tom Cargilli särtsakas väike vanasõna saab keskpunkti, miks programmeerimine võib nii pettumust valmistada: hoolimata sellest, kui lähedale arvate, et olete lõpule jõudmas, olete palju kaugemal kui isegi teie parimad hinnangud. Kui arvate, et olete valmis, olete alles poole peal.

See on käsikäes Hofstadteri seadusega:

"See võtab alati kauem, kui võite oodata, isegi kui arvestate Hofstadteri seadust."

9. Parkinsoni seadus

"Töö laieneb nii, et selle valmimiseks oleks aega rohkem."

See üks põhimõte, mille autor on Cyril Northcote Parkinson, on laiem põhimõte, mis kehtib absoluutselt programmeerimise ja käsikäes ülaltoodud üheksakümne üheksakümne reegliga: hoolimata sellest, kui palju aega teil projekti lõpetamiseks kulub, on täpselt see, kui kaua see läheb võta. Tarkvaraarenduses on varajane lõpetamine müüt.

Parkinsoni seadus on põhjus, miks on õiged tähtajad üliolulised, kui soovite oma tarkvara lõpetada ja edastada. Sellepärast soovitavad tänapäevased professionaalsed programmeerijad sageli vilgas projektijuhtimise põhimõtted Kuidas kasutada vilgas projektijuhtimise põhimõtteid oma elu korraldamiseksAgiil, mida tuntakse kõige paremini projektijuhtimismeetodina, on suurepärane raamistik isikliku elu haldamiseks. Näitame teile, milliseid põhimõtteid saate laenata - komplekti kuulub ka tasuta töölehe allalaadimine! Loe rohkem ja projektihaldusriistad, näiteks Asana Trello vs. Asana: parim tasuta projektihalduse tööriist on ...Trello ja Asana vahel on keeruline valida. Võrdleme siin tasuta plaane ja aitame teil otsustada, milline projektijuhtimise tööriist sobib teie meeskonnale kõige paremini. Loe rohkem .

10. Brooki seadus

"Hilisele tarkvaraprojektile tööjõu lisamine muudab selle hiljem."

Järgmine kord projekti hilinemisega, mis on tõenäoliselt tõenäoline, kuna enamus programmeerimisprojekte vajab rohkem aega, kui ette nähtud, pidage meeles, et koodide lisamine ei lahenda seda kiiremini.

Tegelikult võtab see tõenäoliselt aega kauem lõpetama. Peate mitte ainult uue kodeerija (d) kiirendama, vaid nad satuvad tõenäoliselt vastuollu ka olemasolevate kooderitega. Rohkem asju tuleb dokumenteerida, vaja on rohkem bürokraatiat, et kõik samal lehel püsiksid, ja kogu krõbistamise kogemusest tuleb välja rohkem hõõrumisi.

Edasi programmeerijana

Nüüd, kui teate neid põhimõtteid, sobib teile tegelikult parem päris maailm programmeerimisest, mitte ainult sellest, millega olete kokku puutunud koolis, veebikursusel või alglaadimislaagris. Need põhimõtted pärinevad aastatepikkustest kogemustest ja ebaõnnestumistest.

Selle uue leidunud tarkuse abil saate nüüd a kõrge nõudlusega programmeerimiskarjäär 10 programmeerimistööd, mis on praegu nõudlusegaKuna programmeerimistöö maandamine võib praeguses maastikus olla keeruline, kaaluge oma eduvõimaluste parandamiseks keskendumist ühele järgmistest kontsentratsioonidest. Loe rohkem realistlikumate ootustega. Selleks õppige maksimeerige oma programmeerimiskarjäärivõimalused Kuidas parandada oma programmeerimiskarjäärivõimalusiKui loodate oma programmeerimiskarjääri alustada, taaskäivitada või muul viisil parandada, pole see lihtne. Kui olete ülikoolis, on aeg käes. Siin on mõned näpunäited, mis võivad teid kaugele viia. Loe rohkem . Ja kui otsustate, et programmeerimine pole teie jaoks, siis ärge muretsege - kaaluge ühte neist mitte kodeerivad tehnilised töökohad Kodeerimine pole kõigile: 9 tehnilist tööd, mida saate ilma selletaÄrge heitke end, kui soovite olla osa tehnikavaldkonnast. Kodeerimisoskuseta inimestel on palju töökohti! Loe rohkem .

Milline neist põhimõtetest sobib teile kõige paremini? Kas teate veel mõnda imelikku programmeerimispõhimõtet, millest me ilma jäime? Andke meile allpool kommentaarides teada!