Essere severi o pragmatici?

Question

Essere severi o pragmatici?

#1 da (21 voti)
#2 da (5 voti)
#3 da (4 voti)
#4 da (4 voti)
#5 da (3 voti)
#6 da (3 voti)
#7 da (2 voti)
#8 da (2 voti)

13

Sto iniziando a rendermi conto che lo sviluppo di software è (tra gli altri) un processo in cui ti poni continuamente domande. Domande sulla qualità del codice, separazione delle preoccupazioni, riduzione al minimo delle dipendenze, ...

Ma la domanda principale è: fino a che punto puoi andare senza finire in un ospedale psichiatrico?

Sto facendo domanda per un nuovo lavoro. Ieri ero con un possibile futuro datore di lavoro che voleva testare le mie capacità di programmazione. Uno degli esercizi è stato: 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 effettivamente come si avvicinano le cose ed è stato piuttosto deludente.

Alcuni esempi:

Ho visto da qualche parte: Chiama [inserisci il nome della subroutine qui] - > Sono rimasto colpito: non è qualcosa di VB6?
Hanno un datalayer separato, usando ado.net, ma un metodo che ho dovuto esaminare restituisce un set di dati al livello chiamante. Quindi datalayer separato o no, l'applicazione è legata ad ado.net (che potrebbe anche non essere mai un problema se non passano mai ad un altro approccio di accesso ai dati).
Il set di dati viene letto così com'è, quindi è ancora un approccio incentrato sui dati (ovviamente, si può argomentare quanta logica / comportamento si possa inserire in classi come "Paziente" o "LabAnalysisRequest".
Credo anche di aver visto la costruzione di una query sql tramite concatenazione di stringhe
Usano stored procedure (che, per me, significano: dispersione della logica)
nessuna menzione di viste / controller: è tutto basato sulla forma

La cosa più brutta che ho visto è stata:

    If TestEnvironment.IsTesting then
       someVar = [some hard coded value]
    else
       someVar = [some dynamically retrieved value]
    end if
    [remainder of the function here]

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

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

culture

posta bvgheluwe 17.06.2011 - 16:02

fonte

8 risposte

3

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 è stato a dir poco orribile. Avevo un team di 3 sviluppatori e nel giro di pochi anni abbiamo sostituito questo con le applicazioni VB.Net corrette.

Ma dal momento che il mio budget per le assunzioni era estremamente limitato, potevo permettermi solo i programmatori junior. E, naturalmente, il codice che hanno prodotto non era poi così eccezionale. Ma ha funzionato e l'azienda ha utilizzato queste applicazioni per guadagnare denaro 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 sono partito dopo 4 anni, il codebase non era ancora ottimo, ma era 100 volte migliore di quando ho iniziato.

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

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


risposta data 17.06.2011 - 17:02
fonte

3

Penso che attenersi ai tuoi principi sia molto importante. Dovresti sempre cercare di produrre il miglior codice possibile all'interno dei vincoli dati. Tuttavia, se si aggiunge "non dovrebbe mai leggere o modificare codice errato" nel proprio elenco di principi, si avrà molta difficoltà a trovare lavoro. Ricorda che il 50% dei programmatori si è laureato nella metà inferiore della loro classe. Anche in una squadra di un solo uomo, "oggi tu" è più qualificato per risolvere un problema rispetto al "tuo mese scorso". 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 peggior codice nella loro base di codice, piuttosto che del loro meglio. Se questo non è chiaro dal contesto, dovresti chiedere. Un collega a cui intervengo a volte ha una pagina di codice che ha appositamente scritto male solo per usare come domanda di intervista.


risposta data 06.03.2013 - 02:31
fonte

2

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

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


risposta data 17.06.2011 - 16:07
fonte

2

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

Stack Exchange utilizza le tabelle per il layout (così come molti altri importanti siti web che fanno soldi ). Ciò fa uscire il fumo dalle orecchie dei puristi? Certo che lo fa Ma il pragmatismo vince sulla purezza, ogni volta. Il prodotto di spedizione vince per averlo sempre perfetto,

L'intero livello del dominio, il livello di persistenza, il livello di presentazione, il test di unità è ancora relativamente nuovo, dal punto di vista storico. Esistono pacchetti di software là fuori che usano ancora un modello Client / Server e non saranno modificati secondo lo stile architettonico più recente solo perché è "migliore".


