In che modo i costruttori di case giustificano lo sforzo che ogni prigioniero a muro è di 16 "gli uni dagli altri? In che modo gli ingegneri aeronautici giustificano che bulloni / rivetti (qualunque cosa essi usino oggi) sull'ala di un aeromobile siano tutti equidistanti?
Forse la spaziatura esatta non ha importanza e forse la capitalizzazione non ha importanza, ma al di fuori dell'ingegneria del software è molto facile guardare a queste cose che non contano e distinguere tra un prodotto ben fatto e qualcosa che è stato schiaffeggiato insieme. Perché il software dovrebbe essere diverso?
Avere uno stile coerente in tutto il codice consente ai tuoi ingegneri di leggerlo in modo efficiente senza il cervello, "WTF" ogni volta che aprono un nuovo file sorgente. Forse la capitalizzazione di per sé non è un fattore di contribuzione importante, ma la chiave è lo stile generale. Un aspetto e una sensazione standard e coerenti di tutto il tuo codice ti fanno usare meno cicli cerebrali per cercare di leggerlo e più cicli per cercare di comprenderlo.
Gli sviluppatori stanno spendendo tempo nella capitalizzazione di Oracle perché stanno cercando di ripulire il casino e allineare tutti quei chiodi / rivetti / bulloni (qualunque sia l'equivalente del software). Forse è solo estetico per un Program Manager ma quando uno sviluppatore risolve una di queste cose, è una cosa in meno che lo infastidisce sul codice base, quindi la prossima volta che dovrà lavorare sul file, può evitare un altro fastidio / distrazione e salto dritto nel coraggio. I bravi ingegneri del software sono generalmente quelli che prestano molta attenzione ai dettagli. È importante perché quando scrivi un pezzo di codice, può fallire in oltre 1000 modi diversi e prestare attenzione è come evitare di spendere il 90% del tuo tempo a cercare i bug. Ma quando una persona presta attenzione ai dettagli, nota TUTTI i dettagli.
Uno dei ben noti autori (non ricordo la fonte ma Robert C. Martin o forse Brooks o DiMarco) una volta ha menzionato un'analogia che anche un manager di prodotto dovrebbe capire: se hai bisogno di fare una cena, vorresti piuttosto farlo in una cucina disordinata con contatori e utensili sporchi dappertutto? O preferiresti entrare in un ambiente pulito e pulito dove tutto è esattamente dove dovrebbe essere? Certo, puoi portare a termine il tuo lavoro in entrambi i tipi di ambienti, ma a) sarai sicuramente più efficiente in un ambiente pulito eb) se non altro, renderà la tua giornata di lavoro ancora più piacevole. Vagliare ogni giorno migliaia di righe di codice è un ambiente di lavoro di un ingegnere del software (NON responsabile del prodotto) e dovrebbero avere pieno diritto di entrare e ripulirlo. Perché il tuo ingegnere felice è il tuo ingegnere produttivo. Il tuo ingegnere le cui mani sono legate così tanto da non poter nemmeno fissare le maiuscole è un ingegnere che va a casa e lavora sul suo curriculum o sul suo software di avvio.
E quest'ultima parte è principalmente una sfuriata che potrebbe farmi fiammeggiare, ma qui va ... Nell'ultimo anno circa ho il piacere di incrociare percorsi con numerosi software prodotti da Oracle e la maggior parte dei il tempo che ho lasciato è che la loro politica ufficiale è quella di dare uno schiaffo. Non conosco altre società a quel livello che impiegano più di 6 mesi per correggere una vulnerabilità di sicurezza o che definisce una classe che contiene internamente i dati necessari ma l'unico modo per ottenere tali dati è di chiamare aString () e poi analizzare ciò che si ottiene indietro.