Essere severi o pragmatici?

Sto cominciando a rendermi conto che lo sviluppo di software è (tra gli altri) un processo di costante ponersi domande. Domande riguardanti la qualità del codice, la separazione delle preoccupazioni, la riduzione al minimo delle dipendenze, ...

Ma la domanda principale è: quanto lontano puoi andare senza finire in un ospedale psichiatrico?

Mi sto candidando per un nuovo lavoro. Ieri ero con un possibile futuro datore di lavoro che voleva testare le mie capacità di programmazione. Uno degli esercizi era: spiegare cosa fa questo codice. Ho esaminato il codice dell'applicazione (winforms in vb.net) che hanno sviluppato (è un'applicazione amministrativa per un ospedale). Questo mi ha dato l'opportunità di vedere davvero come si avvicinano alle cose ed è stato piuttosto deludente.

Qualche esempio:

• Ho visto da qualche parte: chiama [inserisci il nome della subroutine qui] -> Sono stato colpito: non è qualcosa da VB6?
• Hanno un datalayer separato, usando ado.net, ma un metodo che ho dovuto esaminare restituisce un set di dati al layer chiamante. Quindi, separatore di dati separato o no, l'applicazione è legata ad ado.net (che potrebbe anche non essere mai un problema se non passano mai a un altro approccio di accesso ai dati).
• Quel set di dati viene letto così com'è, quindi è ancora un approccio incentrato sui dati (ovviamente, si può discutere di quanta logica / comportamento si può mettere in classi come "Paziente" o "LabAnalysisRequest".
• Credo anche di aver visto la costruzione di una query sql mediante concatenazione di stringhe.
• Usano le procedure memorizzate (che, per me, significa: diffusione della logica)
• nessuna menzione di viste / controller: è tutto guidato dalla forma
• La cosa più brutta che ho visto è stata:

      Se TestEnvironment.IsTesting quindi
         someVar = [qualche valore hard coded]
      altro
         someVar = [un valore recuperato dinamicamente]
      finisci se
      [resto della funzione qui]
  

È tutto così diverso da quello che ho imparato a scuola: livello di dominio (persistenza agnostica), livello di persistenza, livello di presentazione, test di unità, ...

Quindi riformulo la mia domanda: quanto fondamentale o dogmatico dovrebbe essere? In che misura un programmatore dovrebbe attenersi ai suoi principi o semplicemente scrivere un codice che funzioni?

So che non risponde direttamente alla tua domanda, ma sento ancora che vale più di un commento:

Quando fai un colloquio di lavoro, li stai intervistando tanto quanto ti stanno intervistando . Abbassa l'abitudine di vedere un'intervista come qualcosa a cui striscia sul ventre supplicando che ti offrano qualcosa. Ti controllano, ma anche tu li controlli . Se non gli piaci, non ti assumeranno. Se non ti piacciono, non andare a lavorare lì.

Sì, nel settore, con una base di codice legacy di dieci anni che è stata violata nel tempo da tre dozzine di sviluppatori con background, abilità e passione diversi, guidati da scadenze strette, mancanza di risorse e vincoli finanziari, il codice non sarà mai guarda come avresti dovuto (dovresti) imparare. Dovrai fare alcune concessioni. Ma quanti, e dove tracciate la linea, dipende totalmente da voi.
Certo, i lavori sono più difficili da trovare meno concessioni che fai. Ma potrebbero essere più divertenti.

