Koska kirjoittamaani

-koodia käytän melkein aina vain itse

sinulla on vain itsellesi miellyttävä asia. Joten ainoa järkevä vastaus on tasapainottaa asiat minimoidaksesi turhautumisen itsellesi. Älä tee asioita, jotka näet turhauttavasti hidastavan sinua, ennen kuin olet turhautunut ongelmista, joita aiheutuu niiden tekemättä jättämisestä.

Kuitenkin strategisempi kysymys on, em> want jatkaa koodin kirjoittamista, jota vain sinä käytät ja näet. Jos haluat edetä urasi tekemällä yhteistyötä ikäisensä kanssa tai rakentamalla tutkijoiden ryhmän työskentelemään koodiesi kanssa, sinun on parempi tehdä enemmän aikaisemmin.

Sitten tiedät, että olet löysi hyvän tasapainon, kun yhteistyökumppanit, joiden kanssa haluat työskennellä, haluavat silti työskennellä kanssasi, kun he ovat viettäneet jonkin aikaa koodisi kanssa.

Sanoit:

Kirjoittamaani koodia käytän melkein aina vain itse

mutta pidän tätä huomautusta hieman lyhytnäköisenä.

Tällä hetkellä koodia voi käyttää melkein yksinomaan kirjoittaja / opiskelija-tutkija, mutta lopulta kyseinen opiskelija valmistuu, ja jatkotutkimusta saattaa olla tehtävä. Voi seuraavaa jatko-opiskelijaa, joka perii sen sotkun, tai kesäharjoittelijaa, joka palkataan siivoamaan se!

On paljon hyviä syitä sijoittaa vähän aikaa paremmin suunnitellun koodin kirjoittamiseen:

• Sinä (ja muut, jotka saatat liittyä tutkimusryhmään) pystyt edelleen rakentamaan hyvin suunnitellulle arkkitehtuurille.
• Se, mikä nyt näyttää olevan "itsedokumentointia", voi olla vaikeampi- seurata kuin luulet kuuden kuukauden päästä
• Paljon koodia tottuu lopulta kauemmin kuin alkuperäinen kirjoittaja arveli
• Mitä monimutkaisempi koodisi tulee, sitä vaikeampi se on debugata myöhemmin

Toki tulosten välittömyyden ja tulevaisuuden rakentamisen välillä on kompromissi. Mutta varoitin siitä, että tunkeudutaan väärään turvallisuustunteeseen ja koodin tyhjentämiseen niin nopeasti kuin pystyt, ottaen huomioon tulevaisuuden ylläpidettävyyden ja laajennettavuuden.

Kuten muillekin asiakirjoille, kirjoita yleisölle. Eli kirjoita koodisi, jotta se auttaisi parhaalla mahdollisella tavalla (silti kohtuullisin kustannuksin) niitä, jotka lukevat sitä. Harkitse:

1. Lukevatko muut kuin sinä koodia nyt vai tulevaisuudessa? Jos se on kertaluonteinen komentosarja, jonka hylkäät nopeasti, sinun ei tarvitse huolehtia paljon luettavuudesta. Jos kukaan muu ei todennäköisesti koskaan katso sitä, sinun on mietittävä, kuinka todennäköinen tulevasi itsesi on muistaa tuolloin tapahtunutta ja ymmärtää käyttämäsi käytännöt.

2. Jos muut todennäköisesti lukevat koodisi, kuinka teknisesti taitavia tietylle kielelle ja kirjastoille, ja yleensä, ovatko he todennäköisesti? Voitteko käyttää tavanomaisia ​​käytäntöjä, joita ohjelmoijat käyttävät kyseisellä kielellä? Tarvitsetko kirjoittaa asioita siten, että kokeneet kehittäjät, jotka eivät osaa kyseistä kieltä, voivat nopeasti ymmärtää, mitä teet? Täytyykö sinun välttää tavallisia asioita (esim. Luettelonäkymiä), joita kokematon kehittäjä ei ehkä ymmärrä hyvin?

3. Kuinka hyvin muut kehittäjät ymmärtävät ongelma-alueen? Pitäisikö sinun antaa yksityiskohtainen selitys siitä, mitä olet tekemässä ja miksi teet sen, vai odotatko, että kun he tarkastelevat riviä, he esimerkiksi näkevät heti, että se on eräänlainen Black Scholes -yhtälö ja ymmärrätkö miten ja miksi sitä käytetään siellä?

