Il codice viene continuamente riscritto ed è quindi inutile preoccuparsi della qualità delle prime iterazioni del codice di riscrittura?

In the University one of the lecturers ..

Sembra un accademico che soffre dell'effetto Dunning-Kruger . Ma forse hai semplicemente frainteso alcune delle sue affermazioni.

Rewriting code, even in another programming language and under changed requirements, is not hard once you have a working prototype

Quando solo ha un prototipo funzionante, e quel prototipo non è molto grande, riscrivere il codice probabilmente non è troppo difficile, perché non c'è molto da riscrivere . Tuttavia, una volta ottenuto un software di successo sviluppato in diversi mesi e anni, e una solida base di utenti, una riscrittura completa diventa sempre più difficile. Fa la differenza se si tenta di riscrivere 1k LOC, 20kLOC o 400k LOC, e che la saggezza è in gran parte indipendente dal linguaggio di programmazione. E sono sicuro che le principali società di software come Google o Microsoft non gettano ogni anno il codice di tutti i loro principali prodotti e lo riscrivono da zero, che semplicemente non sarebbe economico.

what is hard is making this working prototype

Realizzare un primo prototipo è sicuramente più difficile che farlo la seconda volta quando hai il primo costruito prima e finché qualcuno non cade nella trappola del effetto secondo sistema . Ma la parte davvero difficile viene dopo - realizzare un prodotto stabile e di qualità. E dal momento che hai citato Joel Spolsky, lascia che lo citino anche: un buon software richiede dieci anni .

Instead, focus only on making a working prototype, without caring for anything else; then, once you have it, make an informed decision how to fix the code and how to adjust it for your particular requirements and rewrite your code accordingly, this time caring for its quality.

Naturalmente, il "time-to-market" è spesso molto più importante della qualità del codice quando si introduce una nuova idea in un mercato concorrente, è vero. I prototipi sono importanti per scopi dimostrativi, marketing, proof-of-concept. Sostituire il primo prototipo con una versione completamente riscritta potrebbe essere l'approccio più ragionevole. Non riscrivendolo quando la qualità del codice è stata sacrificata per ottenere la cosa fuori dalla porta durante la prototipazione, forse è un enorme fallimento, ma spesso gli sviluppatori devono convincere i loro superiori su questo, altrimenti sono costretti a costruire un intero sistema su quel prototipo, senza possibilità di passare a un'architettura diversa.

If your product is succesfull enough to enter the maintenance phase you will also be periodically rewriting code whenever a need for a relatively major change arises.

In primo luogo, ridirai costantemente il codice di tale prodotto. Puoi anche riscriverne alcune parti di volta in volta, se l'evoluzione a piccoli passi non sembra più possibile o abbordabile. Ma sicuramente vuoi evitare di buttare tutto nella pattumiera e ricominciare tutto da capo. Cercando di portare a quel tipo di desaster menzionato in Joel Spolsky's saggio che hai già menzionato.

This lecturer insisted that his pupils do not care too much about decisions like the choice of the programming language, target platform, or other design choices that are not strictly necessary to make a working prototype.

Questa raccomandazione va bene, almeno per questo pubblico. Non dimenticare in un'università, gli alunni in genere non iniziano uno sviluppo a lungo termine per alcuni prodotti commerciali, iniziano con progetti di apprendimento e il 99,9% di questi verrà gettato via, indipendentemente dalla qualità del codice.

Quindi TLDR; la maggior parte di ciò che il tuo docente ha detto va bene se applicato a piccoli prototipi , nel suo ambiente accademico, ma non dovresti interpretarlo male come una raccomandazione o una scusa per sacrificare la qualità del codice in sistemi software commerciali più grandi. / p>

Un'ultima nota su

... write it in Python if we like Python even if we know that Python is unavailable for our target platform.

Con quale frequenza incontri una situazione in cui un prototipo deve essere creato su una piattaforma così diversa dalla piattaforma di destinazione che Python non è disponibile su quest'ultimo, ma ha senso usare Python sul primo? Non che tali situazioni non si verifichino, ma questo mi sembra molto forzato.

Questo è qualcosa che sarei molto diffidente in una società privata. Personalmente ho riscontrato diverse volte che è stato realizzato un prototipo "veloce e sporco" e che il "prototipo" è stato successivamente venduto come software completamente funzionante.

Molto spesso, in queste circostanze, è disponibile pochissimo tempo per riscrivere sin dall'inizio, così il tuo prototipo diventa lucido e poi spedito, aggiungendo la linea di fondo per la società.

In breve, mentre la prototipazione può essere un po 'approssimativa, è necessario tenere sempre d'occhio il prodotto finale.

