Una delle professioni più piene di idioti è quella dei manager che gestiscono i programmatori. Non tutti, ma quelli che non erano programmatori. Coloro che pensano che sia possibile “aumentare” l’efficienza (o aumentare l’“efficienza”?) utilizzando i metodi dei libri. Senza nemmeno prendersi la briga di leggere questi stessi libri, il video è gitano.
Coloro che non hanno mai scritto codice. Quelli per i quali vengono realizzati i film di Hollywood sui programmatori, beh, quelli per cui guardano la posta elettronica utilizzando la riga di comando. Coloro che non sono interessati ad altro che agli indicatori, alle scadenze e al proprio stipendio.
Quelli che sono la maggioranza.
Ma sono idioti per un motivo diverso. Vogliono efficienza, o almeno efficacia (dai, manager, Google qual è la differenza), senza capire né l'uno né l'altro. Senza comprendere in generale l'essenza, il processo per ottenere il risultato, le perdite che si verificano in questo processo, i costi di sviluppo. Insomma, lavorare con un programmatore come se fosse una scatola nera.
Si sono imbattuti nella gestione dei programmatori esattamente per una ragione: c'è clamore, denaro, mercato e un gruppo degli stessi idioti. C'è un posto dove perdersi.
Se ci fosse pubblicità nella produzione di assemblaggi meccanici, correremmo lì. Le station wagon fanno schifo. Non mi sorprenderebbe che il ragazzo che vende alberi di Natale nel nostro quartiere a dicembre sia un responsabile IT in vacanza.
In breve, se possibile, sparate al collo a questi ragazzi. Non preoccuparti, troveranno un lavoro. Nessuno di loro farà mai nulla di decente finché non diventeranno loro stessi un programmatore. Perché non comprende l'essenza, il meccanismo, la logica del processo che controlla.
Ok, basta con i manager. Ora veniamo al punto, per i programmatori. Come aumentare l'efficienza dello sviluppo imparando a scrivere codice di alta qualità.
Per aumentare l’efficienza, è necessario risolvere i problemi più velocemente senza perdere la qualità. Per risolvere i problemi più velocemente, devi essere in grado di scrivere immediatamente codice di alta qualità. E "alta qualità", "scrivi" e "immediatamente". Mi spiego con una metafora.
Scrivere codice di alta qualità è come parlare correttamente una lingua straniera. Quando non conosci una lingua, passi molto tempo cercando di formulare i tuoi pensieri in essa.
Se devi dire qualcosa con urgenza, ti limiti a mettere qualche parola, spesso non quella giusta, ti dimentichi degli articoli, dell'ordine corretto delle parole, per non parlare dei tempi verbali e della pronuncia sbagliata.
Se hai tempo per formulare una risposta, dovrai aprire un dizionario o un traduttore online e dedicare molto tempo a formulare i tuoi pensieri. La sensazione, però, sarà comunque spiacevole: dici la risposta e non sai se è corretta oppure no. Lo stesso vale per il codice: sembra che sia stato scritto, sembra che funzioni, ma se sia di buona qualità o meno è un mistero.
Si rivela una doppia perdita di tempo. Ci vuole tempo per trovare una risposta. Anche formulare questa risposta richiede tempo – e non così poco.
Se è presente l'abilità di scrivere codice di alta qualità, la risposta può essere formulata immediatamente, non appena è maturata nella testa, senza dedicare ulteriore tempo alla traduzione.
L'abilità di scrivere codice di alta qualità aiuta quando si progetta l'architettura. Semplicemente non prenderai in considerazione nella tua testa opzioni errate, irrealizzabili o abbandonate.
Riassumendo: la capacità di scrivere codice di alta qualità accelera notevolmente la risoluzione dei problemi.
Ma non è tutto. Grazie ai gestori degli stivali di feltro, c'è un problema: non abbiamo motivo di scrivere codice di alta qualità. Il manager non guarda il codice, il cliente non guarda il codice. Raramente ci mostriamo il codice a vicenda, solo qualche volta, in alcuni progetti in cui è presente un "controllo" del codice designato o un refactoring periodico.
Si scopre che nella maggior parte dei casi il codice di merda va alla produzione o al cliente. Una persona che ha scritto un codice di merda forma una connessione neurale stabile - scrivere codice di merda non solo è possibile, ma è anche necessario - è accettato e addirittura pagano per questo.
Di conseguenza, la capacità di scrivere codice di alta qualità non ha alcuna possibilità di svilupparsi. Il codice scritto da un dipendente condizionato non viene mai controllato da nessuno. L'unico motivo per cui imparerà a programmare normalmente è la motivazione interna.
Ma questa motivazione interna è in conflitto con i piani e i requisiti di efficienza e produttività. Questa contraddizione chiaramente non viene risolta a favore di un codice di alta qualità, perché le persone non criticano nemmeno le persone per il codice di merda. E per il mancato rispetto del piano, anche così.
Cosa dovrei fare? Vedo e propongo due percorsi che possono essere combinati.
Il primo è mostrare il tuo codice a qualcuno all'interno dell'azienda. Non in modo reattivo (quando richiesto/forzato), ma in modo proattivo (uh, amico, guarda il mio codice, per favore). La cosa principale qui è non pubblicare moccio zuccherino, non cercare di esprimere critiche al codice in una forma educata. Se il codice è una schifezza, lo diciamo noi: il codice è una schifezza. Con spiegazioni, ovviamente, e consigli su come migliorarlo.
Ma anche questo percorso è così così. La sua applicabilità dipende dal punto in cui si è verificato il contatto. Se il lavoro è già entrato in produzione e si scopre che il codice è pessimo, non ha senso rifarlo. Più precisamente, le ragioni: anche le metriche diminuiranno. I manager si precipiteranno e ti schiacceranno con requisiti di efficienza. E non provare nemmeno a spiegare loro che il codice schifoso tornerà sicuramente sotto forma di bug: si ritorcerà contro di te. Puoi solo impegnarti a non farlo più.
Se il lavoro non è stato ancora consegnato o è appena iniziato, versare merda sul codice (o sul suo progetto, idea) può avere un significato abbastanza pratico: la persona lo farà normalmente.
Il secondo modo, quello più interessante, è dedicarsi allo sviluppo open source durante le ore non lavorative. Qual è l'obiettivo: che un gruppo di programmatori, vale a dire programmatori, veda il tuo codice e ne parli. Tutti all'interno dell'azienda non hanno tempo. Ma i programmatori di tutto il mondo non hanno ancora niente da fare, e se scrivi qualcosa di utile dal punto di vista applicativo, sicuramente si guarderanno dentro.
Il trucco principale, secondo me, è scrivere codice durante l'orario non lavorativo, perché la contraddizione tra la qualità del codice e la velocità di consegna del risultato non funzionerà. Scrivi il tuo sviluppo per almeno un anno. Né le scadenze, né le specifiche tecniche, né i soldi, né il capo ti metteranno pressione. Completa libertà e creatività.
Solo nella libera creatività capirai e sentirai cos'è un codice eccezionale, vedrai la bellezza del linguaggio e della tecnologia e sentirai il fascino delle attività aziendali. Bene, imparerai a scrivere codice di alta qualità.
È vero, ciò richiederà di trascorrere del tempo personale. Proprio come qualsiasi altro sviluppo. Consideralo non come un costo, ma come un investimento – in te stesso.
Fonte: habr.com