Muista, että tekemällä asioista kuvailevampi ja lisäämällä kommentteja ei välttämättä tehdä koodistasi luettavampaa; joillekin yleisöille, mikä saattaa jopa tehdä siitä vähemmän luettavan. Aivan kuten matemaatikot pystyvät ymmärtämään nopeammin tiheän yhtälön kuin pitkä kuvaus yhtälöstä, joka on kirjoitettu "tavallisella englanniksi", kokeneille kehittäjille, jotka tuntevat verkkotunnuksen, kestää huomattavasti kauemmin aloittelijalle kirjoitetun verbokoodin lukeminen kuin tiukan koodin kirjoittaminen asiantuntija, joka välittää tarkalleen mitä tarvitaan, eikä enempää. Äärimmäisenä esimerkkinä, lue tämä:

  def double_a_number (number_to_be_doubled): '' 'Numeron perusteella tämä palauttaa kaksinkertaisen määrän. Parametrit: number_to_be_doubled: kaksinkertaistettava luku Palautusarvo: Kaksinkertaistettu luku. '' 'palauta numero_to_be_doubled * 2  

ja kerro sitten jos luulet kenenkään olevan helpompi ymmärtää kuin:

  def double (x): palauta 2 * x  

Ole myös varovainen, ettet pudota klassiseen ansaan, joka vaikuttaa kokemattomiin (ja valitettavasti jopa moniin kokeneisiin) kehittäjiin asettamalla orjalainen omistautuminen sääntöihin ennen niiden sääntöjen luettavuutta heidän piti mainostaa. Epäyhtenäiset muuttujien nimet ja vastaavat eivät välttämättä ole ongelma (lukuun ottamatta sitä, joka kirjoittaa lint -määritystiedostosi), jos keskityt kommunikointiin muiden kehittäjien kanssa mielivaltaisten sääntöjen täyttämisen sijaan.

Ja viimeinen henkilökohtainen neuvoni, koska mainitset käskyt, muista aina, että kommentti on vain siellä, koska et voinut kirjoittaa tarpeeksi selkeää koodia. Jos mielestäsi funktio tarvitsee komentosarjan, tarkista ensin, etkö pysty parantamaan funktion nimeä, vaihtamaan sijaintiparametreja nimettyihin parametreihin tai käyttämään muita tekniikoita koodin tilan selkeyttämiseksi, mistä siinä on kyse. (Ja jos joku käskee sinua joka tapauksessa laittaa käskyt, viittaa heidät yllä olevaan esimerkkiin.)

Kuinka varovainen sinun pitäisi olla käytännöllinen valinta.

Tieteenalojen tarkoitus on auttaa sinua kirjoittamaan työkoodi (jota voit jatkaa työskentelyä ja laajentamista).

Tämä ei ole akateeminen harjoitus (Ehkä tämä on väärä foorumi kommentin tekemiseen). Hyvien käytäntöjen valitsemisesta ei ole "pisteitä" (ehkä ympäristössäsi on niitä ).

Hyvät käytännöt ovat ansaittuja opetuksia ohjelmointikäytäntöjen yhteisestä toiminnasta. Ympäristössä, jossa monet ohjelmoijat työskentelevät yhteistyössä koodin kanssa, jota ylläpidetään usein pidempään kuin koskaan odotettiin, ne auttavat rajoittamaan tarvittavaa sekaannusta ja uudelleen työskentelyä.

Kuulostaa siltä, ​​että olet hyvin mukana tavalla.

Jos olet lähellä ohjelmoijan matkan alkua, suosittelen, että tutkit "KUIVA", "YAGNI" ja "KIINTEÄ" merkitykset. Ja mainitsen erikseen yksikötestauksen.

Oman kokemukseni mukaan yksikkötestaus:

• auttaa sinua dokumentoimaan mitä sinua tarkoitettu koodi tekemään istuessasi alas kirjoittamaan sitä, ja sen avulla voit tarkistaa, että se tekee sitä edelleen, vaikka tekisitkin muutama ilmeisesti täysin toisistaan ​​riippumaton muutaman kilometrin päässä koodissasi, kuukausia myöhemmin. Sisältää pieniä yksityiskohtia, kuten mitään ei ilmoiteta tyhjäksi tai mitään ei ilmoiteta tyhjänä merkkijonona .
• välähtää väärinkäsitykset ensisijaisesta kielestäsi tai siihen liittyvät viitekehykset ja kirjastot, jotka olet vain katsonut dokumentaatioon ennen hyväksymistä. Nämä väärinkäsitykset aiheuttavat aikaa vievää virheenkorjausta, jos sinun on selvitettävä ne virheenkorjaamalla kuluttaja väärin käyttöönotetusta koodistasi.
• kannustaa sinua kirjoittamaan asianmukaisesti rakeista koodia: se on niin haitallista kirjoittaa yksikötestit koodille, joka yrittää puristaa liikaa toimintaa kuhunkin rutiiniin (menetelmä, alaohjelma jne.).
• on parasta aloittaa ennen koodin luomista, jonka se myöhemmin testaa. Tämä voi auttaa sinua keskittymään selkeämmin siihen, mitä koodisi pitäisi toimittaa.
• Saa selville sinulle varhaisessa vaiheessa, kun varhainen koodisuunnittelusi on heitettävä pois. Tämä estää sinua sotkemasta väärällä suunnittelulla, johon olet jo investoinut liikaa voidaksesi heittää pois. Kyse on toimivan koodin luomisesta, ei ensimmäisen yleissuunnitelman vahvistamisesta.

