Persuadere la gestione che una buona ingegneria del software vale lo sforzo [duplicato]

Question

Persuadere la gestione che una buona ingegneria del software vale lo sforzo [duplicato]

#1 da (3 voti)
#2 da (1 voti)

3

Background: lavoro per una piccola azienda che non ha una serie di best practice consolidate per la progettazione di software. Sono stato assunto per lavorare su un progetto che raccoglie dati da un flusso, esegue un processo di elaborazione e aggregazione e li scrive nel database. Dovrebbe alla fine aiutare a sostituire un vecchio sistema che è fondamentalmente molte migliaia di righe di codice spaghetti. Insieme a un collega, abbiamo progettato e realizzato qualcosa che considero una buona base per un sistema che sia estensibile, verificabile e stabile.

Il problema: lo sviluppo dell'ultima funzione ha richiesto circa 15 giorni di lavoro e la situazione era piuttosto alquanto rigida per quanto riguarda il rispetto della scadenza quando la funzionalità sarebbe stata dimostrata al cliente. Un tizio più anziano "viene in soccorso" e costruisce la stessa funzione in tre giorni, usando lo stesso stile di codifica e l'approccio generale usato nel vecchio sistema. Il risultato è altrettanto mostruoso dell'originale, ma questo non è visibile al management, chi certamente chiederà perché non siamo così produttivi come questo ragazzo. La nostra soluzione ha comunque rispettato la scadenza, ma nel frattempo l'interfaccia utente è stata cablata per mostrare i dati di questa nuova soluzione.

È molto facile essere un codificatore di cowboy e scrivere codice senza test, nessuna protezione contro situazioni impreviste e non reali struttura. Il nuovo codice sfugge allo scenario felice e fa il minimo necessario per ottenere il database corretto (ma come sappiamo?)

Come posso convincere il management che questa pratica è estremamente dannosa e che una buona ingegnerizzazione del software inizierà molto presto a pagare dividendi? Ci sono dei buoni esempi che potrei menzionare per supportare il mio caso?

management project-management programming-practices technical-debt

posta JohnEye 04.07.2018 - 17:32

fonte

2 risposte

Leggi altre domande sui tag management project-management programming-practices technical-debt

CQRS + Event Sourcing come architettura di primo livello: anti-pattern Servizio applicazioni - parte del Contesto Limitato?

score 3 · Answer 1

Non è facile essere un codificatore di cowboy. Solo tu capisci il codice base. Anche tu sei ostacolato dalla resistenza del tuo codice a cambiare. E i tuoi colleghi programmatori lamentano costantemente che niente ha senso.

Il problema è che la gestione non capisce la qualità del codice. Non lo fanno mai. Non lo faranno mai. Perché dovrebbero? Non è il loro lavoro.

Quando la mia auto non comincerà e la porterò dal meccanico se mi verrà detto che sarà pronta tra una settimana, mi aspetterò in una settimana. Non voglio presentarmi e mi viene detto che devo aspettare un mese perché i motorini di avviamento importati dalla Germania sono i migliori.

Se stai pensando di legare la mia macchina per un mese, dimmelo il primo giorno. Una volta che prometti una settimana avresti dannatamente meglio avere un modo per essere fatto in una settimana. Se lo chiedo in una settimana, è meglio che tu dica no adesso. Se sei in competizione con un altro negozio che garantisce di essere fatto in una settimana, è meglio capire come puoi offrire di essere fatto in una settimana.

Quello che spieghi è che cosa otterranno se lo vogliono fare in una settimana contro quello che ottengono se ti danno un mese. Non puoi decidere questo. Devi imparare a lavorare in entrambi i modi.

Dammi un antipasto scadente oggi e se tengo alla qualità talmente tanto che tornerò tra un mese per farti una bella figura.

Questo è tutto ciò che puoi fare con la gestione. Chi, come ho detto, non lo capirà mai veramente.

Quello che dovresti fare è andare e imparare tutto quello che puoi da quel codificatore di cowboy. Smetti di comportarti come se i tuoi libri fossero più intelligenti di quel tipo. Chiedigli quali problemi ha attualmente. Chiedi come evita i problemi che vedi nei suoi progetti e cosa pensa dei cambiamenti che vorresti fare. Se vedi un modo migliore, non vergognartene. Mostra a lui. Lascialo decidere che in questa situazione è davvero una buona idea. Fagli un compagno. Non la concorrenza.

Se non lo fai, sprecherai un sacco di tempo e di energia a spingerlo a combattere contro di lui mentre continui a rovinarti a vicenda. La soluzione migliore è metterlo dalla tua parte prima di provare a convincere la gestione di qualsiasi cosa.

Se la qualità del codice è corretta, la gestione non lo noterà mai.

score 1 · Answer 2

Vado qui a difendere i diavoli. Mi è piaciuta la risposta di candied_orange; fa notare che potresti imparare qualcosa dal "coder dei cowboy".

Io sostengo che se il presunto "codificatore di cowboy" sta veramente lavorando con "codice spaghetti", è improbabile che il programmatore sia in grado di essere più produttivo di un coder non-cowboy che lavora con codice pulito. E quando dico "codice pulito", lo intendo nel senso tradizionale (il più semplice possibile), non pieno di tecniche standard di culto come "SOLID".

Pensi di poter competere con il "coder dei cowboy" per progetti a lungo termine? In caso contrario, è necessario tornare indietro ed esaminare il vecchio codice e parlare con il codificatore del cowboy, perché il nuovo codice è un errore e il vecchio codice potrebbe non essere così brutto come si pensa. Se il nuovo codice è migliore, sarai più produttivo, perché un codice migliore è sempre più semplice e più piccolo. Se non è più semplice e più piccolo, ti suggerisco di riconsiderare l'intera visione dello sviluppo del software.