Üks idiootsemaid ameteid on juhid, kes juhivad programmeerijaid. Mitte kõik, aga need, kes ise polnud programmeerijad. Need, kes arvavad, et raamatutest pärit meetoditega on võimalik efektiivsust “tõsta” (või “efektiivsust”?). Viitsimata neid samu raamatuid lugedagi, on video mustlaslik.
Need, kes pole kunagi koodi kirjutanud. Need, kellele tehakse Hollywoodi filme programmeerijatest – noh, need, kus nad vaatavad meili käsurealt kasutades. Neid, keda peale näitajate, tähtaegade ja enda palga miski muu ei huvita.
Need, kes on enamus.
Kuid nad on idioodid teisel põhjusel. Nad tahavad tõhusust või vähemalt tulemuslikkust (no kuule, juht, guugelda, mis vahe on), mõistmata ei üht ega teist. Arusaamata üldiselt olemust, tulemuse saamise protsessi, selles protsessis tekkivaid kadusid, arenduskulusid. Ühesõnaga, töötades programmeerijaga nagu oleks ta must kast.
Nad sattusid programmeerijate juhtkonda täpselt ühel põhjusel: seal on hype, raha, turg ja hunnik samu idioote. Eksimiseks on koht.
Kui mehhaanilise koostu tootmises oleks kära, jookseksime sinna. Universaalid on nõmedad. Ma ei imestaks, et meie naabruskonnas detsembris jõulukuuske müüv mees on puhkusel IT-juht.
Ühesõnaga, kui võimalik, siis tulistage neid tüüpe kuklasse. Ärge muretsege, nad leiavad töö. Ükski neist ei tee kunagi midagi korralikku enne, kui ta ise programmeerijaks saab. Sest ta ei mõista oma juhitava protsessi olemust, mehhanismi, loogikat.
Okei, piisab juhtidest. Nüüd asja juurde, programmeerijate jaoks. Kuidas tõsta arenduse efektiivsust, õppides kvaliteetset koodi kirjutama.
Tõhususe suurendamiseks tuleb probleeme kiiremini lahendada, ilma kvaliteeti kaotamata. Probleemide kiiremaks lahendamiseks tuleb osata kohe kvaliteetset koodi kirjutada. Ja “kvaliteetne”, “kirjuta” ja “kohe”. Lubage mul selgitada metafooriga.
Kvaliteetse koodi kirjutamine on nagu võõrkeele õige rääkimine. Kui te keelt ei oska, kulutate palju aega, püüdes selles oma mõtteid sõnastada.
Kui teil on vaja midagi kiiresti öelda, jääte lihtsalt mõnele sõnale, sageli mitte õigele, unustate artiklid, õige sõnajärje, rääkimata verbi aegadest ja kehvast hääldusest.
Kui teil on aega vastuse sõnastamiseks, peate avama sõnastiku või veebitõlgi ja kulutama palju aega oma mõtete sõnastamisele. Tunne jääb aga ikkagi ebameeldivaks: ütled vastuse ja ei tea, kas see on õige või mitte. Sama on koodiga – tundub, et see on kirjutatud, tundub, et see töötab, aga kas see on kvaliteetne või mitte, on mõistatus.
See osutub kahekordseks ajaraiskamiseks. Vastuse leidmine võtab aega. Ka selle vastuse sõnastamine võtab aega – ja mitte nii vähe.
Kui kvaliteetse koodi kirjutamise oskus on olemas, saab vastuse sõnastada kohe, niipea kui see on peas küpsenud, ilma tõlkimisele lisaaega kulutamata.
Kvaliteetse koodi kirjutamise oskus aitab arhitektuuri kujundamisel. Te lihtsalt ei kaalu oma peas valesid, teostamatuid või käsitsi tehtud valikuid.
Kokkuvõtteks: kvaliteetse koodi kirjutamise oskus kiirendab oluliselt probleemide lahendamist.
Kuid see pole veel kõik. Tänu viltsaabaste halduritele on üks konks – meil pole põhjust kvaliteetset koodi kirjutada. Haldur ei vaata koodi, klient ei vaata koodi. Näitame üksteisele koodi harva, ainult mõnikord, mõne projekti puhul, kus on määratud koodi "kontrollija" või perioodiline ümberkujundamine.
Selgub, et enamasti läheb nõme kood tootmisse või kliendile. Inimene, kes on kirjutanud nõmedat koodi, moodustab stabiilse närviühenduse - nõmedat koodi pole mitte ainult võimalik kirjutada, vaid see on ka vajalik - see on aktsepteeritud ja selle eest isegi makstakse.
Seetõttu pole kvaliteetse koodi kirjutamise oskusel üldse võimalust areneda. Tingimusliku töötaja kirjutatud koodi ei kontrolli kunagi keegi. Ainus põhjus, miks ta õpib normaalselt programmeerima, on sisemine motivatsioon.
Kuid see sisemine motivatsioon läheb vastuollu tõhususe ja tootlikkuse plaanide ja nõuetega. See vastuolu ei lahene selgelt kvaliteetse koodi kasuks, sest inimesed isegi ei kritiseeri inimesi nõmedate koodide pärast. Ja plaani täitmata jätmise eest – isegi nii.
Mida ma peaksin tegema? Ma näen ja pakun välja kaks teed, mida saab kombineerida.
Esimene on näidata oma koodi kellelegi ettevõtte sees. Mitte reaktiivselt (kui küsitakse/sunnitakse), vaid ennetavalt (uh, kutt, vaata palun mu koodi). Siin on peamine mitte postitada suhkrust tatti, mitte püüda koodi kriitikat viisakasse vormi panna. Kui kood on jama, siis ütleme nii: kood on jama. Muidugi koos selgitustega ja soovitustega, kuidas asja paremaks muuta.
Aga see tee on ka nii-nii. Selle rakendatavus sõltub kokkupuutepunktist. Kui töö on juba tootmisse läinud ja selgub, et kood on nõme, pole mõtet seda uuesti teha. Täpsemalt põhjused – ka mõõdikud lähevad longu. Juhid tormavad kohale ja purustavad teid tõhususnõuetega. Ja ärge isegi proovige neile selgitada, et nõme kood tuleb kindlasti vigade kujul tagasi – see annab teile tagasilöögi. Saate ainult lubada seda enam mitte teha.
Kui töö pole veel kohale jõudnud või on alles alanud, siis võib koodile (või selle projektile, ideele) jama kallamine olla üsna praktilise tähendusega - inimene teeb seda normaalselt.
Teine viis, kõige lahedam, on teha avatud lähtekoodiga arendust töövälisel ajal. Mis on eesmärk: et hulk programmeerijaid, nimelt programmeerijaid, näeksid teie koodi ja räägiksid sellest. Kõigil ettevõttes pole aega. Aga programmeerijatel üle maailma pole ikka veel midagi teha ja kui rakenduse seisukohalt midagi kasulikku kirjutada, siis nad vaatavad kindlasti sisse.
Peamine nipp on minu arvates töövälisel ajal koodi kirjutamine, sest vastuolu koodi kvaliteedi ja tulemuse edastamise kiiruse vahel ei toimi. Kirjutage oma areng vähemalt aasta jooksul. Sind ei survesta ei tähtajad, tehnilised näitajad, raha ega ülemus. Täielik vabadus ja loovus.
Ainult vabas loovuses mõistate ja tunnete, mis on suurepärane kood, näete keele ja tehnoloogia ilu ning tunnete äriülesannete võlu. Noh, sa õpid kirjutama kvaliteetset koodi.
Tõsi, see nõuab teilt isiklikku aega. Nagu iga teinegi areng. Vaadake seda mitte kui kulu, vaid kui investeeringut – iseendasse.
Allikas: www.habr.com