Ien fan 'e meast idioat-laden beroppen is managers dy't programmeurs beheare. Net allegear, mar dejingen dy't sels gjin programmeurs wiene. Dejingen dy't tinke dat it mooglik is om effisjinsje te "ferheegje" (of "effisjinsje" te fergrutsjen?) Mei metoaden út boeken. Sûnder sels de muoite om dizze deselde boeken te lêzen, is de fideo in sigeuner.
Dejingen dy't hawwe nea skreaun koade. Dejingen foar wa't Hollywood-films oer programmeurs wurde makke - goed, dejingen wêr't se e-post sjogge mei de kommandorigel. Dejingen dy't net ynteressearre binne yn wat oars as yndikatoaren, deadlines en har eigen salaris.
Dejingen dy't de mearderheid binne.
Mar se binne idioaten om in oare reden. Se wolle effisjinsje, of op syn minst effektiviteit (kom op, manager, Google wat it ferskil is), sûnder ien of oare te begripen. Sûnder algemien begryp fan 'e essinsje, it proses fan it krijen fan it resultaat, de ferliezen dy't foarkomme yn dit proses, de kosten fan ûntwikkeling. Koartsein, wurkje mei in programmeur as wie er in swarte doaze.
Se kamen yn it management fan programmeurs om krekt ien reden: der is hype, jild, de merk en in bulte deselde idioaten. Der is in plak om te ferdwale.
As der hype wie yn meganyske assemblageproduksje, soene wy dêr rinne. Stationwagons sûgje. Ik soe net fernuverje dat de keardel dy't yn desimber krystbeammen ferkeapet yn ús buert, is in IT-manager op fakânsje.
Koartsein, as it mooglik is, sjit dizze jonges yn 'e nekke. Sit gjin soargen, se sille in baan fine. Net ien fan harren sil ea wat fatsoenlik dwaan oant se sels in programmeur wurde. Om't hy de essinsje, meganisme, logika net begrypt fan it proses dat hy kontrolearret.
Goed, genôch oer managers. No nei it punt, foar programmeurs. Hoe kinne jo ûntwikkelingseffisjinsje ferheegje troch te learen koade fan hege kwaliteit te skriuwen.
Om effisjinsje te fergrutsjen, moatte jo problemen rapper oplosse sûnder kwaliteit te ferliezen. Om problemen flugger op te lossen, moatte jo daliks heechweardige koade kinne skriuwe. En "hege kwaliteit", en "skriuwe", en "daliks". Lit my útlizze mei in metafoar.
Koade fan hege kwaliteit skriuwe is as in frjemde taal korrekt prate. As jo in taal net kinne, besteegje jo in protte tiid oan it besykjen om jo gedachten dêryn te formulearjen.
As jo driuwend wat sizze moatte, dan stekke jo gewoan op guon wurden, faaks net de goede, jo ferjitte lidwurden, de juste wurdfolchoarder, om net te sizzen fan tiidwurdstiiden en minne útspraak.
As jo tiid hawwe om in antwurd te formulearjen, moatte jo in wurdboek of in online oersetter iepenje en in protte tiid besteegje oan it formulearjen fan jo gedachten. It gefoel sil lykwols noch ûnnoflik wêze: jo sizze it antwurd, en jo witte net oft it goed is of net. It is itselde mei de koade - it liket skreaun te wêzen, it liket te wurkjen, mar oft it fan goede kwaliteit is of net is in mystearje.
It blykt in dûbele fergriemerij te wêzen. It duorret tiid om mei in antwurd te kommen. It duorret ek tiid om dit antwurd te formulearjen - en net sa min.
As de feardigens fan it skriuwen fan heechweardige koade oanwêzich is, dan kin it antwurd fuortendaliks formulearre wurde, sa gau as it yn 'e holle is matured, sûnder ekstra tiid te besteegjen oan oersetting.
De feardigens om koade fan hege kwaliteit te skriuwen helpt by it ûntwerpen fan arsjitektuer. Jo sille gewoan gjin ferkearde, unrealizable of hand-me-down opsjes yn jo holle beskôgje.
Om gearfetsje: de feardigens om koade fan hege kwaliteit te skriuwen fersnelt it probleemoplossen signifikant.
Mar dat is net alles. Mei tank oan managers fan filtlaarzen is d'r ien fangen - wy hawwe gjin reden om koade fan hege kwaliteit te skriuwen. De behearder sjocht net nei de koade, de kliïnt sjocht net nei de koade. Wy komselden sjen litte koade oan elkoar, allinnich soms, yn guon projekten dêr't der in oanwiisde koade "checker" of periodike refactoring.
It docht bliken dat yn de measte gefallen de shitty koade giet nei produksje of nei de klant. In persoan dy't shitty koade hat skreaun foarmet in stabile neurale ferbining - it is net allinnich mooglik om te skriuwen shitty koade, mar it is ek nedich - it wurdt akseptearre, en se sels betelje foar it.
As gefolch hat de feardigens om koade fan hege kwaliteit te skriuwen gjin kâns om te ûntwikkeljen. De koade skreaun troch in betingst meiwurker wurdt nea kontrolearre troch immen. De ienige reden dat hy sil leare normaal te programmearjen is ynterne motivaasje.
Mar dizze ynterne motivaasje is yn striid mei plannen en easken foar effisjinsje en produktiviteit. Dizze tsjinspraak is dúdlik net oplost yn it foardiel fan hege kwaliteit koade, om't se net iens bekritisearje minsken foar shitty koade. En foar it mislearjen fan it plan - sels sa.
Wat moat ik dwaan? Ik sjoch en stel twa paden foar dy't kombinearre wurde kinne.
De earste is om jo koade te toanen oan immen binnen it bedriuw. Net reaktyf (as frege / twongen), mar proaktyf (uh, dude, sjoch nei myn koade, asjebleaft). It wichtichste is hjir net om sûkerige snot te pleatsen, net te besykjen om krityk op 'e koade yn in beleefde foarm te setten. As de koade is crap, wy sizze dat: de koade is crap. Mei útlis fansels en oanbefellings oer hoe't it better kin.
Mar dit paad is ek sa-sa. De tapassing dêrfan hinget ôf fan it punt wêrop kontakt barde. As it wurk al yn produksje gien is en it docht bliken dat de koade crap is, hat it gjin punt om it opnij te meitsjen. Krekter, de redenen - de metriken sille ek sakje. Managers sille rush yn en crush jo mei effisjinsje easken. En besykje har net iens te ferklearjen dat de shitty koade perfoarst weromkomt yn 'e foarm fan bugs - it sil op jo weromkomme. Jo kinne allinich in ynset meitsje om dit net wer te dwaan.
As it wurk noch net levere is, of krekt begon is, dan kin stront op 'e koade (of har projekt, idee) in heul praktyske betsjutting hawwe - de persoan sil it normaal dwaan.
De twadde manier, de coolste, is om iepen boarneûntwikkeling te dwaan yn net-wurktiden. Wat is it doel: foar in stel programmeurs, nammentlik programmeurs, om jo koade te sjen en der oer te praten. Elkenien binnen it bedriuw hat gjin tiid. Mar programmeurs oer de hiele wrâld noch hawwe neat te dwaan, en as jo skriuwe wat nuttich út in tapassing eachpunt, se sille grif sjen nei binnen.
De wichtichste trúk, nei myn miening, is it skriuwen fan koade yn net-wurktiden, om't de tsjinstelling tusken de kwaliteit fan 'e koade en de snelheid fan it leverjen fan it resultaat net sil wurkje. Skriuw jo ûntwikkeling op syn minst in jier. Noch deadlines, noch technyske spesifikaasjes, noch jild, noch baas sille druk op jo sette. Folsleine frijheid en kreativiteit.
Allinich yn frije kreativiteit sille jo begripe en fiele wat geweldige koade is, de skientme fan taal en technology sjen en de sjarme fan saaklike taken fiele. No, jo sille leare koade fan hege kwaliteit te skriuwen.
Wier, dit sil jo persoanlike tiid fereaskje. Krekt as elke oare ûntwikkeling. Sjoch it net as in kosten, mar as in ynvestearring - yn josels.
Boarne: www.habr.com