Vorrei notare che codificare attivamente il tuo prototipo in una lingua che non è disponibile sulla piattaforma su cui sarà spedito sembrerebbe un modo per aggirare questo problema, tuttavia non è probabile che ti renda troppo popolare con la gestione ...

Quello che trovo è che quando viene presentato con 2 estremi la risposta è di solito da qualche parte nel mezzo. Un'altra ottima lettura sarebbe La Cattedrale e il Bazar , che in apparenza sembrerebbe far eco al tuo professore dichiarazioni. Penso che l'intento dietro ciò che il tuo professore stava affrontando è questo:

Stop worrying about how to start and get something written.

La paralisi per analisi è un problema molto reale a cui gli studenti cadono. È perché hanno troppa teoria e non abbastanza pratica del mondo reale. Prendi alcune pratiche del mondo reale per scoprire se effettivamente ciò che pensi dovrebbe funzionare.

Se si fermasse lì, non credo che ci sarebbe stata alcuna confusione.

Ci sono alcune affermazioni che necessitano di chiarimenti:

• Il software del mondo reale viene riscritto regolarmente, ma non così regolarmente come i commenti del tuo professore sembrerebbero indicare
• I progetti degli studenti non sono realmente intesi come opere d'arte, sono abandonware - scritti per un compito e mai più toccati
• Se ti capita di avere una buona idea da un progetto scolastico che pensi di poter fare in un prodotto reale, è probabilmente meglio scriverlo con questo in mente

Tuttavia, nel mondo reale, dovrai mantenere il software che altre persone hanno scritto. Il fatto che non venga eseguito nel modo in cui l'avresti fatto non significa che sia cattivo o che debba essere riscritto. Quando una società è disposta a riscrivere il software è a causa di un motivo principale:

The cost of rewriting the software to enable the current needs is less than shoehorning the feature in to the software.

La maggior parte degli sviluppatori che conosco sono molto scrupolosi riguardo alla stesura del software, nonché strutturati e progettati come possono nei limiti del programma e dei vincoli di abilità che hanno. Tendono a lavorare in modo iterativo, costruendo nuove funzionalità in un po 'alla volta. Se il programma lo consente, preferiscono ripulire il refactoring man mano che procedono. Sfortunatamente, il programma e le pressioni da parte della direzione per fornire forza alcuni per tagliare alcune curve con soluzioni "abbastanza buone". Se non avessimo il programma, i cicli di rilascio potrebbero essere troppo lunghi per essere competitivi.

Lo troverai:

• Se lo fai abbastanza presto, la maggior parte della bruttezza del software può essere risolta con piccoli refactoring
• Se ti concentri sul fatto che ti basta per soddisfare le tue esigenze, puoi pulire mentre vai

Ricorda che ogni brutto software di lavoro supera ogni volta il software non funzionante ben architettato.

Penso che potresti aver frainteso l'affermazione del tuo docente secondo cui "il codice viene continuamente riscritto".

Se viene scoperto un errore nel codice di produzione, non si butta fuori tutto e si ricomincia. Trovi il bug, lo aggiusti, lo collaudi, lo distribuisci. E questo è molto difficile da fare se il codice è un pasticcio illeggibile.

Detto questo, è importante distinguere tra codice prototipo e codice di produzione. Se stai solo esplorando un concetto, allora va bene che il codice del prototipo sia approssimativo. Tuttavia, nel momento in cui decidi che vale la pena trasformare il concetto in un prodotto completo, allora sì dovresti riscriverlo in un'ottica di stabilità e manutenibilità.

Mentre le opinioni del docente suonano pazzesche, hanno senso nel contesto.

L'unico punto importante è che il tuo "prodotto" potrebbe non essere la tua attività. Potrebbe essere solo un servizio abbastanza piccolo da riscrivere potrebbe essere una buona idea invece di costruire un hack su hack. Questo è il caso sia in Google che in WoW. Non sono enormi monoliti, ma composti da molti piccoli servizi interconnessi, in cui ciascuno può essere riscritto indipendentemente. Questo è il motivo per cui i microservizi stanno diventando popolari al giorno d'oggi. Avere ogni microservizio costruito usando un linguaggio diverso o su stack diversi non solo è possibile, ma anche raccomandato. Il problema qui è che l'esperienza di molte persone con il software è con enormi monoliti. In tal caso, l'idea di riscrittura è pazzesca come sembra. Quindi, per rendere questo tipo di "riscrittura quando necessario" la mentalità, l'intero prodotto deve essere diviso in parti piccole e liberamente accoppiate. Che non è così comune nel nostro settore.

