Hienoimmat ohjelmointiperiaatteet, joita et ole koskaan kuullut

Mainos

Olemme jo käyneet läpi tärkeimmät ohjelmointiperiaatteet 10 ohjelmoinnin periaatetta jokaisen ohjelmoijan on noudatettavaKirjoita aina koodi, jota ylläpitää kuka tahansa, joka voi työskennellä ohjelmistosi kanssa. Tätä varten tässä on useita ohjelmointiperiaatteita, jotka auttavat sinua puhdistamaan teoksesi. Lue lisää sinun täytyy tietää, mutta on olemassa toinen luokka ohjelmointiperiaatteita, jotka voivat osoittautua vieläkin hyödyllisempi kuin nuo.

Kun taas edellä mainitut periaatteet opettavat sinulle kuinka olla fiksu koodillasi seuraavat periaatteet opettavat sinua olemaan viisas koodillasi. Jotkut heistä ovat outoja ja monet heistä ovat humoristisia, mutta he ovat kaikki yhtä käytännöllisiä ja tärkeitä. Varo!

1. Paisuntaperiaate

Tällä on niin monia muunnelmia, että on vaikea valita yksi päävaihtoehdosta. Ehkä "virallisin" versio on ohjelmistokehityslaki, jota kutsutaan yleisemmin Zawinskin laki, nimeltään Jamie Zawinski ja mainittu vuonna UNIX-ohjelmoinnin taide:

”Jokainen ohjelma yrittää laajentua, kunnes se pystyy lukemaan sähköpostia. Ne ohjelmat, jotka eivät voi niin laajentua, korvataan ohjelmilla, jotka voivat. "

instagram viewer

Se puhuu ohjelmien taipumuksesta houkutella yhä enemmän ominaisuuksia ajan myötä ja väistämättä ajautumassa kasvavaan monimutkaisuuteen. Saatat tietää tämän nimellä ominaisuus hiipii, joka on jatkuva uusien ominaisuuksien lisääminen, joilla ei ole mitään tekemistä ohjelman päätarkoituksen kanssa. Ominaisuuden viruminen johtaa turvotukseen, ja paisuminen on usein toivottavaa.

Tämä voi koskea myös ohjelmistojen suorituskykyä:

"Ohjelmisto laajenee kuluttamaan kaikkia käytettävissä olevia resursseja."

90-luvulla kiintolevyt, prosessorit ja RAM olivat paljon rajoittavampia kuin nykyään, ja ohjelmoijat työskentelivät ahkerasti sovittaakseen niin paljon kuin pystyivät. Nyt kun meillä on isommat asemat, nopeammat prosessorit ja enemmän RAM-muistia, pyrimme silti noudattamaan rajoja. Kaikki paisuu ajan myötä. Sinun tehtäväsi pitää se kurissa.

2. "Huonompi on parempi" mentaliteetti

Melkein ikään kuin vastauksena paisuntaperiaatteeseen meillä on Pahempaa on parempi mentaliteetti, keksi ensimmäisenä Richard P. Gabriel kirjoitti esseessä ohjelmiston laadusta:

"Rajoitettu, mutta helppokäyttöinen ohjelmisto voi olla houkuttelevampi käyttäjille ja markkinoille kuin päinvastoin."

Toisin sanoen, on viisasta selvittää yksi ongelma ohjelmistosi tavoitteena on ratkaista ja sitten olla Oikein hyvä siinä yksi asia. Pidä se yksinkertaisena. Mitä enemmän levitä itseäsi, sitä hallitsemattomammaksi projekti tulee, ja sitä epätoivottavampaa se tulee käyttäjille.

Mitä tapahtuu, kun sivuutat tämän? Loppujen lopuksi Ohjelmisto Peter-periaate:

"Liian monimutkaisesta projektista tulee lopulta liian monimutkainen ymmärtää jopa sen omat kehittäjät."

Se tulee laajemmasta Peterin periaatteesta, jonka mukaan työntekijöitä ylennetään heidän nykyhetkensä perusteella pätevyys eikä odotettu pätevyys seuraavassa tehtävässään, kaikki työntekijät päätyvät lopulta asemaan epäpätevyys. Ota tämä periaate ja sovella sitä ohjelmistoihin, ja huomaat, miksi huonommat ohjelmistot voivat usein olla parempia.

3. Eaglesonin laki

"Joku muu on saattanut kirjoittaa myös kaikki omat koodisi, joita et ole tarkastellut vähintään kuuden kuukauden ajan."

Tämä näennäisesti motivoiva sanonta on oikeastaan ​​jotain omaksuttavaa. Tosiasia, kukaan ei ole täydellinen. Saatat ajatella, että olet nero ohjelmoija juuri nyt, mutta siellä on aina jotain enemmän mitä voit oppia, aina enemmän tilaa kasvaa. Jos tarkastellaan vanhaa koodia ja ryömimistä, se todennäköisesti tarkoittaa olet oppinut siitä lähtien jotain uutta.

