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

my project managers told me that I am really in the wrong way and too idealist for the Bank world.

GTFO!

È ora di andarsene e di averne pietà. Perché dovresti dare un cazzo? Sai che a lungo andare costano loro dei soldi 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 migliori pratiche.

L'unica ragione per cui stare lì è un compenso adeguato per i tuoi mal di testa. Quindi è meglio che paghino al di sopra della media o GTFO! Dubito che tu possa crescere 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, più alto è il valore di mercato per le aziende a cui tieni.

Sì, so che questa non è una delle mie solite risposte, ma in realtà, se non puoi giocare al gioco di politica in questa compagnia, GTFO.

What would you advise me ? Should I keep desire of really good code or adapt me to majority of developers who are, I repeat it, really not interesting by design code that is according to me, all the beauty of our developer job.

Non lavorerei per un'azienda che vuole che fornisca soluzioni subottimali. Voglio incidere il mio nome nel software. Voglio esserne orgoglioso. Non scrivo applicazioni procedurali in linguaggi basati sul paradigma OO. Credo in software di alta qualità e se la società non lo fa, io GTFO! Spero che tu abbia abbastanza "fuck you money".

Punto critico. Penso che puoi procedere in due modi in parallelo, mantenendo il tuo punto di vista e mostrando la volontà di scendere a compromessi:

• Si tratta di soldi. Come ogni lavoro di sviluppo, infatti, ma dal momento che si sottolinea l'ambiente bancario, questo dovrebbe funzionare ancora meglio;). Mostra loro che il tuo stile risparmia denaro. Trova un esempio di come un cambiamento nei requisiti potrebbe essere fatto facilmente grazie al tuo design. Cerca di trovare un pezzo di codice (devi assicurarti di non diventare troppo aggressivo qui, ma hey, si tratta di confrontare stili di codice) che è soggetto a rompersi presto e mostrare loro come non devi preoccupati di questi problemi perché il tuo codice è di qualità migliore per cominciare.

• Si tratta di soldi. Cosa succede se il tuo stile di codifica in realtà costa denaro? Potrebbe benissimo farlo, se altre persone passano più tempo a cercare di capire il tuo codice rispetto a ciò che viene salvato da una corretta progettazione. Potresti fare la cosa giusta tecnicamente e non contribuire ancora positivamente allo sforzo del team. Inoltre, è possibile esagerare con il design OOP. Sono con te sul lato "il buon design è bello", ma sto cercando di renderti consapevole qui del loro punto di vista e di come potrebbero effettivamente essere giusti dal loro punto di vista. In parallelo al punto precedente, prova a trovare un punto in cui hai esagerato. Questo ti dà un 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. Ti aiuta anche ad entrare in una mentalità più cooperativa se cerchi di metterti nei panni degli altri ragazzi.

But, a majority of developers came to me in order to precise that all my code is too complex for reading comprehension

Ti è mai venuto in mente che potrebbero avere ragione?

Ho lavorato con qualcuno che ha fatto un sacco di sforzi per scrivere codice che ha descritto come elegante. Passava molto tempo a denigrare il lavoro altrui come non elegante. Quando si rende necessario mantenere il codice, il suo codice non è il codice che avrei scelto di modificare. È così preciso ed esigente che cambiarlo è profondamente irto di pericoli.

La parola interessante che citi qui è "complessa". Il codice che può essere descritto come complex può raramente essere descritto come particolarmente buono.

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

Molti programmatori vogliono essere gli artigiani di un tempo, sfortunatamente, il commercio impone che questo non possa accadere in ogni momento. Puoi scegliere, adattarti o andartene. Ci sono aziende che vogliono artigiani, ma sono enormemente superate in numero da quelli che vogliono prodotti che funzionano principalmente, a buon mercato e ora.

Il suggerimento per me di non essere adatto alla maggior parte dello sviluppo di software commerciale è "Quando consegna in produzione = > zero bugs". Neanche la Nasa l'ha raggiunto con le navicelle spaziali.