Un'altra cosa che viene in mente è che la qualità non significa solo la qualità del codice. La qualità del software è un concetto ampio, che comprende codice, test, documentazione, ecc. E il test è la parte importante qui. Se il tuo codice ha una solida serie di test automatici, riscriverlo è banale. Ma ancora una volta, questo non è qualcosa che viene gratis. I buoni test sono costosi e difficili da creare. Ma una volta che li hai, il codice diventa flessibile come lo stucco. Diventa troppo facile da refactoring o addirittura completamente riscrivere parti della vostra applicazione senza preoccuparsi di rompere nulla. E credo che sia Google che WoW abbiano grandi suite di test automatizzati.

Per riassumere: l'idea che il codice possa essere drasticamente cambiato o persino riscritto è valido e persino incoraggiato, quando si assicura che l'intero prodotto sia suddiviso in piccole unità liberamente accoppiate e si impegna a costruire e mantenere test automatizzati per quelle unità.

Naturalmente, questa è solo la mia interpretazione colorata dalla mia esperienza. Potrei sbagliarmi e il docente è davvero pazzo e le sue idee sono insostenibili.

Probabilmente ha esagerato un po ', tuttavia ci sono alcuni verità su di esso.

• "analisi-paralisi": ci sono così tante possibili scelte e modi per sviluppare qualcosa che a un certo punto potrebbe sembrare controproducente quello che sembra troppo lungo per la migliore integrazione tecnologica. Forse se hai appena scelto il primo "ok", avresti già finito l'operazione entro il tempo che avresti impiegato per valutare tutte le possibili tecnologie.

• "roadblock inattesi". Non puoi prevedere tutto. E se hai investito veramente tanto tempo nella costruzione di una "soluzione" ottimale, solo per scoprire in seguito che alcuni dettagli causano problemi reali, lo sforzo o è tutto sprecato o diventa molto dispendioso in termini di tempo. Fare una prototipazione precoce è un ottimo modo per esplorare ciò che ti aspetta, comprese le insidie.

• "ritorni anticipati". Un prototipo è molto utile, sia come prova del concetto. Forse dovresti riscriverlo tutto (e meglio) la prossima volta, ma hai guadagnato informazioni preziose, feedback, modi per migliorarlo ... e forse il tuo progetto non sarebbe nemmeno a galla altrimenti perché la soluzione "giusta" sarebbe stato troppo dispendioso in termini di tempo.

• "tecnologie obsolete". Soprattutto per i progetti più grandi, al momento in cui lo finisci, è probabile che molti strumenti, tecnologie, API e librerie siano progrediti fino al punto in cui la tua attuale soluzione sembra obsoleta. Una volta lavoravo per una società che ha trasformato enormi codebase dall'assemblatore in C, poi in C ++, e probabilmente ora C # e in un decennio cambierà anche. Allo stesso modo, le GUI JAVA vengono trasferite su web tech, i web tech vengono portati su dispositivi mobili nativi e così via, e così via.

... quindi, beh, sì, si tratta di trovare il giusto equilibrio tra pianificazione e attività.

Durante la prototipazione di un pezzo piccolo di un grande progetto, i commenti del tuo docente sono giusti.

Ad esempio, quando lavoravo in una società di sequenziamento genetico di prossima generazione, molti degli algoritmi sono stati sviluppati in python a causa della familiarità con gli scienziati dei dati e della velocità di sviluppo. Spesso ci sono voluti un sacco di hacking e sperimentazione per ottenere l'I / O e le strutture dati corrette e per soddisfare i requisiti di velocità e spazio per l'elaborazione di enormi set di dati. A volte usavamo R o MatLab. Ci sono molte altre opzioni qui.

Dopo che il prototipo funzionava, l'interfaccia iniziale era tramite la riga di comando. Lentamente, nel tempo, la maggior parte è stata convertita alla nostra "vera" applicazione, scritta in Java, che è stata vista (si noti che non sto prendendo posizione in questo!) Come più robusta e manutenibile, ed era sicuramente più familiare al software ingegneri.

Il codice non viene continuamente riscritto, quindi tutto è già basato su un'ipotesi errata.

A volte hai un codice che viene usato una volta e mai più. La qualità non importa se puoi verificare che il risultato sia corretto. La maggior parte del codice non è così.

A volte le persone scrivono prototipi con l'intento di buttare via il prototipo e scrivere in seguito il codice reale. E poi la direzione decide che il prototipo della spazzatura è abbastanza buono e la cattiva qualità ti perseguiterà per sempre. In teoria, questo non dovrebbe accadere. In pratica, c'è una differenza tra teoria e pratica.

A meno che tu non sia sicuro al 100% che la bassa qualità non influisca su di te ma sia un problema di qualcun altro, assicurati che tutto ciò che fai abbia una qualità decente sin dall'inizio. È più economico in questo modo.