Toinen tapa: jos katsot taaksepäin vanhaan projektiin ja et näe mitään parannettavaa tai mitä tekisit seuraavalla kerralla, olet todennäköisesti stagneutunut ohjelmoijana.

4. Vähimmäisen yllätyksen periaate

"Jos tarpeellisella ominaisuudella on suuri hämmästyskerroin, ominaisuus voi olla tarpeen suunnitella uudelleen."

Ensimmäinen julkaistu IBM Systems Journal Vuonna 1984 tämä periaate on edelleen yllättävän tärkeä nykyään - ehkä enemmän kuin koskaan ennen.

Se koskettaa lähinnä herkkää tasapainoa innovaatioiden ja perehtymisen välillä: jos ohjelmisto on liian erilainen toisiltaan sen tyyppisistä tiedoista ja sitten ei vastaa käyttäjän odotuksia he todennäköisesti eivät hyväksy sitä. On parempi pyrkiä asteittaisiin parannuksiin, jotka ovat vain riittävän suuria vaikuttamaan, mutta riittävän pieniä pysyäkseen tuttuina.

5. Kyberneettisen entomologian laki

"Aina on yksi lisävika."

Usein kutsuttu Lubarskyn kyberneettisen entomologian laki, on epäselvää, kuka tämä Lubarsky oikeasti on. Hänen periaate pätee kuitenkin kaikille ohjelmoijille: riippumatta siitä, kuinka puhtaasti kirjoitat koodisi, ei väliä kuinka testaat moduulejasi tukevasti riippumatta siitä, kuinka usein reagoit kursseihisi, aina tulee uusi virhe.

Tämä on tavallaan vapauttava periaate. Vaikka meidän pitäisi ehdottomasti pyrkiä virheetöntä koodia varten on myös tärkeää muistaa, että perfektionismi on hyvän vihollinen. Etsi virheitä, korjaa ne, kun niitä ilmenee, ja siirry sitten eteenpäin.

6. Kernighanin laki

”Virheenkorjaus on kaksi kertaa vaikeampaa kuin koodin kirjoittaminen. Siksi, jos kirjoitat koodin niin taitavasti kuin mahdollista, et ole määritelmänsä mukaan riittävän fiksu vianmääritykseen. "

Brian Kernighan, sama kirjoittaja C-ohjelmointikielen raamattu Miksi C-ohjelmointi on edelleen oppimisen arvoistaC ei ole kuollut kieli. Itse asiassa IEEE Spectrum -lehti sijoitti sen vuoden 2017 kärkikieleksi. Tässä on viisi syytä miksi. Lue lisää , on kuuluisa tästä oivallisesta laista. Sen ydin on tämä: kirjoita hyvä koodi, kirjoita luettava koodi, kirjoita yksinkertainen koodi, mitään niin kauan kuin se ei ole taitava koodi.

Yritetään taipua ohjelmointilihaksiasi norsunluutornin monimutkaisuuteen nähden on täysin päinvastainen kuin tarkoittaa kirjoita puhdas ja parempi koodi 10 vinkkiä puhtaan ja paremman koodin kirjoittamiseenPuhtaan koodin kirjoittaminen näyttää helpommalta kuin se todellisuudessa on, mutta edut ovat sen arvoisia. Näin voit aloittaa puhtaan koodin kirjoittamisen tänään. Lue lisää . Mitä vaikeampaa koodi on ymmärtää, sitä vaikeampi on virheenkorjaus, kun se väistämättä katkeaa.

Ja kuten Robert C. Martin selittää, että kyse ei ole vain virheenkorjauksesta:

”Lukemiseen käytetyn ajan suhde kirjoittamiseen on todellakin yli 10: 1. Luemme jatkuvasti vanhaa koodia osana uuden koodin kirjoittamista... [Siksi] tekeminen helpoksi lukemiseksi helpottaa kirjoittamista. "

7. Kumiankka-virheenkorjaus

Tämä ei ole niinkään periaate, kuin se on tekniikka, mutta se on niin hyödyllistä ja outoa, että meillä ei ole oikeutta jättää sitä pois.

Ensin kerrottiin Pragmaattinen ohjelmoija, kumiankka-virheenkorjaus on, kun vianetsintää viallisesta ohjelmistosta selittämällä koodisi elottomalle esineelle (esim. kumi-ankkalle) yksi rivi kerrallaan. Se toimii, koska selitystoimenpide laukaisee aivojen eri osat, ja olet todennäköisemmin havainnut epäjohdonmukaisuuksia ja selvittänyt, missä menit pieleen.

Tästä syystä kumi-ankka voi olla a yllättävän lahja ohjelmoijille Paras Geek-lahja ohjelmoijille: 20 ideaa kodereille ja nörtteilleEtsitkö lahjaa ohjelmoijalle? Tässä ovat parhaat geek-lahjat mekaanisista näppäimistöistä pysyviin työpöydiin ja muihin. Lue lisää , ostatko sen itse tai ohjelmointikaverillesi.

8. Yhdeksänkymmentäyhdeksänkymmentä sääntö

