Cosa fai quando pensi che il codice non sia abbastanza complicato? [chiuso]

Questa è una ... visione problematica.

È simile a qualcuno che dice "userò solo selce per accendere un fuoco". come mostri loro un accendino.

Le parti interessate hanno ragione: vogliono vedere il valore. Come programmatori, siamo lì per fornire valore - non reinventare la ruota in modo che possiamo sentire come se stessimo "sgrossando".

Pagano i tuoi assegni: se il tuo modo complicato non sta andando abbastanza veloce, non complicarlo. C'è abbastanza complicazioni in questo mondo senza che gli sviluppatori aggiungano altro per sentirsi importanti.

Fools ignore complexity. Pragmatists suffer it. Some can avoid it. Geniuses remove it. - Alan Perlis

La semplicità è grande. Sforzarsi di trovare una soluzione più complicata mi sconcerta a essere onesto.

Posso entrare in empatia con quello sviluppatore senior. Quando ho fatto lo sviluppo web alla fine degli anni '90, i framework erano praticamente inesistenti e partire da zero era la pratica più comunemente accettata, a meno che la tua azienda non facesse lo stesso tipo di siti web per clienti diversi.

Recentemente ho deciso di aggiornare le mie competenze (il mio lavoro giornaliero è un software incorporato) e ho progettato un sito Web per il settore fotografico di mia cognata. Ho iniziato con Drupal e, sebbene mi aspettassi che l'esperienza fosse diversa, non ero preparato per quanto fosse straordinariamente diverso. Sembrava quasi come l'installazione e la configurazione piuttosto che lo sviluppo. Avevo quasi finito prima di scrivere una singola query SQL, e anche allora ho scritto solo 3 totali.

Tuttavia, piuttosto che vederlo come un negativo, l'ho preso come una buona cosa. Piuttosto che concentrarsi sul far funzionare le funzionalità di base, mi sono concentrato su ciò che ha reso il sito unico. Dopo aver superato una certa curva di apprendimento, quando mi veniva in mente una caratteristica, era spesso un lavoro di 10 minuti per inserirla, dove alla vecchia maniera avrebbero potuto impiegare giorni per andare bene. Di conseguenza, il sito è di qualità molto più elevata di quanto sarebbe stato altrimenti. Non è che non vengo messo in discussione, è che le mie sfide sono nelle parti più interessanti del design piuttosto che reinventare funzionalità banali.

L'errore del tuo senior developer è di non considerare soluzioni come questa in primo luogo. Potrebbe richiedere un po 'più di tempo per imparare a personalizzare in anticipo, ma il guadagno viene rapidamente.

"Il mio obiettivo è rendere le cose il più semplici possibile, ma non più semplici di così." - Albert Einstein

"Quando decidi tra due modelli che creano previsioni equivalenti, scegli la più semplice," - Restatement of Occam's Razor

In altre parole, c'è un'utilità intrinseca nella semplicità e non si dovrebbe tentare di iniettare la complessità e rovinarla.

La complicazione dovrebbe essere qualcosa per cui ti sfidi, non incoraggiare o perseguire.

Dato che hai sei mesi di tempo nel progetto, ritengo che il problema sia ragionevolmente complesso. È così complesso che il tuo team non ha fornito una soluzione. Hai bisogno di più complessità?

Sfortunatamente, ritengo che la tua guida sia tristemente confusa su cosa sia l'ingegneria del software. I bravi ingegneri usano quanti più componenti standard possono. Come li mettono insieme possono essere unici. Quando necessario, progetteranno componenti personalizzati.

Ho alcune regole in cui vivo quando progettano e costruiscono cose.

Ruba dal meglio che riesci a trovare: lo fai ogni giorno con tutti i tuoi strumenti (a meno che non li abbia codificati tu stesso). Quanto più del lavoro che hai già fatto, tanto più produttivo puoi essere. È un giorno molto strano, che non faccio affidamento sul lavoro degli altri.

Mettiti in testa ai giganti: C'è stato un tempo in cui abbiamo fatto tutto in codice macchina o assemblatore. Poi qualcuno ha inventato compilatori di lingue e altre lingue. Siamo sulle spalle di coloro che ci hanno preceduto. Mille grazie a coloro che hanno progettato e costruito gli strumenti che usiamo. Ora abbiamo MVC che si basa su altri strumenti e semplifica una nuova serie di problemi.