FWIW, finora (> 10 anni nel settore) non ho mai lavorato in una grande azienda con molti sviluppatori (~ 30 sviluppatori erano i più, una dozzina la norma), perché è molto più probabile che tu cambi qualcosa in un piccolo azienda. Fintanto che faccio abbastanza soldi per non morire di fame i bambini, non vorrei essere una piccola ruota dentata in una grande azienda, dove tutto quello che devo fare è girare in sincronia con il resto degli ingranaggi.
Ho rifiutato le offerte di lavoro dopo aver visto i test che volevano che superassi. Sono uno sviluppatore C ++, e ci sono molti test C ++ là fuori che sono così male che fa arricciare le unghie dei piedi per il disgusto, e non voglio passare il tempo a combattere i mulini a vento perché hanno assunto deficienti che non sono in grado di scrivere codice pulito.
Ho anche lasciato il lavoro dopo alcuni mesi perché la loro filosofia di programmazione (obiettivi a breve termine, non importa l'anno prossimo) non si adattava alle mie capacità (stabilità del codice a lungo termine), nonostante dicessero diversamente nell'intervista.

Non scrivere mai codice che fa semplicemente il lavoro. Tuttavia, sii ugualmente disposto a esaminare la tua dottrina. Solo perché l'hai imparato a scuola, non significa che sia un pensiero attuale, o anche un pensiero valido. Il ciclo di vita della progettazione del software è diventato obsoleto, a causa della programmazione che deve essere più reattiva al mondo degli affari. A volte le soluzioni software collegate in modo scomodo sono collegate in modo imbarazzante perché le parti sono state sostituite nel tempo consentito.

Ecco un elenco di problemi che ho compilato che determineranno quanto bene ti adatti allo stile di vita dei codici di un'azienda.

1. Quanto apprezzano impostare il tempo da parte per refactoring e aggiornare la loro base di codice aggiornata. Il modo in cui visualizzano l'aggiornamento della base di codice sarà un fattore determinante nel modo in cui ci si adatta.
2. Con quale frequenza acquistano terze parti anziché codificare internamente.
3. Cosa ne pensano del software open source. Si rendono conto di avere flessibilità nel modificare il codice. Lo vedono allo stesso modo dell'acquisto di terze parti.
4. Lavorerai su un certo livello di astrazione. Il team con cui ti interfaccia determina la tua interfaccia per te? Quale livello / squadra / lato dell'interfaccia ha più potere nel processo decisionale.
5. Quanto la supervisione ascolta i programmatori quando prendono decisioni. Quando un programmatore lancia una bandiera rossa, il supervisore si ferma e rivede la propria decisione.
6. Consideri i programmatori esperti nella gestione? Come vedono la loro esperienza? La loro esperienza è valida? Stanno lasciando che esperienze obsolete influenzino il processo decisionale?
7. Quanto è appiccicosa la base di codice?
8. Con quale frequenza aggiornano i loro strumenti di programmazione (IDE, ecc.)

Le risposte a queste domande si adattano meglio a come apprezzerai il loro stile di vita di programmazione, piuttosto che vedere se corrispondono al tuo dogma.

Il dogma sarà inevitabilmente rotto (non abbiamo tempo di aggiornare X). Tuttavia, le priorità definiranno quanto ti scontrerai con il loro stile e il processo decisionale.

Penso che tu debba soppesarlo come parte del tutto. Ricordo che uno dei miei primi lavori era una posizione in un gruppo che mi diceva che stavano facendo C ++ orientato agli oggetti - che era quello che avevo appena fatto diversi anni a scuola.

La loro autovalutazione era sbagliata - stavano facendo un po 'grosso C. Era ancora molto funzionalmente progettato in natura e dovevo andare a farmi un libro in C per insegnarmi e stampare e altri meccanismi in C che non avevo mai imparato. Il fatto che nessuno nel team abbia nemmeno realizzato quanto C fosse come il loro codice indica quanto fosse fuori moda questo "design C ++". Il mio obiettivo in quel momento era quello di fare lo sviluppo di OO, quindi questo è stato scoraggiante.

Ma sono contento, alla fine, di essermi bloccato con la squadra. Erano un gruppo dinamico di persone molto intelligenti e mi sono bagnato i piedi con molti problemi difficili, ho dovuto lavorare tutto il ciclo di vita e le cose che ho imparato sul dominio del problema (PKI) hanno alimentato la mia carriera da allora. Il lavoro che il team stava svolgendo nello spazio funzionale è stato fantastico e continuo a pensare molto a quel prodotto e a quell'esperienza di lavoro. Meglio ancora: lavoro ancora con alcune di quelle persone oggi (diverse aziende dopo), sono ancora fonte di ispirazione e stiamo ancora facendo un buon lavoro.

Non credo che la perfetta implementazione delle migliori pratiche di un linguaggio di codifica sia la creazione o la rottura di una buona esperienza di lavoro o di una buona squadra: il lavoro che alimenta una carriera è molto più di questo, e se il prodotto ha decenti qualità, il team ha condizioni di lavoro decenti (come il Joel Test) e il team è pieno di persone intelligenti e che fanno le cose, quindi la perfezione dell'implementazione è secondaria. Porta via fattori come un buon lavoro, brave persone, buone condizioni di lavoro - e non vale la pena attenersi - indipendentemente dal fatto che il codice sia stranamente messo insieme.

quanto fondamentale o dogmatico dovrebbe essere? In che misura un programmatore dovrebbe attenersi ai suoi principi o semplicemente scrivere un codice che funzioni?

La cosa più importante da ricordare qui è qual è il tuo scopo ?

Nella maggior parte delle aziende, il tuo scopo nella vita non è scrivere codice perfetto. Il tuo scopo è fornire valore per l'utente. Scrivere un buon codice è di solito il modo migliore per fornire un buon prodotto che è anche facile da mantenere, risolvere i problemi e sviluppare.

Il buon codice è uno strumento che dovresti applicare dove ti dà un buon ROI.

Qualche esempio:

1. Dedicherei molto tempo a progettare e codificare le mie API, in particolare l'API di livello aziendale. Molti altri programmatori li useranno e farà risparmiare molto tempo e problemi se sono progettati correttamente
2. Rilasserò un po 'le regole nel mio livello di presentazione. Lì sarò più propenso a sacrificare la "perfezione" del codice a favore dell'aggiunta di più funzionalità

In conclusione, devi avere dei principi ma dovresti anche essere abbastanza flessibile da infrangere questi principi quando portano più danni che valore.

Ho lavorato per un rivenditore di e-commerce per alcuni anni. Quando ho iniziato lì, il codice per le loro applicazioni interne era tutto scritto in VB per MS Access ed era orribile a dir poco. Avevo un team di 3 sviluppatori e nei prossimi anni lo abbiamo sostituito con le applicazioni VB.Net appropriate.

Ma poiché il mio budget per le assunzioni era estremamente limitato, potevo permettermi solo programmatori junior. E, naturalmente, il codice che hanno prodotto non era poi così eccezionale. Ma ha funzionato e la società ha utilizzato queste applicazioni per fare soldi, ogni giorno.

E poi ho iniziato a lavorare con i miei ragazzi. Un po 'di formazione in OOD, nella progettazione di database, in MVC e C #. E nel corso degli anni, le cose sono migliorate. Quando me ne sono andato dopo 4 anni, la base di codice non era ancora eccezionale, ma era 100 volte migliore di quando ho iniziato.

Una situazione come quella che descrivi è spesso la conseguenza di dover accontentarti delle risorse disponibili. Non viviamo in un mondo ideale. Allo stesso tempo, questa è una grande opportunità per fare davvero la differenza.

A proposito: alcune di queste applicazioni sono ancora in uso, praticamente invariate rispetto a circa 3 anni fa, e fanno ancora soldi.

Penso che attenersi ai tuoi principi sia molto importante. Dovresti sempre cercare di produrre il miglior codice possibile entro i vincoli indicati. Tuttavia, se aggiungi "non dovresti mai leggere o modificare il codice errato" al tuo elenco di principi, avrai molte difficoltà a trovare lavoro. Ricorda che il 50% dei programmatori si è laureato nella metà inferiore della classe. Anche in una squadra di un solo uomo, "oggi tu" è più qualificato per risolvere un problema rispetto a "il mese scorso tu". Essere in grado di lavorare con codice non ideale è solo una parte del lavoro.

Molti datori di lavoro lo riconoscono, quindi il codice che ti danno da leggere potrebbe essere rappresentativo del codice peggiore nella loro base di codice, piuttosto che del loro meglio. Se ciò non è chiaro dal contesto, dovresti chiedere. Un collega con cui a volte intervisto ha una pagina di codice che ha scritto di proposito male solo per essere usato come domanda per l'intervista.

Nel 99% dei casi, dovresti attenersi al «dogma» come lo chiami. Il dogma è creato da persone esperte nel corso di anni di pratica, e ciò che a un certo punto sembrerebbe pragmatico, spesso non lo è. Questo di solito è più rilevante del fatto che non sei abbastanza bravo da gestire correttamente quel problema.

Tuttavia, non seguire il dogma alla cieca. Ricorda quali conclusioni portano le persone a seguire quel dogma. Perché troverai una piccola parte dei casi in cui non dovrebbe essere seguito. Comunque, quei casi saranno molto rari e dovresti sempre discutere con alcuni altri programmatori esperti prima di prendere una decisione del genere.

Sii severo quando conta. Stile di parentesi graffa (o altre convenzioni di codifica)? Non importa Usa quello utilizzato dal negozio. Rompere l'incapsulamento (o altri principi di programmazione fondamentali) senza una buona ragione? Non così banale.

Stack Exchange utilizza le tabelle per il layout (così come molti degli altri principali siti Web che stanno facendo soldi ). Questo fa uscire il fumo dalle orecchie dei puristi? Certo che lo fa. Ma il pragmatismo vince sempre sulla purezza. Il prodotto di spedizione vince vincendolo sempre alla perfezione.

L'intero livello di dominio, livello di persistenza, livello di presentazione, test unitario è ancora relativamente nuovo, da un punto di vista storico. Ci sono un sacco di software là fuori che usano ancora un modello Client / Server e non saranno cambiati all'ultimo stile architettonico solo perché è "migliore".