”Koodin ensimmäiset 90 prosenttia vastaa kehityksen ensimmäisestä 90 prosentista. Loput 10 prosenttia koodista muodostaa loput 90 prosenttia kehitysajasta. ”

Tämä Tom Cargillin pirteä pieni sananlasku keskittyy siihen, miksi ohjelmointi voi olla niin turhauttavaa: riippumatta siitä, kuinka lähellä luulet olevansa valmis, olet paljon kauempana kuin edes parhaat arviosi. Kun luulet olevan valmis, olet vain puolivälissä.

Se kulkee käsi kädessä Hofstadterin lain kanssa:

"Se vie aina kauemmin kuin odotat, jopa kun otat huomioon Hofstadterin lain."

9. Parkinsonin laki

"Työ laajenee niin, että sen suorittamiseen käytettävissä oleva aika täyttyy."

Tämä yksi periaate, jonka kehitti Cyril Northcote Parkinson, on laajempi periaate, jota ehdottomasti sovelletaan ohjelmointiin ja joka menee käsi kädessä yllä olevan yhdeksänkymmentä -kymmentä -säännön kanssa: projektin loppuun saattamiseen kuluu kuitenkin paljon aikaa, kuinka kauan se kestää kestää. Ohjelmistokehityksessä ”varhainen viimeistely” on melko myytti.

Parkinsonin laki on syy siihen, miksi oikeat määräajat ovat tärkeitä, jos haluat viimeistellä ja lähettää ohjelmistosi. Siksi nykyaikaiset ammattimaiset ohjelmoijat suosittelevat usein ketterät projektinhallintaperiaatteet Kuinka käyttää ketterää projektinhallinnan periaatteita elämäsi järjestämiseenKetterä, tunnetaan parhaiten projektijohtamismenetelmänä, on loistava kehys henkilökohtaisen elämäsi hallintaan. Näytämme sinulle, mitkä periaatteet voit lainata - ilmainen laskentataulukon lataus mukana! Lue lisää ja projektinhallintatyökalut kuten Asana Trello vs. Asana: Paras ilmainen projektinhallintatyökalu on ...Valinta Trello ja Asana välillä on vaikeaa. Tässä verrataan ilmaisia ​​suunnitelmia ja autamme sinua päättämään, mikä projektinhallintatyökalu on paras ryhmällesi. Lue lisää .

10. Brookin laki

"Lisäämällä työvoimaa myöhässä olevaan ohjelmistoprojektiin, se tekee siitä myöhemmin."

Kun seuraavan kerran olet myöhässä projektin suhteen, on todennäköistä, että useimmat ohjelmointiprojektit tarvitsevat enemmän aikaa kuin varattu, muista, että koodereiden lisääminen ei ratkaise sitä nopeammin.

Itse asiassa se todennäköisesti vie kauemmin viedä loppuun. Paitsi, että sinun on nostettava uusi (t) kooderi (t) nopeuteen, ne todennäköisesti törmäävät olemassa oleviin koodereihin. Enemmän asioita on dokumentoitava, tarvitaan enemmän byrokratiaa kaikkien pitämiseksi samalla sivulla, ja koko kitka-ajan kokemuksesta tulee enemmän kitkaa.

Eteenpäin ohjelmoijana

Nyt kun tiedät nämä periaatteet, olet oikeasti paremmin sopiva oikeassa maailmassa ohjelmoinnista, ei vain siitä, mitä olet tavannut koulussa, verkkokurssilla tai käynnistysleirillä. Nämä periaatteet ovat peräisin vuosien kokemuksesta ja epäonnistumisista.

Tällä uudella tavalla löydetyllä viisaudella voit nyt lähteä a: ksi korkean kysynnän ohjelmointiuran 10 tietokoneohjelmointityötä, jotka ovat tällä hetkellä kysynnässäKoska ohjelmointityön purkaminen voi olla vaikeaa nykyisessä tilanteessa, harkitse keskittymistä yhteen seuraavista keskittymistä parantaaksesi menestysmahdollisuuksiasi. Lue lisää realistisemmilla odotuksilla. Tätä varten opi maksimoida ohjelmointiuran mahdollisuutesi Kuinka parantaa ohjelmointiuran mahdollisuuksiaJos haluat aloittaa, käynnistää uudelleen tai parantaa muuten ohjelmointiuraasi, se ei ole helppoa. Jos olet yliopistossa, aika on nyt. Tässä on vinkkejä, jotka voivat viedä sinut kauas. Lue lisää . Ja jos päätät, että ohjelmointi ei ole sinulle, älä murehdi - harkitse yhtä näistä ei-koodaavat tekniset työt sen sijaan Koodaus ei ole kaikille: 9 teknistä työtä, jotka voit saada ilman sitäÄlä lannistu, jos haluat olla osa tekniikan kenttää. Ihmisillä on paljon työpaikkoja ilman koodaustaitoja! Lue lisää .

Mikä näistä periaatteista kuuluu sinulle parhaiten? Tiedätkö muita oudon ohjelmoinnin periaatteita, jotka unohdimme? Kerro meille alla olevissa kommenteissa!