Refactoring codice di noodle stagista precedente con futuri stagisti in mente [duplicato]

Ci sono due cose da notare qui: sembra che tu sappia un bel po 'sulle buone pratiche e il progetto è destinato a scomparire "presto" (anche se non subito dopo che te ne sei andato).

Come Telastyn menziona, sfrutta al massimo questa esperienza per imparare cosa funziona e cosa no e come applicare le migliori pratiche in un ambiente reale. Pensa prima a te stesso.

Detto questo, le migliori pratiche includono il mantenimento del codice di facile comprensione per i tuoi colleghi, quindi, come parte dell'esperienza di apprendimento, dovresti comunque cercare di scrivere un codice leggibile. Anche l'uso di OOP per strutturare correttamente le cose fa parte di questo e dovrebbe naturalmente aiutare a rendere le cose più facili da comprendere e mantenere a lungo termine.

Secondo me, il codice OO dovrebbe essere più facile da leggere perché è ben strutturato, quindi non sono sicuro del motivo per cui devi scegliere tra un codice buono e un codice leggibile internamente. Se i tirocinanti non conoscono abbastanza bene l'OOP, questa è un'occasione per imparare. Preferisco dare un buon codice OOP ai nuovi programmatori, in modo che imparino immediatamente con buone basi.

Se senti davvero il bisogno di rendere le cose ancora più comprensibili, prenderei in considerazione l'aggiunta di commenti a qualsiasi parte che, per te, è già sembrata complicata, ad esempio quando hai difficoltà a ottenere il codice scrivevi giorni o poche settimane fa. Se tu lotti, immagina l'effetto su qualcuno che non ha mai nemmeno scritto il codice.

Potresti anche passare attraverso il tuo codice "vecchio" e improvvisamente realizzare una struttura migliore basata su approfondimenti successivi e potresti individuare il codice duplicato che può essere trasformato in una funzione con parametri. Questo è il momento in cui vorresti rifattorizzare ciò che hai, se ti senti sicuro che il tempo speso a farlo sarà davvero di aiuto nel lungo periodo (io stesso sto ancora lottando con tali stime).

L'aggiunta di test unitari o altra forma di suite di test potrebbe anche aiutare te e chiunque altro come può essere eseguito per assicurarti di non aver infranto le funzionalità del codice esistente. Penso che possa essere un ottimo strumento per i nuovi arrivati in quanto è spesso difficile cogliere l'impatto della modifica di bit di codice che non conosci (anche il codice che conosci, davvero).

Potresti scrivere della documentazione su ciò che la tua applicazione dovrebbe realizzare e dare una visione dei suoi aspetti più complicati. Conoscere il comportamento previsto aiuta a chiarire se hai trovato un bug o una mancanza di funzionalità (spesso una nozione confusa agli utenti finali).

Perché non chiedi ai tuoi colleghi? Se mostrano la conoscenza di OOP e buone pratiche e tuttavia non facilmente "ottengono" il tuo codice, potresti chiedere a cosa stanno lottando e cosa manca per aiutarli a capire.

Il punto di uno stage è imparare. Vorrei rifattorizzare il codice per essere migliore e ignorare i limiti presunti di persone che non conosci. Per quel che ne sai, la società trasferirà il progetto a un team interno piuttosto che ai tirocinanti presto.

La tua domanda ha due problemi principali: dovrei scrivere un buon codice, anche se la prossima persona potrebbe non capirlo? e, come posso assicurarmi che i miei sforzi non vengano sprecati se una persona con meno esperienza si impadronisce di me?

Per quanto riguarda il primo, dovresti sempre scrivere il miglior codice possibile. Sappiamo che il codice scritto con schemi e principi di progettazione è flessibile, manutenibile ed estensibile. Anche i nuovi programmatori possono generalmente vederlo, anche se non capiscono come farlo da soli. I test forniscono anche un enorme vantaggio e possono anche riempire un ruolo di documentazione. Non puoi lasciare che le aspettative di chi verrà dopo ti impediscano di scrivere un buon codice; semmai dovrebbe incoraggiarti a scrivere un buon codice.

Per quanto riguarda la conservazione di tutto il lavoro che hai inserito, la maggior parte degli sviluppatori, anche di quelli nuovi, può generalmente capire che cosa sta succedendo in un codice ben scritto (almeno sul superficie), ma alcuni sviluppatori, specialmente nuovi sviluppatori a scuola, non hanno idea perché un pezzo di codice è così com'è. Questo è ciò che devi comunicare.

Suggerirei di scrivere un documento per comunicare come e perché hai ottenuto il codice dove si trova. Descriveremo brevemente come si usa il controllo della versione per il progetto, poiché alcuni curricula non implicano alcun controllo della versione e forniscono risorse su dove conoscere il VCS (ad esempio, hginit.com e " Mercuriale: la guida definitiva per Mercurial, esistono risorse simili per altri VCS Dovresti parlare di schemi di progettazione, in particolare quelli che vedranno spesso: ancora una volta, alcuni curricula non parlano di schemi di progettazione, ancora una volta forniscono risorse per saperne di più.

Parlate anche del codice e della vostra esperienza con esso. Parla della conquista del metodo della linea 700, di come l'hai fatto, perché l'hai fatto e di come ha reso la vita di tutti più facile. Lo scriverei meno formalmente e in un tono narrativo per mantenerlo interessante e di bell'aspetto. Questo aiuterà la prossima persona a vedere quali progressi hai fatto, a vedere come lavori e a costruire un legame personale. Tutti gli sviluppatori possono commiserare su esperienze di lavoro con codice errato.

Non tralascio dettagli specifici, ad esempio come accedere ai repository o accedere ai server o informazioni commerciali riservate. La ragione per cui lo farei è che possano inviarlo a uno stagista prima che inizino, e potrebbero mantenerlo dopo che se ne sono andati, come risorsa informativa. Dovresti fornire le altre informazioni in un documento separato che ricevono una volta che hanno effettivamente iniziato lo stage. Punterei per una lunghezza compresa tra 5 e 10 pagine, abbastanza spazio per poter raccontare le tue storie abbastanza breve da essere letto casualmente.

I programmatori che verranno dopo faranno probabilmente la stessa cosa che hai fatto (come hai visto prima dove la lista è vissuta per sempre), se possono capire come e perché farlo. Se crei una buona base e mostri chiaramente la strada, è probabile che la prossima persona segua il flusso.