Een van die mees idioot-belaaide beroepe is bestuurders wat programmeerders bestuur. Nie almal nie, maar diegene wat nie self programmeerders was nie. Diegene wat dink dat dit moontlik is om doeltreffendheid te “verhoog” (of “doeltreffendheid” te verhoog?) deur metodes uit boeke te gebruik. Sonder om eers die moeite te doen om dieselfde boeke te lees, is die video 'n sigeuner een.
Diegene wat nog nooit kode geskryf het nie. Diegene vir wie Hollywood-rolprente oor programmeerders gemaak word – wel, dié waar hulle e-pos kyk deur die opdragreël te gebruik. Diegene wat in niks anders as aanwysers, spertye en hul eie salaris belangstel nie.
Diegene wat die meerderheid is.
Maar hulle is idiote om 'n ander rede. Hulle wil doeltreffendheid hê, of ten minste doeltreffendheid (komaan, bestuurder, Google wat die verskil is), sonder om die een of die ander te verstaan. Sonder om die essensie, die proses om die resultaat te verkry, die verliese wat in hierdie proses voorkom, die koste van ontwikkeling algemeen te verstaan. Kortom, om met 'n programmeerder te werk asof hy 'n swart boks is.
Hulle het die bestuur van programmeerders raakgeloop om presies een rede: daar is hype, geld, die mark en 'n klomp dieselfde idiote. Daar is 'n plek om te verdwaal.
As daar 'n hype in meganiese samestelling produksie was, sou ons daar hardloop. Stasiewaens suig. Ek sal nie verbaas wees dat die ou wat in Desember Kersbome in ons woonbuurt verkoop 'n IT-bestuurder met vakansie is nie.
Kortom, indien moontlik, skiet hierdie ouens in die nek. Moenie bekommerd wees nie, hulle sal werk kry. Nie een van hulle sal ooit iets ordentliks doen totdat hulle self 'n programmeerder word nie. Omdat hy nie die essensie, meganisme, logika van die proses wat hy beheer, verstaan nie.
Goed, genoeg oor bestuurders. Nou tot die punt, vir programmeerders. Hoe om ontwikkelingsdoeltreffendheid te verhoog deur te leer hoe om kode van hoë gehalte te skryf.
Om doeltreffendheid te verhoog, moet jy probleme vinniger oplos sonder om kwaliteit te verloor. Om probleme vinniger op te los, moet jy onmiddellik hoëgehalte-kode kan skryf. En "hoë-gehalte", en "skryf", en "onmiddellik". Kom ek verduidelik met 'n metafoor.
Om hoë gehalte kode te skryf is soos om 'n vreemde taal korrek te praat. Wanneer jy nie ’n taal ken nie, spandeer jy baie tyd om jou gedagtes daarin te probeer formuleer.
As jy dringend iets moet sê, hou jy net by sommige woorde vas, dikwels nie die regte nie, jy vergeet van artikels, die korrekte woordorde, om nie eens te praat van werkwoordtye en swak uitspraak nie.
As jy tyd het om 'n antwoord te formuleer, sal jy 'n woordeboek of 'n aanlyn vertaler moet oopmaak en baie tyd spandeer om jou gedagtes te formuleer. Die gevoel sal egter steeds onaangenaam wees: jy sê die antwoord, en jy weet nie of dit korrek is of nie. Dit is dieselfde met die kode - dit lyk asof dit geskryf is, dit lyk of dit werk, maar of dit van goeie gehalte is of nie, is 'n raaisel.
Dit blyk 'n dubbele mors van tyd te wees. Dit neem tyd om met 'n antwoord vorendag te kom. Dit neem ook tyd om hierdie antwoord te formuleer – en nie so min nie.
As die vaardigheid om hoëgehalte-kode te skryf teenwoordig is, kan die antwoord onmiddellik geformuleer word sodra dit in die kop volwasse is, sonder om ekstra tyd aan vertaling te spandeer.
Die vaardigheid om kode van hoë gehalte te skryf, help met die ontwerp van argitektuur. Jy sal eenvoudig nie verkeerde, onrealiseerbare of hand-me-down opsies in jou kop oorweeg nie.
Om op te som: die vaardigheid om kode van hoë gehalte te skryf, versnel probleemoplossing aansienlik.
Maar dit is nie al nie. Danksy die viltstewelbestuurders is daar een vangs - ons het nie 'n rede om kode van hoë gehalte te skryf nie. Die bestuurder kyk nie na die kode nie, die kliënt kyk nie na die kode nie. Ons wys selde kode vir mekaar, net soms, in sommige projekte waar daar 'n aangewese kode-“checker” of periodieke herfaktorering is.
Dit blyk dat in die meeste gevalle die kak kode na produksie of na die klient gaan. 'n Persoon wat kak kode geskryf het, vorm 'n stabiele neurale konneksie - dit is nie net moontlik om kak kode te skryf nie, maar dit is ook nodig - dit word aanvaar, en hulle betaal selfs daarvoor.
Gevolglik het die vaardigheid om kode van hoë gehalte te skryf geen kans om te ontwikkel nie. Die kode wat deur 'n voorwaardelike werknemer geskryf is, word nooit deur enigiemand nagegaan nie. Die enigste rede waarom hy sal leer om normaal te programmeer, is interne motivering.
Maar hierdie interne motivering bots met planne en vereistes vir doeltreffendheid en produktiwiteit. Hierdie teenstrydigheid word duidelik nie opgelos ten gunste van hoë kwaliteit kode nie, want hulle kritiseer nie eers mense vir kak kode nie. En vir die versuim om die plan te vervul – selfs so.
Wat moet ek doen? Ek sien en stel twee paaie voor wat gekombineer kan word.
Die eerste is om jou kode aan iemand binne die maatskappy te wys. Nie reaktief (wanneer gevra/gedwing), maar proaktief (uh, ou, kyk asseblief na my kode). Die belangrikste ding hier is om nie soet snot te plaas nie, nie om kritiek op die kode in 'n beleefde vorm te probeer plaas nie. As die kode kak is, sê ons so: die kode is kak. Met verduidelikings, natuurlik, en aanbevelings oor hoe om dit beter te maak.
Maar hierdie pad is ook so-so. Die toepaslikheid daarvan hang af van die punt waarop kontak plaasgevind het. As die werk reeds in produksie gegaan het en dit blyk dat die kode kak is, is dit geen sin om dit oor te doen nie. Meer presies, die redes - die statistieke sal ook sak. Bestuurders sal instorm en jou verpletter met doeltreffendheidvereistes. En moenie eers aan hulle probeer verduidelik dat die kak kode beslis sal terugkom in die vorm van goggas nie - dit sal terugvuur op jou. Jy kan net 'n verbintenis maak om dit nie weer te doen nie.
As die werk nog nie afgelewer is nie, of pas begin het, dan kan dit nogal 'n praktiese betekenis hê om kak op die kode (of sy projek, idee) te gooi – die persoon sal dit normaal doen.
Die tweede manier, die coolste een, is om oopbronontwikkeling te doen gedurende nie-werksure. Wat is die doel: vir 'n klomp programmeerders, naamlik programmeerders, om jou kode te sien en daaroor te praat. Almal binne die maatskappy het nie tyd nie. Maar programmeerders regoor die wêreld het steeds niks om te doen nie, en as jy iets nuttig uit 'n toepassingsoogpunt skryf, sal hulle beslis na binne kyk.
Die belangrikste truuk, na my mening, is om kode tydens nie-werksure te skryf, want die teenstrydigheid tussen die kwaliteit van die kode en die spoed om die resultaat te lewer, sal nie werk nie. Skryf jou ontwikkeling vir ten minste 'n jaar. Nóg spertye, nóg tegniese spesifikasies, nóg geld, nóg baas sal druk op jou plaas. Volledige vryheid en kreatiwiteit.
Slegs in vrye kreatiwiteit sal jy verstaan en voel wat wonderlike kode is, die skoonheid van taal en tegnologie sien, en die bekoring van saketake voel. Wel, jy sal leer om kode van hoë gehalte te skryf.
Dit sal weliswaar van jou vereis om persoonlike tyd te spandeer. Net soos enige ander ontwikkeling. Kyk dit nie as 'n koste nie, maar as 'n belegging - in jouself.
Bron: will.com