suggerendo grandi cambiamenti / una riscrittura come stagista [chiuso]

Il contesto:

• è un progetto interno (che non credo che molte persone usino)
• è vecchio
• lo stiamo aggiornando

I problemi:

1. abusa del framework mvc (nessun uso di modelli, logica aziendale nelle viste, ecc.)
2. quello che ci viene chiesto di fare è piccolo, ma a causa della bassa coesione abbiamo due opzioni:
   1. continua a rovinare le cose
   2. sposta grandi blocchi di codice o riscrivi la cosa

Le soluzioni (vedo):

1. continuare a lavorare con esso, ignorare le migliori pratiche in favore di essere fatto presto e non introdurre nuovi bug rifattorizzando / riscrivendo
2. refactoring / riscrittura

Immagino che la mia domanda sia davvero: se voglio apportare grandi cambiamenti a questo progetto, come posso proporlo senza offendere nessuno? O sarebbe meglio per me semplicemente seguire il flusso anche se a volte ciò significa nastro adesivo (metaforico)?

OK Ecco qui.

Pensi che l'applicazione sia mal strutturata e scritta male.

Il cliente pensa che faccia il suo lavoro.

Vuoi riscriverlo per nessun altro motivo se non quello di migliorare la sua "bellezza interna".

Quindi stai chiedendo al cliente di spendere soldi per fare in modo che l'applicazione faccia esattamente quello che fa ora - solo le parti che l'utente non vede o capisce saranno in qualche modo "migliori".

L'obiezione principale al codice mal strutturato e mal scritto è che è difficile da capire.

Il codice è difficile da comprendere e ha funzionalità e caratteristiche che possono essere facilmente implementate solo in un'applicazione mal strutturata. Quindi, a meno che tu non sia molto bravo in questo, la nuova applicazione non farà esattamente quello che fa l'attuale applicazione e, poiché non hai compreso appieno ciò che il codice originale stava facendo, probabilmente lo avrebbe fatto male.

Quindi il tuo cliente ora ha speso molti soldi per ottenere un'applicazione che è notevolmente peggiore rispetto all'applicazione originale. Non sarai popolare!