Luulen, että pääkysymykseen, "milloin koodi on tarpeeksi hyvä?", vastaus on yksinkertainen: kun se tekee mitä haluat, ja voit olla varma, että sen antama vastaus on oikea.

Koodin tekemiseen on kuitenkin ehdottomasti kompromissi. Minulle se tulee esiin kahdessa paikassa:

1. Entä jos haluat kuuden kuukauden kuluttua palata tutkimustuloksiin ja nähdä, pystytkö keksimään joitain parannuksia tai oletko löytänyt umpikujasta, joten tulet takaisin katsomaan, pystytkö saamaan työn päätökseen. Voitko lukea kuuden kuukauden takaisen koodisi ja jatkaa sen muokkaamista? Vai onko liian sekava seurata ja käyttää? Ihannetapauksessa sinun pitäisi pystyä palaamaan koodiisi vuoden kuluttua ja ymmärtämään helposti tekemäsi.
2. Tutkimustasi ei ole kuplassa. Seuraava tutkimushankkeesi liittyy todennäköisesti jonkin verran edelliseen. Voiko koodiasi käyttää uudelleen? Voidaanko sen osia käyttää uudelleen? Vaikka nykyisessä projektissasi olisi vain vähän etuja koodin tekemiseen mukavaksi ja modulaariseksi, voit säästää itsellesi paljon aikaa ja vaivaa rivillä, jos teet tämän. Tärkeät toiminnot ja algoritmit voidaan sitten siirtää uuteen asetukseesi pienellä mukautuksella. Haittapuolena on, että voit korvata tietyt koodinpätkät vaihtoehtoisilla toteutuksilla nähdäksesi, saatko parempia tuloksia.

Sanot:

Kirjoittamaani koodia käytetään melkein aina vain itse

Kuten muutkin, en jaa tätä mielipidettä. Koodin on TAKUU käyttää vähintään kaksi ihmistä:

1. Sinä
2. Sinä kolmen kuukauden kuluttua.

Hyvä sisäinen dokumentaatio ei vie niin kauan, ja säästää pitkällä aikavälillä aikaa ja vaivaa.

Kirjoittamaani koodia käytän melkein aina vain itse.

Tämä kommentti näyttää olevan hieman harhaanjohtava, ja minun pitäisi sanoa tämä sanomalla, että kirjoitan itse paljon tutkimuskoodia nimellä hyvin. Syy siihen, miksi mielestäni tämä väite on väärä, johtuu siitä, että koodia käytetään jollekin (esim. Valmistellaan tietoja analyyseja, analyyseja, mallinnuksia jne. Varten) ja se vaikuttaa viime kädessä kaikkiin valmistamiinne käsikirjoituksiin. . Sinänsä sen varmistaminen, että koodi on muiden luettavissa, on osa sen varmistamista, että työsi voidaan toistaa myös muilla. Lisäksi, jos koodisi ratkaisee ongelman, joka muilla on (melko yleinen myös tutkimuksessa!), Toiset voivat osittain käyttää sitä omassa tutkimuksessaan.

Tästä huolimatta käytännössä se on mahdollista kirjoittaa melko luettavaa koodia ensimmäisellä kerralla ja vaatii vain vähän kuria. Jotkut IDE: t pakottavat tämän sinulle tarkistamalla muuttujien nimet (esim. Ovatko ne CamelCase-yhteensopivia?), Funktioiden nimet, toimintojen pituuden, yksikötestien peiton ja niin edelleen. Tämä on yleensä paljon, koska on epätavallista, että ihmiset palaavat takaisin ja viettävät paljon aikaa koodin parantamiseen - kun sinulla on tulokset, puolueellisuus pyrkii siirtymään seuraavaan projektiin.

Joten loppujen lopuksi sinun on yritettävä kirjoittaa koodi, joka on tarpeeksi hyvä jakamaan muiden kanssa ensimmäistä kertaa. Et voi koskaan tietää, milloin arvostelija voi pyytää asiaankuuluvaa lähdekoodia.