risposta data 06.03.2013 - 02:39
fonte

Leggi altre domande sui tag culture

Cosa fare quando hai esaurito tutte le strade per correggere un bug Linq è più efficiente di quanto appaia sulla superficie?

score 21 · Answer 1

So che non risponde direttamente alla tua domanda, ma ritengo che valga più di un commento:

Quando fai un colloquio di lavoro, stai intervistando tanto quanto ti stanno intervistando . Rompere l'abitudine di vedere un'intervista come qualcosa che ti striscia sulla pancia supplicando che ti offrano qualcosa. Ti fanno il checkout, ma li controlli . Se non ti piacciono, non ti assumeranno. Se non ti piacciono, non andare a lavorare lì.

Sì, nel settore, con una base di codice legacy vecchia di dieci anni che è stata hackerata nel tempo da tre dozzine di sviluppatori con background, competenze e passione diversi, guidati da scadenze serrate, mancanza di risorse e vincoli finanziari, il codice non sembrerà mai come dovrebbe (dovrebbe) aver imparato che dovrebbe apparire. Dovrai fare alcune concessioni. Ma quanti, e dove tracciate la linea, ciò dipende totalmente da voi.
Ovviamente, i lavori sono più difficili da trovare meno concessioni. Ma potrebbero essere più divertenti.

FWIW, ho finora (> 10 anni nel settore) non ha mai lavorato in una grande azienda con molti sviluppatori (~ 30 sviluppatori era il massimo, una dozzina la norma), perché è molto più probabile che tu cambi qualcosa in una piccola azienda. Fintanto che guadagno abbastanza per non far morire di fame i bambini, non vorrei essere una piccola ruota dentata in una grande azienda, dove tutto ciò che devo fare è sincronizzare il resto degli ingranaggi.
Ho rifiutato le offerte di lavoro dopo aver visto i test che volevano che io passassi. Sono uno sviluppatore C ++, e ci sono molti test C ++ là fuori che sono così brutti che rendono le tue unghie arricciate con disgusto, e non voglio passare il mio tempo a combattere i mulini a vento perché hanno ingannato idioti che non sanno scrivere codice pulito.
Ho anche lasciato lavoro dopo alcuni mesi perché la loro filosofia di programmazione (obiettivi a breve termine, non importa il prossimo anno) non si adattava alle mie capacità (stabilità del codice a lungo termine), nonostante dicessero diversi nell'intervista.

score 5 · Answer 2

Non scrivere mai codice che fa solo il lavoro. Comunque sia ugualmente disposto ad esaminare la tua dottrina. Solo perché l'hai imparato a scuola, non significa che sia il pensiero corrente o il pensiero valido. Il ciclo di vita del design del software è diventato obsoleto, poiché la programmazione deve essere più reattiva al mondo del business. A volte le soluzioni software collegate in modo maldestro sono collegate in modo maldestro perché le parti sono state sostituite nel tempo consentito.

Ecco un elenco di problemi che ho elaborato che determineranno quanto bene ti adatti allo stile di vita di codifica di un'azienda.

Quanto apprezzano l'impostazione del tempo da parte del refactoring e l'aggiornamento del loro code-base. Il modo in cui visualizzano l'aggiornamento del codice base sarà un fattore determinante per la tua capacità di adattamento.
Quanto spesso acquistano terze parti anziché codificarle internamente.
Cosa pensano del software open-source. Si rendono conto che hanno flessibilità nel modificare il codice. Lo vedono allo stesso modo dell'acquisto di terze parti.
Lavorerai su un certo livello di astrazione. Il team con cui ti interfacciati determina la tua interfaccia per te? Quale livello / squadra / lato dell'interfaccia ha più potere decisionale.
Quanto il supervisore ascolta i programmatori quando prende decisioni. Quando un programmatore lancia una bandiera rossa, il supervisore si ferma e rivede la sua decisione.
Considerate i programmatori esperti di gestione? Come vedono la loro esperienza? La loro esperienza è valida? Stanno lasciando che l'esperienza obsoleta influenzi il processo decisionale?
Quanto è appiccicoso il code-base?
Quanto spesso 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 scontri con il loro stile e il tuo processo decisionale.

