Scegli lo sforzo di progettazione del codice o la pigrizia nel mondo bancario

Ho lavorato per due anni in una grande banca d'investimento.

Ho realizzato alcuni progetti tecnici con il desiderio di creare il codice più ottimizzato, rispettando i buoni modelli di progettazione adattati, il principio SOLID, la legge di demeter ed evitando ogni sorta di codici duplicati ...

Quando la consegna in produzione => zero bug, tutto è avvenuto come previsto.

Ma la maggior parte degli sviluppatori è venuta da me per precisare che tutto il mio codice è troppo complesso per la comprensione della lettura. Ho ascoltato per esempio: "fai un po 'if e instanceof, dimentica il polimorfismo in modo che sarà molto facile correggere i bug di produzione di emergenza". Non ho preferito rispondere ......

Sapere che questi sviluppatori non sono affatto curiosi, rifiutando gli sforzi per comprendere un buon design (ad esempio, il 90% degli sviluppatori non conosce cos'è un modello di strategia e crea codice procedurale e non progetta mai perché vuole, ha detto, semplicità ), i miei project manager mi hanno detto che sono davvero nel modo sbagliato e troppo idealista per il mondo della Banca.

Cosa mi consiglieresti? Devo mantenere il desiderio di un codice davvero buono o adattarmi alla maggior parte degli sviluppatori che, lo ripeto, non sono davvero interessanti per il codice di progettazione che è secondo me, tutta la bellezza del nostro lavoro di sviluppatore.

O al contrario, dovrebbero imparare i principi e le migliori pratiche OO di base per adattarsi al mio codice?

i miei project manager mi hanno detto che sono davvero nel modo sbagliato e troppo idealista per il mondo della Banca.

GTFO!

È ora di andarsene e compatirli. Perché dovresti fregartene? Sai che costerà loro soldi a lungo termine con il loro staff incompetente. Questo non è un gioco di discussione tecnica. Si tratta di politica. Invitali ad addestrare gli altri sviluppatori o GTFO! Se non hai abbastanza peso politico, allora GTFO! Cerca un'azienda con pratiche migliori.

L'unico motivo per rimanere lì è un adeguato risarcimento per il mal di testa. Quindi paga meglio sopra la media o GTFO! Dubito che tu possa crescere anche lì come sviluppatore di software. La crescita della nostra professione si ottiene principalmente lavorando con persone migliori di te e che incoraggiano le migliori pratiche. E meglio sei, maggiore è il tuo valore di mercato per le aziende a cui tieni.

Sì, so che questa non è una delle mie solite risposte, ma davvero, se non puoi giocare al gioco politico in questa compagnia, GTFO.

Cosa mi consiglieresti? Devo mantenere il desiderio di un codice davvero buono o adattarmi alla maggior parte degli sviluppatori che, lo ripeto, non sono davvero interessanti per il codice di progettazione che è secondo me, tutta la bellezza del nostro lavoro di sviluppatore.

Non lavorerei per un'azienda che vuole che io fornisca soluzioni non ottimali. Voglio scolpire il mio nome nel software. Voglio esserne orgoglioso. Non scrivo applicazioni procedurali in lingue basate sul paradigma OO. Credo nel software di alta qualità e se la società non lo farà, lo farò GTFO! Spero che tu abbia abbastanza "fottiti soldi".

Punto difficile. Penso che tu possa andare in due modi in parallelo, sostenendo il tuo punto e mostrando la volontà di scendere a compromessi:

• Si tratta di soldi. Come ogni altro lavoro di sviluppo, in effetti, ma poiché si sottolinea l'ambiente bancario, questo dovrebbe funzionare anche meglio;). Mostra loro che il tuo stile fa risparmiare denaro. Trova un esempio di come un cambiamento nei requisiti potrebbe essere fatto molto facilmente grazie al tuo design. Cerca di trovare un altro codice (devi assicurarti di non diventare troppo aggressivo qui, ma hey, si tratta di confrontare gli stili di codice) che è incline a rompersi presto e mostra loro come non devi preoccuparsi di tali problemi perché il codice è di qualità migliore per cominciare.

• Si tratta di soldi. E se il tuo stile di programmazione in effetti costa denaro? Potrebbe benissimo succedere se altre persone passano più tempo a cercare di capire il tuo codice di quello che viene salvato da una progettazione adeguata. Potresti fare la cosa giusta tecnicamente e comunque non contribuire positivamente allo sforzo del team. Inoltre, è possibile esagerare con la progettazione OOP. Sono con te dal lato "il buon design è bello", ma sto provando a renderti consapevole qui del loro punto di vista e di come potrebbero essere proprio dalla loro prospettiva. Parallelamente al punto precedente, prova a trovare un punto in cui l'hai superato. Questo ti dà un certo margine di manovra: puoi dire, ok, posso essere un po 'più pragmatico qua e là, ma guarda, ci sono anche posti in cui questo codice è davvero migliore.

Ma la maggior parte degli sviluppatori è venuta da me per precisare che tutto il mio codice è troppo complesso per la comprensione della lettura

Ti è mai venuto in mente che potrebbero avere ragione?

Ho lavorato con qualcuno che ha fatto molti sforzi per scrivere codice che ha descritto come elegante. Ha trascorso molto tempo a definire il lavoro di altre persone non elegante. Quando si rende necessario mantenere il codice, il suo codice non è il codice che sceglierei di modificare. È così preciso e preciso che cambiarlo è profondamente irto di pericoli.

La parola interessante che menzioni qui è "complessa". Il codice che può essere descritto come complesso può raramente essere descritto anche come particolarmente buono.

I produttori di mobili di epoca vittoriana (almeno quelli di cui vediamo ancora oggi il lavoro) erano veri e propri artigiani, ciò che creavano era funzionale, bello, ben realizzato e progettato e costruito per durare una vita. Tuttavia, negli ultimi 150 anni, il mondo è cambiato. Non molte persone sono disposte a pagare per tale artigianato, quando le alternative più economiche sono più pragmatiche dal punto di vista commerciale quando si acquista un tavolo da pranzo.

Molti programmatori vogliono essere gli artigiani del passato, purtroppo il commercio impone che ciò non possa accadere in ogni momento. Puoi scegliere, adattarti o partire. Ci sono aziende che vogliono artigiani, ma sono notevolmente più numerose di quelle che vogliono prodotti che per lo più funzionano, a buon mercato e ora.

Il suggerimento per me che non sei adatto per la maggior parte dello sviluppo di software commerciale è il "Quando la consegna in produzione => zero bug". Nemmeno la Nasa l'ha raggiunto con le navette spaziali.

Gli unici luoghi in cui la tua attenzione ai dettagli, e quindi i costi iniziali, è probabilmente accettabile sono i sistemi critici per la vita di livello 1 - ad es. Avionica / aerospaziale, automobilistica, militare e medica.

Il problema è che stai lavorando nel posto sbagliato. Sembra che tu sia un programmatore molto incline al mondo accademico. Non farai bene nell'ambiente in cui ti trovi ed è molto probabile che vengano inventate delle scuse per sbarazzarti di te e del tuo codice "troppo complesso". È possibile che vengano assegnati incarichi spazzatura e / o revisioni scadenti delle prestazioni e così via fino a quando non si lascia da soli o non hanno una scia di carta di copertura posteriore sufficiente per licenziarti.

Ti consiglierei di trovare un posto di lavoro che valorizzi le tue inclinazioni accademiche. Sono là fuori. Troverai anche alcuni che si trovano sul recinto tra pragmatico e accademico. Un lavoro del genere potrebbe essere la tua migliore opzione poiché ti permetterebbe di invitare un po 'di caos nel tuo approccio mentre aiuti gli altri a rinforzare il loro.

Prima di prendere misure così drastiche come cambiare il tuo datore di lavoro, proverei a migliorare la tua capacità di spiegare ai non programmatori come i tuoi dirigenti perché il tuo modo di scrivere codice è migliore per l'azienda, risparmiando tempo e denaro. Inoltre, assicurati di non applicare i modelli di design solo per motivi di design - sei sicuro di aver seguito anche le regole di KISS e YAGNI? (Ok, il modello strategico e il polimorfismo non sono scienza missilistica, dai ai tuoi colleghi un po 'di tempo per adattarsi e spiegare loro perché hai scelto quell'approccio.)

Nella mia azienda, abbiamo condotto una serie di seminari basati su Clean Code Developer . Lo scopo era quello di creare un forum al di fuori delle normali attività quotidiane con i suoi tempi frenetici e scadenti e i suoi compromessi, in cui gli sviluppatori potevano conoscere i principi di progettazione del software (come hai menzionato), le tecniche di programmazione ecc. E riflettere sui loro progetti e il proprio lavoro.

Sono stati discussi anche esempi di vita reale di progetti reali. Il feedback dei partecipanti è stato molto positivo per AFAIK. Tuttavia, è difficile misurare un vantaggio reale.

La partecipazione a questi seminari era in parte sul tempo sponsorizzato dall'azienda, in parte sul tempo libero dei partecipanti. Non raggiungerai quei colleghi che non si interessano all'apprendimento e semplicemente vogliono fare il loro lavoro e andare a casa, ma per chiunque abbia un certo interesse nel proprio lavoro lasciato questo potrebbe essere interessante.

Innanzi tutto verificherei che la tua strada sia davvero migliore. Il codice orientato agli oggetti può essere molto bello, ma può anche essere un incubo di effetti collaterali nascosti e ogni azione può richiedere diverse classi.

Meglio ancora vai a InfoQ e guarda il discorso di Rich Hickey su "Simple Made Easy"

Dovrai arrenderti un po 'se vuoi continuare a lavorare lì senza continue lotte. Un gruppo di sviluppatori che è tutto procedurale non accetterà subito il polimorfismo. Anche se potrebbero non essere in grado di progettare in modo OO, possono imparare dal tuo codice. Potrebbero apprezzare che alcuni di voi il codice è più facile da mantenere.

Come nota a margine, è necessario porre domande durante il processo di intervista per vedere quale processo di sviluppo e metodologia di codifica viene utilizzato se si ritiene che sia importante abbinare le proprie preferenze.

Le emergenze accadono. Tu non sei perfetto e le loro mani si rovinare il vostro codice ad un certo punto. Ciò a meno che non ti prenda mai del tempo libero, che, come confermerà il tuo medico di famiglia, non fa bene alla salute. E porta a maggiori possibilità di emettere codice scadente.

Il tuo codice potrebbe avere una qualità superiore (fatto non dimostrato) ma hanno delle politiche . (sicuro come un vero inferno)

Sei stato avvisato di seguire le politiche e sarai responsabile di non averle seguite. In una situazione di emergenza. In un'applicazione bancaria. Voglio dire, se il tuo obiettivo sta finendo male e in prigione posso capire molti modi più divertenti e significativi per ottenere lo stesso risultato.

I vostri compagni di cella, tuttavia, sarebbero lieti di sentirvi sconclusionati dalla mancanza di curiosità dei vostri ex colleghi.

(poi di nuovo, la tua azienda probabilmente non ha politiche interne contro la progettazione di OO, ma l'ingegnoso ingegnere COBOL che proverà a sistemare il tuo codice riuscirà a risolverlo dal nulla e, IMHO, nel peggiore dei casi, lui ' Avrò il 40% di probabilità di segnare un colpo critico)

Cerca di ricordare che la programmazione è considerata da alcuni come un mezzo per un fine piuttosto che per se stessa. Pensa a tutti i prodotti e servizi che usi: passi molto tempo a considerare se il codice sottostante è realizzato in modo elegante? O li apprezzi semplicemente mentre funzionano? Trova un settore o una causa di cui sei appassionato, quindi trova un'organizzazione con quella, quindi offri loro soluzioni che includono la programmazione ma non solo. I problemi possono essere risolti brillantemente in diversi modi.