Tõlkija eessõna: Pärast selle artikli lugemist võite olla üllatunud või isegi vihane. Jah, ka meie olime üllatunud: väidetavalt polnud autor kuulnudki meeskonna hierarhiast, ülesannete püstitamisest staatusega "tee seda kiiresti ja ilma põhjendusteta". Jah, see on õige, see on natuke kummaline tekst. Tõepoolest, autor soovitab programmeerijal võtta endale süsteemiarhitekti roll – milleks siis arhitekti vaja? Kuid kõik need vastuväited ei tohiks teid pimestada peamise suhtes - miks me selle teksti siiski võtsime ja tõlkisime. Ta ei räägi rollidest. See tekst räägib professionaalsest lähenemisest ja teadlikkusest. Tõde on see, et seni, kuni teete lihtsalt seda, mida kästakse, mõtlemata oma tegude tähendusele, ei saa teist kunagi suurt programmeerijat.
Ütle ei tarbetule koodile. Kõik, mida pead tegema, on kolm tähte kokku panna ja sõna öelda. Proovime seda koos teha: "Nooooo!"
Aga oota. Miks me seda teeme? Programmeerija põhiülesanne on ju koodi kirjutamine. Kuid kas peate kirjutama koodi, mida teilt küsitakse? Ei! "Arusaamine, millal koodi mitte kirjutada, on programmeerija jaoks ilmselt kõige olulisem oskus." .
Tuletame meelde: kõigile "Habr" lugejatele - allahindlus 10 000 rubla, kui registreerute mis tahes Skillboxi kursusele, kasutades sooduskoodi "Habr".
Skillbox soovitab: Praktiline kursus .
Programmeerimine on probleemide lahendamise kunst. Ja te olete selle kunsti meistrid.
Mõnikord, püüdes tööd võimalikult kiiresti alustada, ei mõtle me millelegi muule kui ülesande täitmisele. Ja see võib põhjustada veelgi tõsisemaid probleeme.
Mille ees programmeerijad silma kinni pigistavad?
Kogu teie kirjutatud kood peab olema teistele arendajatele arusaadav ning seda tuleb testida ja siluda.
Kuid on probleem: mida iganes te kirjutate, muudab see teie tarkvara keerulisemaks ja toob tulevikus tõenäoliselt kaasa vigu.
Rich Skrenti sõnul . Siin on see, mida ta kirjutab:
«Kood on halb, sest hakkab mädanema ja nõuab pidevat hooldust. Uute funktsioonide lisamine nõuab sageli vana koodi muutmist. Mida suurem see on, seda suurem on vea tekkimise tõenäosus ja seda rohkem aega kulub kompileerimiseks. Selle väljaselgitamiseks kulub teisel arendajal rohkem aega. Ja kui on vaja refaktoreerimist, siis kindlasti tuleb killukesi, mida tasub muuta. Suur kood tähendab sageli projekti paindlikkuse ja funktsionaalsuse vähenemist. Lihtne ja elegantne lahendus on kiirem kui keeruline kood.
Kuidas sa tead, millal koodi mitte kirjutada?
Probleem on selles, et programmeerijad liialdavad sageli funktsioonide arvuga, mida nende rakendus vajab. Selle tulemusena jäävad paljud koodilõigud pooleli või ei kasuta neid keegi, kuid need muudavad rakenduse keerulisemaks.
Peate selgelt aru saama, mida teie projekt vajab ja mida mitte.
Näitena võib tuua rakenduse, mis lahendab vaid ühe ülesande – meilihalduse. Selleks on kasutusele võetud kaks funktsiooni – kirjade saatmine ja vastuvõtmine. Te ei tohiks eeldada, et meilihaldur muutub samal ajal tegumihalduriks.
Peate kindlalt ütlema "ei" ettepanekutele lisada funktsioone, mis ei ole seotud rakenduse põhiülesandega. Just sel hetkel saab selgeks, et lisakoodi pole vaja.
Ärge kunagi kaotage oma rakenduse fookust.
Küsige endalt alati:
— Millist funktsiooni tuleks praegu rakendada?
— Mis koodi ma peaksin kirjutama?
Küsige pähe tulevatest ideedest ja hinnake väljastpoolt tulevaid ettepanekuid. Vastasel juhul võib lisakood projekti lihtsalt tappa.
Teadmine, millal mittevajalikke asju lisada, aitab teil oma koodibaasi kindla kontrolli all hoida.
Päris tee alguses on programmeerijal ainult kaks või kolm lähtefaili. See on lihtne. Rakenduse koostamine ja käivitamine võtab minimaalselt aega; Alati on selge, kust ja mida otsida.
Rakenduse laienedes ilmub üha rohkem koodifaile. Nad täidavad kataloogi, millest igaühel on sadu ridu. Selle kõige õigeks korraldamiseks peate looma täiendavaid katalooge. Samal ajal muutub üha raskemaks meeles pidada, millised funktsioonid mille eest vastutavad ja millised tegevused neid põhjustavad; ka putukate püüdmine võtab rohkem aega. Ka projektijuhtimine muutub keerukamaks, mitte üks, vaid mitu arendajat ei pea kõike jälgima. Sellest tulenevalt suurenevad nii rahalised kui ka ajalised kulud ning arendusprotsess aeglustub.
Projekt muutub lõpuks tohutuks ja iga uue funktsiooni lisamine nõuab üha rohkem pingutusi. Isegi millegi väga ebaolulise peale tuleb kulutada mitu tundi. Olemasolevate vigade parandamine toob kaasa uute ilmnemise ja taotluste avaldamise tähtajad jäävad mööda.
Nüüd tuleb projekti eluea eest võidelda. Miks?
Fakt on see, et sa lihtsalt ei saanud aru, millal ei tohiks lisakoodi lisada, ning vastasid igale ettepanekule ja ideele “jah”. Olite pime, soov luua uusi asju pani teid olulisi fakte ignoreerima.
Kõlab nagu õudusfilmi stsenaarium, eks?
Täpselt nii juhtub, kui ütlete jätkuvalt jah. Proovige aru saada, millal koodi ei tohiks lisada. Eemaldage projektist mittevajalikud asjad – see muudab teie elu palju lihtsamaks ja pikendab rakenduse eluiga.
"Üks mu produktiivsemaid päevi oli siis, kui kustutasin 1000 koodirida."
- Ken Thompson.
On raske õppida, millal koodi mitte kirjutada. Aga see on vajalik.
Jah, ma tean, et olete just asunud arendaja teele ja soovite koodi kirjutada. See on hea, ärge kaotage seda esmamuljet, kuid ärge unustage entusiasmi tõttu olulisi tegureid. Saime kõigest aru katse-eksituse meetodil. Samuti teete vigu ja õpite neist. Aga kui suudad ülaltoodust õppida, muutub sinu töö teadlikumaks.
Jätkake loomist, kuid tea, millal öelda ei.
Skillbox soovitab:
- Rakendatud veebikursus .
- Veebikursus .
- Praktilise aasta kursus .
Allikas: www.habr.com