score 4 · Answer 3

Penso che tu debba pesare questo 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 'grossa C. Era ancora molto funzionalmente progettata in natura e dovevo andare a prendere un libro di C per insegnare a me stesso printf e getf e altri meccanismi C che non avevo mai imparato . Il fatto che nessuno sulla squadra abbia mai capito quanto C piaccia il loro codice indicava come questo "design C ++" fosse caduto. Il mio obiettivo in quel momento era fare lo sviluppo OO, quindi questo è stato un po 'scoraggiante.

Ma sono contento, alla fine, di essere rimasto con la squadra. Erano un gruppo dinamico di persone molto intelligenti e mi sono bagnato i piedi con un sacco di problemi difficili, ho avuto modo di lavorare per tutto il ciclo di vita e le cose che ho imparato riguardo al dominio del problema (PKI) hanno alimentato la mia carriera da allora. Il lavoro che il team stava svolgendo nello spazio funzionale è stato sorprendente e continuo a pensare molto affettuosamente a quel prodotto e all'esperienza lavorativa. Meglio ancora - lavoro ancora con alcune di quelle persone oggi (diverse aziende dopo), sono ancora un'ispirazione e stiamo ancora facendo un buon lavoro.

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

score 4 · Answer 4

how fundamental or dogmatic should one be? To what extent should a programmer stick to his or her principles or just write code that does the job?

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

Nella maggior parte delle aziende, il tuo scopo nella vita non è quello di scrivere un codice perfetto. Il tuo scopo è fornire valore all'utente. Scrivere un buon codice è di solito il modo migliore per fornire un buon prodotto che sia anche di facile manutenzione, risoluzione dei problemi e sviluppo.

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

Alcuni esempi:

Trascorrere molto tempo a progettare e codificare le mie API, in particolare l'API del livello aziendale. Molti altri programmatori li useranno e risparmierà un sacco di tempo e problemi se sono progettati correttamente

Rilascerò un po 'le regole nel mio livello di presentazione. Lì sarò più propenso a sacrificare il codice "perfetta" a favore dell'aggiunta di ulteriori funzioni

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

score 3 · Answer 5

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 è stato a dir poco orribile. Avevo un team di 3 sviluppatori e nel giro di pochi anni abbiamo sostituito questo con le applicazioni VB.Net corrette.

Ma dal momento che il mio budget per le assunzioni era estremamente limitato, potevo permettermi solo i programmatori junior. E, naturalmente, il codice che hanno prodotto non era poi così eccezionale. Ma ha funzionato e l'azienda ha utilizzato queste applicazioni per guadagnare denaro 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 sono partito dopo 4 anni, il codebase non era ancora ottimo, ma era 100 volte migliore di quando ho iniziato.

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

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

score 3 · Answer 6

Penso che attenersi ai tuoi principi sia molto importante. Dovresti sempre cercare di produrre il miglior codice possibile all'interno dei vincoli dati. Tuttavia, se si aggiunge "non dovrebbe mai leggere o modificare codice errato" nel proprio elenco di principi, si avrà molta difficoltà a trovare lavoro. Ricorda che il 50% dei programmatori si è laureato nella metà inferiore della loro classe. Anche in una squadra di un solo uomo, "oggi tu" è più qualificato per risolvere un problema rispetto al "tuo mese scorso". 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 peggior codice nella loro base di codice, piuttosto che del loro meglio. Se questo non è chiaro dal contesto, dovresti chiedere. Un collega a cui intervengo a volte ha una pagina di codice che ha appositamente scritto male solo per usare come domanda di intervista.

score 2 · Answer 7

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

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

score 2 · Answer 8

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

Stack Exchange utilizza le tabelle per il layout (così come molti altri importanti siti web che fanno soldi ). Ciò fa uscire il fumo dalle orecchie dei puristi? Certo che lo fa Ma il pragmatismo vince sulla purezza, ogni volta. Il prodotto di spedizione vince per averlo sempre perfetto,

L'intero livello del dominio, il livello di persistenza, il livello di presentazione, il test di unità è ancora relativamente nuovo, dal punto di vista storico. Esistono pacchetti di software là fuori che usano ancora un modello Client / Server e non saranno modificati secondo lo stile architettonico più recente solo perché è "migliore".