Le uniche aree in cui l'attenzione ai dettagli, e quindi il costo iniziale, è probabile che sia accettabile sono i sistemi vitali di livello 1 - ad es. Avionica / aerospaziale, automobilistica, militare e medica.

Prima di adottare 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 codificare è migliore per l'azienda e fa risparmiare tempo e denaro. Inoltre, assicurati di non applicare modelli di progettazione solo per motivi di design: sei sicuro di aver seguito anche le regole di KISS e YAGNI? (Ok, il modello di strategia e il polimorfismo non sono scienza missilistica, dai ai tuoi colleghi un po 'di tempo per adattarsi e spiegarli perché hai scelto quell'approccio.)

Nella mia azienda, abbiamo condotto una serie di workshop basati su Clean Code Developer . Lo scopo era quello di creare un forum al di fuori della normale attività quotidiana con le sue frenetiche scadenze e pessimi compromessi, in cui gli sviluppatori potevano conoscere i principi di progettazione del software (come lei menzionato), le tecniche di programmazione ecc. E riflettere sui loro progetti e il loro lavoro.

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

La partecipazione a questi workshop era in parte dedicata al tempo sponsorizzato dall'azienda, in parte al tempo libero dei partecipanti. Non raggiungerai quei colleghi che non si preoccupano dell'apprendimento e vogliono semplicemente fare il loro lavoro e tornare a casa, ma per chiunque abbia un certo interesse per il proprio lavoro, questo potrebbe essere interessante.

Vorrei innanzitutto verificare 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 diverse.

Meglio ancora andare a InfoQ e guarda il discorso di Rich Hickey su "Semplicemente semplice"

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 è abbastanza probabile che una scusa possa inventarsi per sbarazzarti di te e del tuo codice "troppo complesso". Potresti ricevere assegnazioni di spazzatura e / o dare scarse recensioni di prestazioni e simili fino a che non parti di tua iniziativa o se hanno una documentazione cartacea sufficiente per spararti.

Consiglierei di trovare un posto di lavoro che dia valore alle tue inclinazioni accademiche. Sono là fuori. Troverete anche alcuni che sono in bilico tra pragmatico e accademico. Un lavoro del genere potrebbe essere la tua migliore opzione dal momento che ti permetterebbe di invitare un po 'di caos nel tuo approccio mentre aiuti gli altri a valorizzarli.

Dovrai arrenderti un po 'se vuoi continuare a lavorare lì senza lotte continue. Un gruppo di sviluppo che è tutto procedurale non accetterà il polimorfismo subito. Sebbene possano non essere in grado di progettare in modo O-O, possono imparare dal tuo codice. Potrebbero apprezzare che alcuni di voi codici sono più facili da mantenere.

Come nota a margine, devi porre domande durante il processo di intervista per vedere quale processo di sviluppo e la metodologia di codifica vengono utilizzate se ritieni che sia importante abbinare le tue preferenze.

Le emergenze accadono. Non sei perfetto e le loro mani faranno rovinare il tuo codice ad un certo punto. Questo a meno che tu non prendi mai un periodo di pausa, che, come confermerà il tuo medico generico, non è buono per la tua salute. E porta a maggiori possibilità di emettere un codice scadente.

Il tuo codice potrebbe avere una qualità superiore, (fatto non dimostrato) ma hanno politiche . (sicuramente come un fatto infernale)

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 finisce male e in prigione riesco a capire molti modi più divertenti e più significativi per ottenere lo stesso risultato.

I tuoi compagni di cella, tuttavia, sarebbero felici di sentirti parlare della mancanza di curiosità dei tuoi ex colleghi.

(anche in questo caso, probabilmente la tua azienda non ha politiche interne contro la progettazione OO, ma l'impacciato ingegnere COBOL che cercherà di sistemare il tuo codice ne farà un po 'fuori dal nulla e, IMHO, nel peggiore dei casi , avrà una probabilità del 40% di segnare un colpo critico)

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