Pahoja tapoja on vaikea katkaista, ja vielä vaikeampaa on, jos et tajua, että se, mitä teet, heikentää työtäsi. Jos tiedät, mutta et välitä – se olisi pahinta. Mutta olet täällä, etkö olekin?
Ohjelmoijana olen nähnyt paljon huonoja käytäntöjä, ei vain koodin, vaan myös tiimityöskentelytaitojen ympärillä. Olen itsekin syyllistynyt monien näiden huonojen tapojen harjoittamiseen. Seuraavassa on 35 tärkeintä huonoa ohjelmointitapaani, jotka on jaoteltu neljään kategoriaan: koodin organisointi, tiimityö, koodin kirjoittaminen sekä testaus ja ylläpito.
Koodin organisointi
1. Sanomalla: ”Korjaan sen myöhemmin”
Tapa lykätä koodin korjauksia ei ole pelkkä prioriteettiongelma. Ongelmanseurannan järjestäminen saattaa tuottaa jonkin verran edistystä, mutta tarvitset myös keinon seurata esiin tulevia pienempiä ongelmia. ”TODO”-kommenttien lisääminen on nopea tapa varmistaa, ettet jätä mitään huomaamatta.
2. Yhden rivin ratkaisun vaatiminen
Tehokkaiden, tyylikkäiden koodinpätkien kirjoittamisen pakkomielteisyys on ohjelmoijien yleinen piirre. Se on kuin palapelin ratkaiseminen – löydät funktioiden ja säännöllisten lausekkeiden yhdistelmän, joka muuttaa 20 koodiriviä kahdeksi tai kolmeksi. Valitettavasti se ei aina johda luettavaan koodiin, ja se on yleensä paljon tärkeämpi tulos. Tee koodistasi ensin helppolukuista ja vasta sitten fiksua.
3. Turhien optimointien tekeminen
Toinen paikka, johon usein panostamme väärin, ovat optimoinnit. Kuulostaa hienolta pienentää sivustosi kokoa muutamalla tavulla, mutta eikö gzip korvaa sen joka tapauksessa? Ja eikö pyynnöt ole tärkeämpiä? Käsittele optimointeja projektin loppuvaiheessa, sillä useimmiten vaatimukset muuttuvat, ja aikasi on mennyt hukkaan.
”Ennenaikainen optimointi on kaiken pahan alku ja juuri.”
-Donald Knuth
4. Vakuuttelet itsellesi, että tyylikysymykset eivät ole niin tärkeitä
Jos olen oppinut jotain vuosien varrella katsellessani muiden ihmisten koodia, niin sen, että koodaustyyliin liittyvien kysymysten käsittely on asia, jota kehittäjät todennäköisimmin lykkäävät. Ehkä kokemattomien koodaajien on vaikea nähdä, mitä hyvää tyylikysymysten käsittelemisestä seuraa, mutta ajan myötä käy selväksi, että kun koodin laatu suistuu raiteiltaan, lumipalloefekti muuttaa minkä tahansa projektin täydelliseksi sotkuksi. Noudata tiukasti parhaita käytäntöjä, vaikka ne tuntuisivatkin vähäpätöisiltä. Ota käyttöön koodintarkistus- ja linting-työkalut, jotta voit antaa itsellesi tilaa huolehtia tärkeämmistä asioista.
5. Ota koodintarkistus- ja linting-työkalut käyttöön, jotta voit huolehtia tärkeämmistä asioista. Asioiden lakaise maton alle
Joko pyydystämällä ja jättämällä huomiotta poikkeuksia tai käyttämällä kirjastoja, jotka eivät ilmoita virheistä (kuten jQuery), on monia tapoja lakaista asioita maton alle. Mutta kun jostain virheestä tulee prioriteetti, sen korjaamisen haaste on moninkertainen ottaen huomioon, ettei sinulla ole aavistustakaan, mistä aloittaa. Helppo tapa välttää tämä on kirjata nuo huomiotta jätetyt virheet lokiin, jotta voit tutkia niitä myöhemmin.
6. HUOM! Nimien käyttäminen, jotka eivät lisää informaatiota
Nimeäminen on vaikeaa, mutta on olemassa helppo tapa varmistaa, että muuttujien ja funktioiden nimet ovat vähintäänkin kunnollista laatua. Kunhan nimet lisäävät jonkinlaista tietoa, jota muu koodi ei välitä, muiden kehittäjien on helpompi lukea koodiasi. Nimeäminen on niin tärkeää siksi, että nimet voivat antaa yleisen käsityksen siitä, mitä koodi tekee. Vie enemmän aikaa, jos joudut kaivautumaan laskelmiin selvittääksesi, mitä koodinpätkä tekee, mutta hyvä nimi voi auttaa sinua ymmärtämään sekunneissa, mitä koodi tekee.
7. Todistettujen parhaiden käytäntöjen huomiotta jättäminen
Koodikatselmukset, testivetoinen kehitys, laadunvarmistus, käyttöönoton automatisointi – nämä käytännöt ja useat muut käytännöt ovat osoittaneet hyödyllisyytensä lukemattomissa projekteissa, minkä vuoksi kehittäjät bloggaavat niistä jatkuvasti. Näiden parhaiden käytäntöjen hyvä hakuteos on kirja Making Software: What Really Works, and Why We Believe It. Ota aikaa opetella, miten ne tehdään oikein, ja kehitysprosessisi paranee kaikissa projekteissasi tavoilla, jotka yllättävät sinut.
Tiimityö
8. Ryhmätyöskentely
. Suunnitelmista luopuminen liian aikaisin
Varma tapa tehdä järjestelmästäsi käsittämätön on olla sitoutumatta suunnitelmaan. Voit aina, kun koodiasi arvostellaan, sanoa, että suunnitelma ei ole valmis. Puolivalmiiden moduulien olemassaolo johtaa kuitenkin tiukasti kytkettyyn koodiin heti, kun yrität saada nämä keskeneräiset moduulit toimimaan keskenään. Tällainen komplikaatio tulee esiin myös silloin, kun projektin johtajaroolit vaihtuvat ja uudet johtajat päättävät, että heidän tapansa on tärkeämpi kuin arkkitehtuurin johdonmukaisuus.
9. Pitäytyminen suunnitelmassa, jolla ei ole juurikaan mahdollisuuksia toimia
Niin kuin suunnitelmista luopuminen voi aiheuttaa ongelmia, niin voi myös pitäytyminen suunnitelmassa, joka ei toimi. Siksi sinun pitäisi jakaa ideasi tiimisi kanssa saadaksesi palautetta ja neuvoja, kun asiat muuttuvat hankaliksi. Joskus erilainen näkökulma voi olla ratkaiseva.
10. Työskentelet koko ajan yksin
Sinun tulisi pyrkiä jakamaan edistyksesi ja ideasi tiimin kanssa. Joskus luulet rakentavasi jotain oikein, mutta et olekaan, joten jatkuva kommunikointi on erittäin arvokasta. Siitä on hyötyä myös muille ihmisille, kun työskentelet heidän kanssaan. Heidän työnsä usein paranee, kun keskustelet heidän kanssaan ideoista ja ohjaat tiimisi vähemmän kokeneita jäseniä, jotka jäävät todennäköisemmin jumiin.
11. Muuta. Kieltäydyt kirjoittamasta huonoa koodia
Jokaisen kehittäjän elämässä tulee aika, jolloin määräajat pakottavat sinut kirjoittamaan kauheaa koodia, ja se on ihan ok. Olet yrittänyt varoittaa asiakastasi tai esimiestäsi seurauksista, mutta he pitävät kiinni määräajasta, joten nyt on aika koodata. Tai ehkä sinulla on kiireellinen vika, joka ei voi odottaa, että keksit siistin ratkaisun. Siksi on tärkeää olla ohjelmoijana monipuolinen ja pystyä kirjoittamaan sekä huonoa että hyvää koodia hyvin nopeasti. Toivottavasti voit tarkastella koodia uudelleen ja maksaa teknisen velan takaisin.
12. JOHDANTO. Muiden syyttäminen
Ei ole mikään salaisuus, että ylimielisyys on aivan liian yleinen piirre kehittäjien ja muiden teknisten ammattilaisten keskuudessa. Vastuun ottaminen virheistäsi on hyve, joka saa sinut loistamaan vertaistesi joukossa. Älä pelkää myöntää, että olet tehnyt virheen. Kun olet hyväksynyt sen, voit keskittyä oppimaan, miksi teit virheen ja miten voit välttää sen. Jos et myönnä virhettäsi, oppimisesta tulee mahdotonta.
13. Et jaa tiimisi kanssa, mitä olet oppinut
Arvosi kehittäjänä ei asetu vain kirjoittamallesi koodille, vaan myös sille, mitä opit sitä kirjoittaessasi. Jaa kokemuksiasi, kirjoita siitä kommentteja, kerro muille, miksi asiat ovat niin kuin ne ovat, ja auta heitä oppimaan uusia asioita projektista ja sen kiemuroista.
14. Jaa kokemuksiasi. Liian hidas palautteen antaminen esimiehille/asiakkaille
Yksi jokaisen käsityöläisen arvokkaimmista luonteenpiirteistä on varmistaa, että kaikki ovat mahdollisimman pitkälti samoilla linjoilla työn suhteen. Syy tähän ei ole se, että esimiehesi voi täyttää taulukoita. Se on myös oman etusi vuoksi: Sinulla on vähemmän epävarmuustekijöitä ja epävarmuus projektin elinkaaresta ja tulevaisuudesta vähenee.
15. Googlea ei käytetä tarpeeksi
Paras tapa ratkaista monimutkainen ongelma nopeasti on olla ratkaisematta sitä lainkaan. Kun olet epävarma, googlaa se. Voit tietysti sen sijaan vaivata vieressäsi olevaa insinööriä, mutta harvoin hän pystyy antamaan yhtä yksityiskohtaisen vastauksen kuin Stack Overflow, puhumattakaan siitä, että keskeytät myös hänen työnsä.
16. Kuka tietää? Henkilökohtaisen tyylisi yliarvostaminen
Pyrki aina sovittamaan työskentelytyylisi ja ympäristöasetelmasi yhteen tiimisi kanssa. Ihannetapauksessa kaikkien tiimisi jäsenten tulisi työskennellä samanlaisissa olosuhteissa ja noudattaa samaa koodaustyyliä. Asioiden tekeminen omalla tavallasi voi olla hauskempaa, mutta työtoverit eivät ehkä ole tottuneet koodaustyyliisi, ja jos se on epätavallinen, seuraavan kehittäjän on vaikeampi työskennellä sen parissa, mitä sinä olet rakentanut.
17. Tehdä asioita omalla tavallasi. Henkilökohtainen kiintymys koodiisi
Kun joku kommentoi koodiasi, älä ota sitä henkilökohtaisesti. Koodisi pitäisi seisoa vankalla pohjalla, eli sinun pitäisi pystyä selittämään, miksi kirjoitit sen juuri sillä tavalla. Jos siinä on parantamisen varaa, se kertoo vain koodin oikeellisuudesta, ei sinusta itsestäsi.
Koodin kirjoittaminen
18. Ei osata optimoida
Hyvä optimointistrategia vaatii jonkin verran kokemusta. Se vaatii tutkimista, analysointia ja jokaisen prosessiin osallistuvan järjestelmän tuntemista. Informoi itseäsi näistä asioista. Opi algoritmien monimutkaisuudesta, tietokantakyselyjen arvioinnista, protokollista ja siitä, miten suorituskykyä yleensä mitataan.
19. Ota selvää algoritmien monimutkaisuudesta. Väärän työkalun käyttäminen työhön
Voit tietää vain niin paljon, mutta syy siihen, miksi sinun on jatkettava oppimista, on se, että jokainen uusi ongelma tuo mukanaan erilaisen asiayhteyden ja vaatii erilaisen työkalun – sellaisen, joka soveltuu paremmin kyseiseen tehtävään. Ole avoin uusille kirjastoille ja kielille. Älä tee päätöksiä tiukasti sen perusteella, mitä tiedät.
20. Älä vaivaudu hallitsemaan työkalujasi ja IDE:täsi
Jokainen uusi pikanäppäin, pikanäppäin tai parametri, jonka opit käyttäessäsi työkaluja, joiden kanssa työskentelet päivittäin, vaikuttaa koodausnopeuteesi myönteisemmin kuin uskotkaan. Kyse ei ole siitä, että säästät muutaman sekunnin käyttämällä pikanäppäintä; kyse on kontekstin vaihtamisen vähentämisestä. Mitä enemmän aikaa käytät jokaiseen pieneen toimenpiteeseen, sitä vähemmän aikaa sinulla on aikaa miettiä, miksi teet sen ja mitä seuraavaksi tulee. Pikanäppäinten hallitseminen vapauttaa mielesi.
21. Virheilmoitusten huomiotta jättäminen
Älä oleta, että tiedät mikä koodissasi on vialla lukematta edes virheilmoitusta tai että saat sen selville riittävän nopeasti. Ongelmasta on aina parempi saada enemmän tietoa, ja jos käytät aikaa tuon tiedon keräämiseen, säästät pitkällä aikavälillä enemmän aikaa.
22. Kehittäjän työkalupakin romantisointi
Joskus suosikkieditorisi tai komentorivityökalusi ei olekaan paras työkalu käsillä olevaan työhön. Visual Studio on loistava IDE-kirjoittamiseen, Sublime on loistava dynaamisille kielille, Eclipse on loistava Javalle ja niin edelleen. Saatat rakastaa vimiä tai emacsia, mutta se ei tarkoita, että se on oikea työkalu jokaiseen työhön.
23. Arvojen kovakoodaaminen sen sijaan, että niistä tehtäisiin konfiguroitavissa olevia
Ole aina miettimässä, mitä muutoksia voi tulla ja miten käsitellä niitä. Tekninen velka kasvaa hirvittävää vauhtia, jos et erota liikkuvia osia muusta työstäsi. Käytä tarvittaessa vakioita ja konfiguraatiotiedostoja.
24. Pyörän keksiminen uudelleen koko ajan
Älä kirjoita koodia, jota ei tarvitse. Ehkä joku muu on jo käyttänyt paljon aikaa ongelmasi ratkaisemiseen, ja hänellä saattaa olla hyvin testattu ratkaisu, jota voit käyttää uudelleen. Säästä itsesi vaivalta.
25. Koodin sokea kopiointi/liittäminen
Tutustu koodiin ennen kuin käytät sitä uudelleen. Joskus et heti ensisilmäyksellä huomaa kaikkea, mitä koodi tekee. Opit myös enemmän ongelmasta, kun käytät aikaa lukeaksesi koodin yksityiskohtaisesti.
26. Lue koodi uudelleen. Et käytä aikaa oppiaksesi, miten asiat todella toimivat
Hyödynnä aina tilaisuutta laajentaa tietämystäsi miettimällä, miten asiat toimivat, ja lukemalla niiden taustalla olevista ongelmista. Saatat säästää aikaa jättämällä vaivaamatta juuri nyt, mutta se, mitä opit jostakin projektista, on pitkällä aikavälillä tärkeämpää kuin se, että saat sen todella tehtyä.
27. Liiallinen luottamus omaan koodiin
On vaarallista olettaa, että vain siksi, että olet kirjoittanut jotain, sen täytyy olla loistava. Opit lisää ohjelmoinnista, kun työstät uusia asioita ja saat kokemusta, joten vilkaise silloin tällöin vanhaa koodiasi ja pohdi, miten olet edistynyt.
28. Et ajattele kunkin suunnittelun, ratkaisun tai kirjaston kompromisseja
Jokaiseen tuotteeseen liittyy hienouksia, jotka opit tuntemaan vain käyttämällä ja analysoimalla sitä. Muutaman kirjaston käyttöesimerkin näkeminen ei tee sinusta sen mestaria, eikä se tarkoita, että se sopisi täydellisesti jokaiseen projektissasi eteen tulevaan tilanteeseen. Ole jatkuvasti kriittinen kaiken käyttämäsi suhteen.
29. Se, ettet hae apua, kun olet jumissa
Lyhyen palautesilmukan pitäminen on sinulle aina vähemmän tuskallista. Avun pyytäminen ei tarkoita, että olet epäpätevä. Oikeat ihmiset näkevät vaivannäkösi ja tietämättömyytesi myöntämisen pyrkimyksenä oppia, ja se on hieno hyve.
Testaaminen ja ylläpito
30. Jos et auta, et voi auttaa. Testien kirjoittaminen läpäiseviksi
Testien kirjoittaminen, joiden tiedät läpäisevän, on välttämätöntä. Ne tekevät refaktoroinnista ja projektin uudelleenjärjestelystä paljon turvallisempaa. Toisaalta on myös kirjoitettava testejä, joiden tietää menevän läpi. Ne ovat välttämättömiä, jotta projektia voidaan viedä eteenpäin ja jotta ongelmia voidaan seurata.
31. Suorituskykytestauksen huomiotta jättäminen kriittisissä tapauksissa
Valmistele automaattinen suorituskykytestausasetus suunnilleen projektin kehitysprosessin puolivälissä, jotta voit varmistaa, ettei suorituskykyongelmia ole eskaloitumassa.
32. Suorituskykytestauksen huomiotta jättäminen kriittisissä tapauksissa
. Et tarkista, että buildisi toimii
On harvinaista, että buildi menee läpi, mutta ei oikeasti toimi, mutta niin voi käydä, ja ongelman korjaaminen voi olla hankalaa, mitä kauemmin odotat sen tutkimista. Jokaisen buildin nopea testaaminen on tärkeä tapa.
33. Suurten muutosten työntäminen myöhään tai poistuminen suuren työntämisen jälkeen
Tässä kohtaa liiallinen itsevarmuus saa sinut kärsimään, ja voi vaatia useita kertoja kärsimään, ennen kuin opit, miksi sinun ei pitäisi tehdä näin, joten ota neuvoni nyt vastaan ja varmista, että olet aina paikalla, kun buildisi lopulta rikkoutuu.
34. Jos et ole valmis tekemään suuria muutoksia, älä tee niin. Kirjoittamasi koodin hylkääminen
Ole valmis tukemaan kirjoittamaasi koodia. Olet sopivin henkilö auttamaan muita ymmärtämään sitä. Sinun tulisi pyrkiä siihen, että koodisi pysyy luettavana itsellesi ja muille vielä vuosienkin kuluttua.
35. Muiden kuin toiminnallisten vaatimusten huomiotta jättäminen
Kun yrität toimittaa jotain, voi olla helppoa unohtaa joitakin tärkeitä osa-alueita, kuten suorituskyky ja tietoturva. Pidä tarkistuslistaa niitä varten. Et halua, että ne pilaavat juhlasi, koska laadit aikataulusi ajattelematta näitä ei-toiminnallisia huolenaiheita.
Mitkä ovat pahimmat ohjelmointitottumuksesi?
Kuten usein sanotaan, olemme tottumuksen luomia. Työskentelytapojen parantaminen tottumusten avulla on loistava tapa välttää se, että joutuu miettimään liikaa jokaista tilannetta. Kun olet omaksunut hyvän tavan tehdä jotain, siitä tulee vaivatonta.