Rendilo semplice stupido: le cose che trovi complesse diventano incomprensibili quando devi risolverle in un paio di mesi. (Sono stato lì.) La mente umana può solo tenere traccia di circa 7 cose in qualsiasi momento. Quando stai programmando include come sei arrivato, dove vai, cosa stai facendo e cosa devi fare. Non lascia molto spazio alla complessità extra.

A differenza di altri rispondenti e commentatori, non ti suggerisco di lasciare o far licenziare lo sviluppatore principale. E 'normale. I programmatori sono abituati alle sfide e a loro non piace non averli.

La risposta alla tua domanda "cosa fare?" è "continua a lavorare". Spiega il tuo ruolo che quando un'attività è abbastanza complessa, uno strumento più potente richiede un lavoratore più potente . Ecco un paio di sfide che dovrai affrontare utilizzando un potente framework.

• Astrazioni di perdita . Il framework che sviluppi ti riassume un sacco di cose con cui ti è piaciuto giocare? Sì, ma cosa succederà quando queste astrazioni si diffonderanno , quando qualcosa va storto e non sarai in grado di capire cosa a titolo definitivo?

  Schiacciare tutto il codice e l'infrastruttura di framework e componenti che si trova sotto la tua astrazione è un compito impegnativo e richiede molta esperienza. A parte l'articolo di Joel collegato, un semplice esempio: uno stacktrace nel framework web di Ruby on Rails può facilmente raggiungere 50 chiamate di funzione. Non sembra così semplice, vero?

• Semplicità . Sì, il progetto di esempio non sembra un compito impegnativo. Un semplice programma sembra semplice in qualsiasi lingua. Ti abitui a una tale semplicità, ma quando diventa più complesso, mantenere il tuo codice semplice come nel progetto di esempio diventa una sfida .

Quindi, quale è ingegneria del software in base al tuo lead di sviluppo? (-:

Dato che sei sulla strada del "veloce e sporco lascia che sia fatto", potresti non avere il lusso di preoccuparti delle complicazioni del codice o di discutere l'esistenzialismo dell'ingegneria del software.

Se funziona, va bene.

Buona fortuna,

KM

Nella tua domanda manca il punto.

I tuoi stakeholder non ottengono il valore che credono di dover ottenere. E 'normale. Tutti vogliono di più con meno.

Tuttavia, il team dovrebbe sempre cercare di ottenere di più spendendo di meno e capire che cosa hanno veramente bisogno gli stakeholder. Potrebbe esserci una domanda migliore in merito ai bisogni, al modo in cui il tuo framework sta affrontando la sfida di fornire tali esigenze e raccomandazioni per fornire meglio il valore desiderato.

La tua formulazione della domanda presuppone che l'unica lamentela dello Sr. Developer sia che il nuovo framework "non è ingegneria del software" e che sta cercando una maggiore complessità. Alla luce di questa premessa, otterrete solo risposte che rafforzano il vostro punto di vista; ovviamente le persone diranno che la complessità è cattiva.

Potrebbe essere assolutamente vero, ma direi che la prima cosa da fare è assicurarsi di comprendere correttamente il punto di vista di Sr. Dev. Potrebbe effettivamente dire "questo non ci permetterà di soddisfare tutti i requisiti" o "colpiremo rapidamente un muro".

Per rispondere alla tua domanda dichiarata : dì loro che sono pazzi, un buon codice dovrebbe essere parti semplici che si sommano a una struttura complessa ma non complicata.

Per rispondere alla tua situazione : anch'io sono stato in una situazione simile in cui la direzione non poteva vedere che un po 'più di tempo trascorso ora avrebbe risparmiato molto più tempo dopo. L'ho superato, quello che non avrebbe dovuto essere, un incontro difficile e lungo a spiegare questo.

Non so nulla di ASP.net o dei suoi framework, e tu non sai quale lingua stai attualmente usando. Ma in un senso generale, sospetto che se non si riuscisse a fare progressi prima, aggiungere un framework non cambierebbe magicamente le cose. Soprattutto perché stai facendo un passo indietro e ricominciando da capo.

E, sfortunatamente, tra 5 anni probabilmente continuerai a mantenere quella soluzione "veloce-sporca".