suggerendo grandi cambiamenti / una riscrittura come stagista [chiuso]

OK Ecco qui.

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

Il cliente pensa di fare il lavoro.

Vuoi riscriverlo per nessun altro motivo che per migliorare la sua "bellezza interiore".

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 mal scritto è che è difficile da capire.

Il codice è difficile da comprendere e ha funzionalità e funzionalità che possono essere facilmente implementate 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'applicazione corrente, e, poiché non hai capito appieno cosa stava facendo il codice originale, probabilmente lo farebbe male.

Quindi il tuo cliente ha speso un sacco di soldi per ottenere un'applicazione che è marcatamente peggiore dell'applicazione originale. Non sarai popolare!

Fortunatamente i tuoi college più esperti sono pronti ad umorarti (probabilmente perché hanno commesso lo stesso errore quando stavano iniziando e potrebbero anche aver avuto la sfortuna di ottenere l'approvazione da parte della direzione per un progetto tanto malato).

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

Proponi le tue modifiche. Sii chiaro sul business case per ciascuno di essi: perché il tuo cambiamento proposto aiuterà il sistema nel suo insieme? Se così non fosse, aspettati di respingerti. Perché spendere soldi per aggiustare qualcosa che non è rotto? Ragioni come rendere il sistema più estendibile e separare le preoccupazioni possono essere valide (a seconda di chi stai parlando), ma il 99% delle volte, solo dicendo "non è implementato correttamente" otterrà tu da nessuna parte. Assicurati di aggiungere valore al progetto e non solo di proporre make work (anche se pulisce il codice).

Sfortunatamente, nel mondo professionale, solo perché qualcosa è stato implementato in modo errato non significa che sia rotto, e quindi non necessita di essere risolto. Inoltre, nel risolverlo, puoi introdurre problemi imprevisti che potrebbero avere un impatto su altre aree del progetto.

Leggendo la tua domanda, sono effettivamente scettico sul fatto che riscrivere l'applicazione ne valga la pena. Forse non ti sei preso la briga di fare il caso nella tua domanda. Ma quanto è probabile che il beneficio della riscrittura valga il costo se si tratta di un'applicazione interna vecchia, raramente utilizzata? 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 prenderne di più di quello che hai fatto qui.

Per migliorare l'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 ti sospettano per un idiota.

Mentre procedi a dare suggerimenti, calpesta leggermente . Sii umile e senza pretese. Lascia che le tue idee scorrano in modo discorsivo mentre permetti agli altri membri di discutere anche le loro idee sulla base di codice e su quali pressioni potrebbero essere (potrebbe esserci una buona ragione per cui non è stato fatto uno sforzo per ripulire le cose).

Vuoi guadagnare la loro fiducia. Fai questo scrivendo un buon codice per i compiti che ti vengono assegnati. Scrivilo in modo pulito, usa le migliori pratiche che vorresti vedere implementate, ma solo su ciò che sei assegnato a fare. Probabilmente saranno piccole cose, cose che probabilmente il resto della squadra pensa siano insignificanti. Fai bene quelle cose. Illumina l'angolo in cui ti trovi, e mentre il team arriva a rivedere il tuo codice favorevolmente, anche le tue idee cresceranno di statura.

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

Vorrei assolutamente dare questo suggerimento, ma solo a un altro sviluppatore . Non lo farei con il management, come immagino che la direzione lo vedrebbe come un qualche tipo di superamento dei limiti.

Dopo aver presentato il suggerimento a uno sviluppatore con cui stai lavorando, probabilmente avranno delle buone ragioni per capire perché il codebase è il motivo per cui lo è. I motivi potrebbero variare da "no, in realtà il codice va bene, semplicemente non capisci MVC (ed è per questo che sei uno stagista)" a "è una grande idea, architettiamo la nuova applicazione insieme!"

Tieni presente che la risposta al refactoring di questa applicazione sarà più che probabile che no; Non vorrei mai che uno stagista si occupasse della 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 piuttosto che frugare in un'applicazione interna .

Ma non fa mai male chiedere ai tuoi pari, e se lo fai, imparerai qualcosa. E questo, 7983879342, è ciò che uno stage è tutto.

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 il migliore dei motivi tecnici a volte è impraticabile per motivi di affari / costi. Troppi programmatori vivono nella soluzione tecnica e si rifiutano di considerare che la loro personale ricerca dell'eleganza / leggibilità / delle migliori pratiche tecniche 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 dubbio le cose anche se, anche se ottieni alcuni contraccolpi, è il modo in cui apprendiamo e cresciamo.

Altre risposte hanno parlato molto della politica della tua situazione e sono tendenzialmente d'accordo. A meno che tu non possa presentare un caso aziendale convincente, probabilmente non è possibile riscrivere le carte.

Tuttavia, ciò non significa che dovresti dimenticare la regola Boy Scout :

Always leave the campground cleaner than you found it.

Se mentre stai implementando qualcosa su questo codebase, puoi trovare un modo per ripulire alcuni aspetti della progettazione o dell'implementazione, quindi è qualcosa che dovresti prendere in considerazione. Probabilmente non bisogno di riscrivere l'intera applicazione per sfruttare al meglio il modello MVC e, se stai implementando alcune nuove logiche di business per una determinata vista, potresti prendere in considerazione la possibilità di spostare la logica della vecchia vista nel modello e aggiungendo la tua nuova logica a questo.

Come altri hanno affermato, chiedi a un altro sviluppatore (uno che ha familiarità con questa applicazione) di fare una breve panoramica, in modo che tu possa capire come / perché dell'implementazione. Spiega che, mentre puoi capire gli aspetti tecnologici, ma vuoi essere in grado di collegare i punti ai requisiti aziendali (i requisiti aziendali superano tutti).

Una volta che hai queste informazioni, puoi fare la tua valutazione. Se pensi personalmente che dovrebbe essere riscritto, ma non pensare che gli altri lo vedranno come un buon uso del tempo, prendilo come un progetto personale. Anche se è un'ora qui / là quando hai dei tempi di inattività, esegui l'implementazione "correttamente". Una volta finito, presentalo agli altri sviluppatori come a un "hey, mi sentivo come se questo potesse usare un po 'di pulizia, quindi ho fatto un po' di lavoro laterale durante il mio downtime. Cosa ne pensi?" Non premere il cambiamento su di loro - basta offrire a loro come un "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 cronologia dell'applicazione?
• Perché è brutto oggi?
• Qual è il vantaggio delle modifiche architettoniche?

Una buona strategia è lavorare sulle piccole cose e fare un sacco di domande su argomenti (domande che non puoi imparare da Google o dalla fonte, non perdere tempo alle persone). Dopo esserti sentito a tuo agio con la base di codice e gli sviluppatori, dovresti avere un'idea del perché il codice è così com'è. A volte, è solo, "Sì, dovevamo incidere qualcosa e spingerlo fuori dalla porta". Se puoi proporre modifiche lievi a piccole parti del sistema che si verificano durante il tuo normale lavoro, otterrà più trazione rispetto alle riscritture radicali.

Non c'è niente di male nel suggerire una riscrittura se si chiede gentilmente e si fa un caso logico (non solo un'intuizione o è il modo migliore per farlo). C'è un'alta probabilità che la riscrittura di un'applicazione a basso utilizzo venga abbattuta, e c'è una buona possibilità che chiunque abbia originariamente scritto il sistema sia ancora in giro (e più in alto nella gerarchia di te) e potrebbe non essere gentile con le critiche.

Quindi non dire "Abbiamo bisogno di riscrivere questo sistema orribilmente progettato che viola i principi di base dell'MVC", ponilo come una domanda aperta ai superiori più adatti (le persone direttamente sopra di te). Qualcosa del tipo "Mi chiedo se riscrivere il sistema nel modello MVC potrebbe risparmiare un sacco di tempo a lungo termine." Cosa ne pensi? Scommetto che potremmo dimezzare i tempi di manutenzione con una grande riscrittura (in 2 settimane) che incorpora modello MVC, TDD, ecc. è stato fatto e che dopo due mesi di manutenzione ordinaria avremo un break even ". La risposta potrebbe essere, no non pensiamo che ciò sia richiesto - non sono d'accordo con le tue stime di tempo e la probabilità che il nuovo sistema sia un sostituto adatto. O la risposta potrebbe essere, va bene, ma ricorda se il tuo nuovo sistema non funziona come / migliore del nuovo sistema nel tempo che hai proposto che la gente ti biasimi. E anche se il sistema è poco utilizzato; potrebbe non essere accettabile interrompere l'aggiornamento con correzioni minori durante il periodo di riscrittura.