Kääntäjän esipuhe: Tämän artikkelin luettuasi saatat olla yllättynyt tai jopa vihainen. Kyllä, mekin yllätyimme: kirjoittaja ei ilmeisesti ollut koskaan kuullutkaan tiimin hierarkiasta, tehtävien asettamisesta status "tee se nopeasti ja ilman perusteluja". Kyllä, aivan oikein, tämä on vähän outoa tekstiä. Kirjoittaja todellakin ehdottaa, että ohjelmoija ottaisi järjestelmäarkkitehdin roolin - miksi sitten tarvitset arkkitehdin? Mutta kaikkien näiden vastaväitteiden ei pitäisi sokeuttaa sinua pääasialle - miksi otimme ja käänsimme tämän tekstin. Hän ei puhu rooleista. Tämä teksti kertoo ammattimaisesta lähestymistavasta ja tietoisuudesta. Totuus on, että niin kauan kuin teet vain mitä käsketään ajattelematta tekojesi merkitystä, sinusta ei koskaan tule suurta ohjelmoijaa.
Sano ei tarpeettomalle koodille. Sinun tarvitsee vain laittaa kolme kirjainta yhteen ja sanoa sana. Yritetään tehdä tämä yhdessä: "Nooooo!"
Mutta odota. Miksi teemme näin? Loppujen lopuksi ohjelmoijan päätehtävä on kirjoittaa koodia. Mutta tarvitseeko sinun kirjoittaa koodia, jota sinulta pyydetään? Ei! "Ymmärtäminen milloin ei saa kirjoittaa koodia on luultavasti ohjelmoijan tärkein taito." .
Muistutamme sinua: kaikille "Habrin" lukijoille - 10 000 ruplan alennus ilmoittautuessaan mille tahansa Skillbox-kurssille "Habr" -tarjouskoodilla.
Skillbox suosittelee: Käytännön kurssi .
Ohjelmointi on ongelmanratkaisun taidetta. Ja olette tämän taiteen mestareita.
Joskus pyrkiessämme aloittamaan työn mahdollisimman nopeasti, emme ajattele muuta kuin käsillä olevan tehtävän suorittamista. Ja tämä voi aiheuttaa vielä vakavampia ongelmia.
Mitä ohjelmoijat sulkevat silmänsä?
Kaiken kirjoittamasi koodin on oltava muiden kehittäjien ymmärrettävissä, ja se on testattava ja korjattava.
Mutta siinä on ongelma: mitä tahansa kirjoitat, se monimutkaistaa ohjelmistoasi ja todennäköisesti tuo mukanaan bugeja tulevaisuudessa.
Rich Skrentin mukaan . Tässä on mitä hän kirjoittaa:
”Koodi on huono, koska se alkaa mätää ja vaatii jatkuvaa huoltoa. Uusien ominaisuuksien lisääminen vaatii usein vanhan koodin muokkaamista. Mitä suurempi se on, sitä suurempi on virheen todennäköisyys ja sitä enemmän aikaa sen kääntämiseen kuluu. Toiselta kehittäjältä kuluu enemmän aikaa selvittää se. Ja jos refaktorointia tarvitaan, niin varmasti tulee fragmentteja, jotka kannattaa vaihtaa. Suuri koodi tarkoittaa usein projektin joustavuuden ja toimivuuden vähenemistä. Yksinkertainen ja tyylikäs ratkaisu on nopeampi kuin monimutkainen koodi."
Mistä tiedät, milloin koodia ei saa kirjoittaa?
Ongelmana on, että ohjelmoijat liioittelevat usein sovellusten tarvitsemien ominaisuuksien määrää. Tämän seurauksena monet koodin osat jäävät kesken tai kukaan ei käytä niitä, mutta ne vaikeuttavat sovellusta.
Sinun on ymmärrettävä selvästi, mitä projektisi tarvitsee ja mitä se ei.
Esimerkki on sovellus, joka ratkaisee vain yhden tehtävän - sähköpostin hallinnan. Tätä tarkoitusta varten on otettu käyttöön kaksi toimintoa - kirjeiden lähettäminen ja vastaanottaminen. Sinun ei pitäisi odottaa, että sähköpostin hallinnasta tulee samanaikaisesti tehtävänhallinta.
Sinun on sanottava lujasti "ei" ehdotuksille sellaisten ominaisuuksien lisäämiseksi, jotka eivät liity sovelluksen päätehtävään. Juuri tällä hetkellä käy selväksi, että lisäkoodia ei tarvita.
Älä koskaan menetä sovelluksesi keskittymistä.
Kysy aina itseltäsi:
– Mikä toiminto nyt pitäisi ottaa käyttöön?
- Mikä koodi minun pitäisi kirjoittaa?
Kyseenalaista mieleen tulevat ideat ja arvioi ulkopuolelta tulevia ehdotuksia. Muuten ylimääräinen koodi voi yksinkertaisesti tappaa projektin.
Kun tiedät, milloin ei saa lisätä tarpeettomia asioita, voit pitää koodipohjasi tiukasti hallinnassa.
Aivan polun alussa ohjelmoijalla on vain kaksi tai kolme lähdetiedostoa. Se on yksinkertaista. Sovelluksen kääntäminen ja käynnistäminen vie vähän aikaa; Aina on selvää, mistä ja mitä etsiä.
Sovelluksen laajentuessa näkyviin tulee yhä enemmän kooditiedostoja. Ne täyttävät luettelon, jokaisella on satoja rivejä. Jotta voit järjestää kaiken tämän oikein, sinun on luotava lisää hakemistoja. Samalla on yhä vaikeampaa muistaa, mitkä toiminnot ovat vastuussa mistä ja mitkä toimet aiheuttavat niitä; bugien pyydystäminen vie myös enemmän aikaa. Projektinhallinta on myös tulossa monimutkaisemmaksi; ei yhden, vaan usean kehittäjän ei tarvitse seurata kaikkea. Näin ollen sekä rahalliset että aikakustannukset kasvavat ja kehitysprosessi hidastuu.
Projektista tulee lopulta valtava, ja jokaisen uuden ominaisuuden lisääminen vaatii yhä enemmän vaivaa. Jopa hyvin merkityksettömään asiaan joutuu viettämään useita tunteja. Olemassa olevien virheiden korjaaminen johtaa uusien syntymiseen ja hakemusten julkaisun määräajat ylitetään.
Nyt meidän on taisteltava projektin kestosta. Miksi?
Tosiasia on, että et yksinkertaisesti ymmärtänyt, milloin sinun ei pitäisi lisätä ylimääräistä koodia, ja vastasit "kyllä" jokaiseen ehdotukseen ja ideaan. Olit sokea, halu luoda uusia asioita sai sinut jättämään huomiotta tärkeät tosiasiat.
Kuulostaa kauhuelokuvan käsikirjoitukselta, eikö?
Juuri näin tapahtuu, jos jatkat kyllä. Yritä ymmärtää, milloin koodia ei pitäisi lisätä. Poista tarpeettomat asiat projektista - tämä helpottaa elämääsi paljon ja pidentää sovelluksen käyttöikää.
"Yksi tuottavimmista päivistäni oli, kun poistin 1000 koodiriviä."
- Ken Thompson.
On vaikeaa oppia, milloin koodia ei saa kirjoittaa. Mutta se on välttämätöntä.
Kyllä, tiedän, että olet juuri aloittanut kehittäjän polun ja haluat kirjoittaa koodia. Se on hyvä, älä menetä ensivaikutelmaa, mutta älä unohda tärkeitä tekijöitä innostuksen vuoksi. Ymmärsimme kaiken yrityksen ja erehdyksen kautta. Teet myös virheitä ja opit niistä. Mutta jos voit oppia edellä mainitusta, työstäsi tulee tietoisempaa.
Jatka luomista, mutta tiedä milloin sanoa ei.
Skillbox suosittelee:
- Sovellettu verkkokurssi .
- Verkkokurssi .
- Käytännön vuoden kurssi .
Lähde: will.com