Che orizzonte temporale e livello di astrazione è il diritto per il software gestibile ed evolutivo?

5

Di tanto in tanto mi sento esausto nei miei sforzi di sviluppo del software perché sono spinto a pensare e sviluppare in modo molto specifico e brevissimo. Un cliente qui e ora richiede una funzione e io dovrei implementarla per lui. Né il cliente, né la gestione della mia azienda sono interessati a investire un po 'di tempo e sforzi nell'indagine su come possiamo rendere questa funzione adattabile e più generale (ad esempio, introdurre la configurazione anziché codificare un ramo della funzionalità) per altri client o per un uso futuro.

Da un lato questa potrebbe essere una decisione commerciale sbagliata. Dall'altro lato è certamente una cattiva decisione delle risorse umane. Gli antichi maestri raggiunsero l'eccellenza proprio perché costruivano o costruivano i loro manufatti per il futuro, per le generazioni a venire, per l'eternità. Forse gli sviluppatori di software possono raggiungere una padronanza ed un'eccellenza simili se sono autorizzati a creare software per l'eternità?

Quindi - ci sono criteri tecnici (best practice, standard di settore, ecc.) per la costruzione di software manutenibile ed evolutivo, criteri che determinano il livello richiesto di generalizzazione e sicurezza per l'implementazione di funzionalità specifiche?

Il mio dominio di applicazione è la contabilità e il software aziendale (backoffice).

    
posta TomR 29.06.2017 - 12:00
fonte

2 risposte

8

Le mie regole empiriche sono:

  • Guido il mio codice con un test di unità per rimanere concentrato sul requisito effettivo, ma significa anche che il codice che evolve attraverso ciascuno di questi passaggi successivi rimarrà corretto.
  • La prima volta che ho bisogno di un codice, produco la cosa più semplice che possa funzionare; seguendo il principio KISS .
  • La prossima volta che ho bisogno dello stesso codice, generalizzo il codice esistente per renderlo riutilizzabile, in genere estraggo un metodo o una classe come necessario e introduco la parametrizzazione e applica principio di separazione delle interfacce .
  • La terza volta, la quarta volta, ecc; Raffinamento l' astrazione . Ho aggiunto altre classi aggiuntive, attenendoci rigorosamente al Principio di responsabilità singola per guidare la loro creazione.
risposta data 29.06.2017 - 12:34
fonte
1

Nor client, nor management of my company are interested in investing some time and effort in investigation

C'è una tua risposta. Per essere corretti, si aspetteranno un sacco di cose che non si pongono come requisiti solo perché "ogni sito web / app / rapporto / qualsiasi cosa lo abbia, mi aspetto che sia come predefinito", quindi è necessario un po 'di lungimiranza.

Se il tuo capo / cliente è contento della tua velocità allora tutto va bene. In caso contrario, o si deve respingere e ottenere tali requisiti dichiarati in modo che si rendano conto in anticipo ciò che stanno chiedendo è complesso. O digita più velocemente.

Ovviamente c'è il problema che potresti scoprire che passi tutto il tuo tempo a svolgere noiose attività di manutenzione anche se il tuo capo è felice.

Ma a quel punto la soluzione è assumere qualcun altro per fare i bit noiosi e convincere il tuo capo a darti solo i pezzi buoni.

    
risposta data 29.06.2017 - 12:39
fonte

Leggi altre domande sui tag