Talvolta è ragionevole tagliare gli angoli e aspettarsi di riscrivere il software tra un paio di anni? [duplicare]

Sì, ci sono sicuramente situazioni in cui ha senso creare un codice "usa e getta" sporco e rovinoso con l'intento di lanciarlo dopo un paio d'anni e ricominciare da capo. Forse la tua azienda sta cercando di dimostrare rapidamente un nuovo modello di business e vuole avere un'idea della reazione del mercato a un "prodotto di prova". Forse c'è un mercato non sfruttato e ottenere un prodotto fuori dalla porta (time to market) vince le preoccupazioni sul costo di proprietà a lungo termine (manutenzione).

Ma ecco la parte importante: come programmatore non è questa la tua decisione da prendere . Le ragioni sopra riportate sono aziendali per le quali potrebbe essere fattibile. Il tuo compito è implementare il codice in base ai requisiti aziendali e tali requisiti aziendali includono qualità architettoniche come costi di manutenzione, time-to-market, scalabilità, ecc. C'è un equilibrio da raggiungere in termini di time to market rispetto al costo di proprietà, ma giocano l'uno contro l'altro e non è una risposta valida per tutti. Il tuo compito è quello di elevare questi punti all'azienda, provare a fare del tuo meglio per evidenziare le diverse opzioni e i diversi costi e tempi di commercializzazione, e poi agire in base a qualsiasi decisione commerciale.

Nel tuo caso specifico sembra che tu decida di riscrivere più e più volte la stessa logica di business per risparmiare tempo sul mercato delle app - non penso che abbia senso nel caso generale. È quasi sempre molto difficile estrarre tutto della logica aziendale (ricorda che è necessario un campo che hai evidenziato con un bordo rosso nelle regole CSS - questa è logica di business da un certo prospettiva) e riprenderlo di nuovo in una seconda app. Mi piacerebbe mantenere la prima app in questo caso.

Dopo 2-3 anni avrai un'applicazione in cui avrai investito 2-3 anni di tempo di sviluppo. Cosa ti fa pensare che ricrearlo da zero richiederà molto meno tempo? Forse a causa di una maggiore esperienza con il dominio puoi passare a 1 anno, ma è ancora molto tempo. Cosa farai mentre riscrivi l'app: dì ai tuoi clienti che non ci saranno correzioni di bug e nuove funzionalità per un anno? Non funzionerà.

Le insidie? Hai l'opportunità di creare l'ambiente di lavoro di tua scelta. Non vedo come la creazione di codice che non è facile aggiungere funzionalità rende la vita più facile. La maggior parte degli sviluppatori disprezza e cerca risposte su come riparare un software poco sviluppato.

Il tuo predecessore ha scelto di usare le cattive pratiche e tu vuoi fare lo stesso. È ovvio che la tua azienda non ha idea di come creare e gestire software o sviluppatori.

A meno che tu non sia sotto pressione per apportare modifiche più velocemente a prescindere dalla qualità, non vedo perché vorresti intraprendere questa strada. Scrivi un codice di cui puoi essere orgoglioso. Se la compagnia non lo apprezza, sembra che il tuo soggiorno sia temporaneo. La vita è troppo breve per scrivere codice errato.

Modifica - Non sto sostenendo che devi scrivere il codice più bello del mondo (come ha sottolineato MichealT), ma cogli ogni occasione per fare del tuo meglio e continuare il processo di miglioramento.

I'm wondering if in an environment like this it'd be more feasible to cut corners and churn out web applications (I'm not sure about desktop applications) with the intent of re-writing them every 2-3 years. I mean cutting corners in things like unit tests and architecture.

Sono d'accordo che è allettante tagliare gli angoli e sfornare le applicazioni web di 2-3 anni, anche se mi chiedo se hai provato questo ciclo un paio di volte per vedere cosa succede? Gli angoli taglienti sono un fattore che contribuisce a ciò che porta ai problemi che stai affrontando ora, ti rendi conto, giusto?

I'd expect such applications to be hard to maintain over a long term, and that'd be ok, because we'd just rewrite from scratch and copy and paste any business logic we needed to carry forward - as long as the requirements, documentation, and the data modeling is solid.

Ti sei imbattuto in casi in cui parte della logica di business gestita dal comportamento predefinito si riempie di bug in una nuova versione della lingua o della piattaforma perché le cose sono state aggiornate? Che tipo di modifica avresti per gli utenti dell'applicazione? Questo potrebbe essere il punto più importante in quanto mentre puoi riscrivere le viscere dell'applicazione, se il modello di dati cambia molto, quanto gestisci la conversione di tutti quei dati?

Vorrei anche chiedermi se dopo un paio di round di questo, quanto è buono chiunque mantenga tutti i requisiti e la documentazione aggiornati che mentre si ha un "finchè ..." che da alcuni manager potrebbe non essere il più alto di una priorità e quindi abbiamo più problemi di capitalizzazione.

In uno dei miei precedenti lavori, abbiamo impiegato 2 anni per avviare la prima fase di un nuovo sistema di gestione dei contenuti. In tal caso, provare a riscriverlo ogni 2-3 anni non funzionerebbe bene perché la società pagherà milioni di dollari per il progetto se si sommano tutte le licenze, i costi di manodopera e altre cose. Quindi, può valere la pena considerare quanto tempo impiega una riscrittura come se ci volesse qualche anno, quindi ti occuperai per sempre di sistemi paralleli, no? C'è un attuale sistema live che viene ottimizzato e il prossimo è ancora in costruzione in un dato momento. Dubito che tu intenda questa situazione, ma è un modo per interpretare quello che stai facendo qui.

Joel Sposky ha scritto sul software di riscrittura alcuni anni fa che potrebbe valer la pena di leggere per vedere quanto sono applicabili i suoi punti su questo.

In primo luogo, è così che si è verificato il bug Y2K. Ma continuiamo.

Stai andando a sovrastimare drasticamente la quantità di tempo fino a quando un angolo torna a morderti. Se tagli un angolo, pensi che ci vorranno anni fino a quando non hai un problema con esso ? O qualche giorno dopo, quando esegui una patch di errore sul codice, hai pensato che non avresti dovuto toccare di nuovo? Fare cose sbagliate significa dover passare un po 'di tempo ogni giorno a preoccuparsi di questo.

Ma più in generale, sembra che tu l'abbia inquadrato in modo molto autolesionista. Sei sotto pressione per fare le cose "più velocemente" e tagliare le curve? Se è così, allora devi migliorare le tue capacità di business al punto che puoi dimostrare al tuo manager che "tagliare gli angoli" è non il modo più veloce per fare le cose. Non sei affatto sotto pressione? Allora cosa si può guadagnare dalle curve di taglio? Questo è un modo molto YOLO di vivere, dove si assume che "Sarò morto per allora!" e ... beh, sono solo vivi e in cattive condizioni di salute, e nel frattempo non mi sono piaciuti particolarmente la vita. È davvero divertente per te tagliare gli angoli? Probabilmente no. In realtà sembra che ti renda insoddisfatto del tuo lavoro, quando potresti passare lo stesso tempo a essere soddisfatto del tuo lavoro facendo un buon lavoro e finire con un curriculum e un set di abilità molto migliori. Quindi raccomando strongmente contro questa strategia, se puoi chiamarla così.