Impostazione delle priorità di codifica

Penso che la prima domanda che un programmatore dovrebbe porre sia: "Devo scrivere questo codice?" Viviamo in un mondo ricco di software preesistente, robusto, open source. Prima di scrivere la tua biblioteca o applicazione, dedica un po 'di tempo a cercare quello che qualcun altro ha già trascorso mesi o anni a sviluppare.

È sempre un atto di bilanciamento tra i requisiti aziendali e la manutenzione dell'applicazione.

In alcuni casi la priorità è fuori dal tuo controllo. Non hai altra scelta che aderire ai requisiti aziendali, ad esempio, per motivi legali o per risolvere problemi importanti.

In altri casi deve esserci una negoziazione tra i requisiti aziendali e gli effetti a lungo termine (negativi?) che possono avere sul sistema. Qualcuno, un responsabile dello sviluppo per esempio, dovrebbe rappresentare le preoccupazioni del dev shop e gestire il lavoro di sviluppo basato su compromessi (si spera) in questi casi.

Poi ci sono momenti in cui la priorità è sotto il tuo controllo. Quindi spetta a te gestire il tuo tempo in modo efficace e consegnare ciò che ti è stato chiesto.

Quindi un po 'di spettro nella gestione delle priorità. Man mano che acquisisci più esperienza, vedrai come funzionano le cose in diverse situazioni. Nel frattempo, sii consapevole, esprimi le tue preoccupazioni come necessario e continua a fare ciò che sai fare meglio (-:

HTH e buona fortuna,

KM

La domanda, così com'è, sarà difficile da rispondere, perché la manutenibilità ha molte sfumature.

Ho identificato 3 livelli di manutenibilità:

1. codice leggibile
2. evitando la ripetizione
3. Architettura / refactoring

Il primo livello è molto semplice e non costa tempo di sviluppo. Significa semplicemente che ogni volta che scrivi nuovo codice (o leggi il codice precedente), lo rendi leggibile il più possibile, magari aggiungendo / modificando alcuni commenti mentre vai.

Il secondo livello è meno semplice, ma non troppo travolgente. Significa semplicemente che ogni volta che aggiungi una parte di codice, devi controllare se non c'è già qualcosa che fa ciò che stai per fare. Se c'è, unisci le cose comuni (fantastico, non hai dovuto scrivere!). Ciò eviterà la ripetizione del codice, il che significa che durante il fixing non dovrai propagare la correzione nelle n copie.

Il terzo livello è decisamente più costoso. I cambiamenti architettonici e il refactoring su larga scala esauriscono rapidamente alcuni giorni di lavoro.

Con questo elenco in mente, è un po 'più gestibile da discutere.

• se sei di fretta, basta applicare 1. e 2. e non preoccuparti dell'architettura (a meno che tu non ne abbia uno ovviamente, nel qual caso basta creare il più semplice che risolva il problema problema)
• quando hai qualche giorno libero, o quando non sei sotto pressione, considera il refactoring se possibile

Per abilitare il secondo, tendo a mantenere un elenco TODO di ciò che vorrei cambiare ma che non ho il tempo di fare adesso. Poi, quando avrò un po 'di tempo tra le mie mani, o quando si presenterà l'opportunità di lavorare su un pezzo di codice che appare in questa lista e posso spremere qualche giorno di mantenimento, procedo.

È sempre un compromesso, dovrai imparare a conviverci. L'azienda ha bisogno di vendere roba, sia il software stesso che i servizi che produce. Il time to market può essere molto importante per l'azienda che paga il tuo stipendio. Un prodotto ragionevole quando è necessario è molto meglio di un prodotto perfetto consegnato troppo tardi.

Se sei uno sviluppatore junior non dovresti calcolare il giusto compromesso, questo è per i manager. Potresti dargli qualche input però.

Il costo principale associato ai progetti software è la complessità. Questo costo si ripaga nella difficoltà di produrre software, il costo per mantenere il software e il costo dei progetti falliti, tra gli altri.

La priorità principale della maggior parte dei team di sviluppo software dovrebbe essere quella di ridurre la complessità.

Hai ragione nel dire che il cliente ha sempre ragione, tuttavia il fattore che rimane è l'aspettativa di vita del prodotto e le esigenze del cliente.

Ad esempio, se stai lavorando su una funzione che l'utente ha bisogno al più presto, è probabilmente meglio lavorare sulle funzionalità ora e perfezionare le prestazioni in un secondo momento. Tuttavia, con il passare del tempo, la manutenibilità diventa importante, poiché è importante assicurarsi che la funzionalità continui a funzionare.

(Fonte: anch'io sono uno sviluppatore giovane)

Uno dei maggiori fattori dal punto di vista della mantenibilità è: quanto tempo verrà utilizzato questo software? E questa è spesso una domanda difficile a cui rispondere, non solo perché il software tende a sopravvivere al tempo e all'utilizzo originariamente previsti.

Il software che ha una vita operativa breve può in teoria essere meno manutenibile. - Applicare avvertimenti!

Non è raro che gli sviluppatori restino intrappolati nei dettagli e perdano l'immagine generale (e sì, sono un dev e sono colpevole di essere accusato, m'lud), o di 'diventare scuro' e avere oro -plate dove non è richiesto.

Qual è il limite principale del progetto? È tempo, denaro, sicurezza operativa?