Fortunatamente i tuoi college più esperti sono pronti ad umorizzarti (probabilmente perché hanno fatto lo stesso errore quando stavano iniziando, e potrebbero anche aver avuto la sfortuna di ottenere l'approvazione della direzione per un progetto così sfortunato).

Quindi il mio consiglio sarebbe di mantenere in esecuzione la vecchia base di codice e di tacere. Il cliente vuole solo un sistema che funzioni a cui non importa se pensi che il codice sia brutto.

Proponi le tue modifiche. Siate chiari sul caso aziendale per ciascuno: perché la modifica proposta aiuterà il sistema nel suo insieme? In caso contrario, aspettati di tornare indietro. Perché spendere soldi per riparare qualcosa che non è rotto? Ragioni come rendere il sistema più estensibile e separare le preoccupazioni possono essere valide (a seconda di chi stai parlando), ma il 99% delle volte, solo dicendo "non è implementato correttamente" non ti porterà da nessuna parte. Assicurati di aggiungere valore al progetto e non solo di proporre di far funzionare (anche se pulisce il codice).

Sfortunatamente, nel mondo professionale, solo perché qualcosa è stato implementato in modo errato non significa che è rotto e quindi non ha bisogno di essere riparato. Inoltre, nel risolverlo, è possibile introdurre problemi a catena imprevisti che potrebbero avere un impatto su altre aree del progetto.

Leggendo la tua domanda, in realtà sono scettico sul fatto che riscriverlo sia valsa la pena. Forse non ti sei preoccupato di fare il caso completo nella tua domanda. Ma quanto è probabile che il vantaggio della riscrittura valga il costo se si tratta di un'applicazione interna vecchia, usata raramente? Il costo di una riscrittura è probabilmente superiore alla somma di tutti gli aggiornamenti e le patch che avrà mai.

Se ritieni che ciò non sia vero, dovrai fare più di un caso per quello che hai fatto qui.

Per quanto riguarda il miglioramento dell'applicazione, potresti avere qualche possibilità per un po 'di refactoring che avviene naturalmente nel corso degli aggiornamenti.

Sei uno stagista. Presumibilmente, sei nuovo di zecca. Probabilmente sospettano che tu sia un idiota.

Quindi, mentre procedi per dare suggerimenti, cammina leggermente . Sii umile e modesto. Lascia che le tue idee fluiscano in modo conversazionale mentre permetti ad altri membri di discutere anche delle loro idee sulla base di codice e su quali pressioni potrebbero subire (potrebbe esserci un'ottima ragione per cui non è stato fatto uno sforzo per ripulire le cose).

Vuoi guadagnare la loro fiducia. Puoi farlo scrivendo un buon codice per le attività che ti vengono assegnate. Scrivilo in modo chiaro, usa le migliori pratiche che vorresti vedere implementate, ma solo su ciò che ti è stato assegnato. Queste saranno probabilmente piccole cose, cose che probabilmente il resto della squadra ritiene insignificanti. Fai queste cose bene. Illumina l'angolo in cui ti trovi e, man mano che il team arriva a rivedere favorevolmente il tuo codice, anche le tue idee aumenteranno di statura.

Alla fine , mentre dimostri la tua competenza e conoscenza, potresti essere in grado di ottenere un suggerimento o due.

Darei completamente questo suggerimento, ma solo a un collega sviluppatore . Non lo direi con il management, come immagino che il management lo vedrebbe come un qualche tipo di superamento dei confini.

Dopo aver dato il suggerimento a uno sviluppatore con cui stai lavorando, probabilmente avranno dei buoni motivi per capire perché la base di codice sia. Le ragioni possono variare da "no, in realtà il codice va bene, semplicemente non capisci MVC (ed è per questo che sei un tirocinante)" a "è una grande idea, progettiamo insieme la nuova applicazione!"

Tieni presente che la risposta al refactoring di questa domanda sarà molto probabilmente no; Non vorrei mai che un tirocinante si assumesse la riscrittura di un'applicazione interna (cosa succede quando il tuo tirocinio è finito e la riscrittura è solo a metà?) Inoltre, ci sono probabilmente cose più importanti su cui potresti lavorare che curiosare con un'applicazione interna .

Ma non fa mai male chiedere ai tuoi pari, e se lo fai, imparerai qualcosa. E questo, 7983879342, è lo scopo di uno stage.

Qualunque cosa accada, spero che porti via il seguente messaggio. Come alcune delle risposte di cui sopra hanno sottolineato a volte una riscrittura del codice, per i migliori motivi tecnici è talvolta impossibile per motivi di business / costi. Troppi programmatori vivono nella soluzione tecnica e si rifiutano di considerare che la loro ricerca personale di eleganza tecnica / leggibilità / best practice dovrebbe essere bilanciata dalle esigenze dell'azienda di fare le cose. Nella mia esperienza personale, il ragazzo che non raggiunge quell'equilibrio (da entrambe le direzioni) è spesso visto come una responsabilità all'interno della squadra.

Non smettere di mettere in discussione le cose, anche se hai dei knockback, è il modo in cui impariamo e cresciamo.

Altre risposte hanno parlato molto della politica della tua situazione e io tendo ad essere d'accordo. A meno che tu non sia in grado di presentare un caso aziendale convincente, probabilmente una riscrittura non è sulle carte.

Tuttavia, ciò non significa che dovresti dimenticare la regola del boy scout :

Lascia sempre il campeggio più pulito di quello che hai trovato.

Se mentre stai implementando qualcosa su questa base di codice, puoi trovare un modo per ripulire alcuni aspetti del design o dell'implementazione, allora è qualcosa che dovresti considerare. Probabilmente non è necessario riscrivere l'intera applicazione per utilizzare meglio il modello MVC e, se si sta implementando una nuova logica aziendale per una vista particolare, è possibile considerare di spostare la logica dalla vecchia vista nel modello e aggiungendo la tua nuova logica a questo.

Come altri hanno già detto, chiedi a un altro sviluppatore (uno che ha familiarità con questa applicazione) di fare una rapida panoramica solo per capire come / perché dell'implementazione. Spiega che mentre puoi comprendere gli aspetti tecnologici, ma vuoi essere in grado di collegare i punti ai requisiti aziendali (i requisiti aziendali prevalgono su tutti).

Una volta che hai queste informazioni, puoi fare la tua valutazione. Se pensi personalmente che debba essere riscritto, ma non pensi che gli altri lo vedranno come un buon uso del tempo, prendilo come un progetto personale. Anche se è un'ora qui / là quando si hanno tempi di inattività, eseguire l'implementazione "correttamente". Una volta terminato, presentalo agli altri sviluppatori come "ehi, pensavo che questo potesse usare un po 'di pulizia, quindi ho fatto un po' di lavoro laterale durante i miei tempi di inattività. Cosa ne pensi?" Non premere il cambiamento su di loro - offrilo a loro solo come "ehi, ragazzi come questo?" e vai da lì.

La maggior parte delle modifiche avviene in modo incrementale, come regola generale.

Alcune cose da tenere a mente;

• Qual è la storia dell'applicazione?
• Perché è brutto oggi?
• Qual è il vantaggio dei cambiamenti architettonici?

Una buona strategia è quella di lavorare sulle piccole cose e porre un sacco di domande sulle cose (domande che non puoi imparare da Google o dalla fonte, non perdere tempo). Dopo esserti sentito a tuo agio con la base di codice e gli sviluppatori, dovresti avere una buona idea del perché il codice è così com'è. A volte, è solo "Sì, abbiamo dovuto hackerare qualcosa insieme e spingerlo fuori dalla porta". Se puoi proporre lievi modifiche a piccole parti del sistema che si verificano man mano che procedi nel tuo normale lavoro, otterrai più trazione rispetto alle riscritture radicali.

Non c'è niente di male nel suggerire una riscrittura se lo chiedi bene e fai un caso logico (non solo un sospetto o è il modo migliore per farlo). C'è un'alta probabilità che la riscrittura di un'applicazione a basso uso venga abbattuta, e ci sono buone probabilità che chiunque abbia originariamente scritto il sistema sia ancora in giro (e più in alto nella gerarchia di te) e potrebbe non accettare gentilmente le critiche.

Quindi non dire "Dobbiamo riscrivere questo sistema orribilmente progettato che viola i principi di base di MVC", ponilo come una domanda aperta agli alti superiori appropriati (persone direttamente sopra di te). Qualcosa del tipo "Mi chiedo se riscrivere il sistema nel modello MVC potrebbe far risparmiare molto tempo nel lungo periodo. Cosa ne pensi? Scommetto che potremmo dimezzare i tempi di manutenzione con una riscrittura importante (diciamo 2 settimane) che incorpora il modello MVC, il TDD, ecc. è stato fatto e dopo due mesi di manutenzione ordinaria andremo in pareggio ". La risposta potrebbe essere, no, non pensiamo che sia richiesto: non sono d'accordo con le tue stime del tempo e la probabilità che il nuovo sistema sia un sostituto adatto. Oppure la risposta potrebbe essere, va bene, ma ricorda se il tuo nuovo sistema non funziona Funzionerà bene / meglio del nuovo sistema nel periodo che hai proposto che la gente ti biasimerà. E anche se il sistema è poco utilizzato; potrebbe non essere accettabile interrompere l'aggiornamento con correzioni minori durante il periodo di riscrittura.