Sono costretto a scrivere un codice errato. Come posso salvare la mia faccia? [chiuso]

Sono solo uno sviluppatore junior, ma il mio lavoro mi costringe a lavorare con un codice PHP davvero terribile (pensa al peggior codice PHP che hai visto; poi pensa al codice due volte meno). Di solito provo a correggere i bug e combatto con la base di codice per aggiungere nuove funzionalità. A volte mi viene ordinato di far funzionare le cose al più presto e il più delle volte comporta hack sporchi.

Il prodotto era precedentemente open source e temo che potrebbe essere open-source in futuro. Mi vergognerei se qualcuno (specialmente i potenziali datori di lavoro) riuscisse a trovare il mio nome accanto ad alcuni dei changeset. Cosa posso fare per proteggere il mio buon nome?

Non sono sicuro che ciò sia pertinente, ma aggiungerò che né il mio capo né i miei colleghi vogliono ammettere che il codice è errato, ma non sono sicuro di poterlo incolpare per questo - per molti di loro questo è il loro primo lavoro.

Roma non fu costruita in un giorno, ma puoi essere un buon "boy scout". Ogni volta che tocchi il codice, lascialo migliore di prima. Non ci vuole uno straordinario tempo per usare nomi di funzioni sensibili, buoni standard di codifica e inserire commenti decenti quando lavori.

Penso che il pericolo sia pensare che sia tutto o niente. Solo perché non puoi passare il tempo che vuoi scrivere codice elegante, non significa che devi rinunciare totalmente e scrivere immondizia.

Accetto con S.Lott dai commenti * (per una volta :) Nessuno ti obbliga a scrivere codice errato. Il fatto è, junior dev. spesso (anche questo sito è da incolpare per questo) perdersi nelle migliori pratiche, "bellissimo codice", ... qualunque cosa tu voglia chiamarlo ... e non ottengono molto; o lo fanno ma perdono molto tempo. Dicendo loro di scrivere un codice errato (che è anche codice che funziona) si ottiene che "attraverso quello", li fa semplicemente consegnare qualcosa. Col passare del tempo risulta che uno sviluppatore junior (ora non più :) si presenta molto rapidamente con una soluzione rapida e sporca, ma passa il resto del tempo a migliorarla. E col passare del tempo, impari di più e ad un certo punto inizi a fornire soluzioni rapide e sporche che in realtà sono un buon codice.

Ma se avessi seguito la tua strada e avessi provato a scrivere un codice perfetto sin dall'inizio, molto probabilmente avresti trascorso molto tempo e non hai fatto quasi nulla.

Quindi ... scrivi codice errato, ... molto ... codice che funziona a malapena, e poi ITERATE. Ogni iterazione è leggermente migliore!

Nessuno ha scritto la soluzione perfetta per la prima volta.

* questo, se fosse più corto sarebbe stato un commento.

I commenti sul codice sono i tuoi amici qui.

Ogni volta che senti di dover scrivere qualche hack economico a causa della pressione, dì semplicemente qualcosa del tipo: "Questo codice fa X a causa dei vincoli temporali. Idealmente, farei Y invece. - Ashamed One, 5 luglio 2011"

Quindi, se i potenziali datori di lavoro lo vedranno, capiranno che preferisci scrivere un buon codice, ma sei anche disposto ad adattare il tuo stile di codifica alle esigenze aziendali. La maggior parte dei datori di lavoro vedrà entrambe come buone cose.

Dipende da come ti costringono.

Nella mia esperienza, ci sono due possibilità:

Ti senti costretto da un programma serrato, un codice legacy, ecc.

In questo caso, come già dice la maggior parte delle altre risposte, spetta a te "ottimizzare per il fresco". Potresti non avere il tempo di riscrivere la base di codice in MVC, ma come primo passo, ad esempio, puoi smettere di incollare il tuo SQL a mano e invece scrivere un bel execute_sql($query, $params), che pone le basi per astrazioni come fetch_customer($filter_params), ecc. Ricorda, tutto il meglio in definitiva ci sono pratiche in base alle quali il tuo capo ottiene un prodotto prima, quindi c'è solo un conflitto in quanto tempo investire nel futuro vs nel presente.

Quando imposti il ​​giusto contesto ("entro 6 mesi, senza ottenere tempo extra, ho riformattato il codice monolitico su MVC") dovresti lasciare il tuo nome sul codice e cercare di essere orgoglioso come un terapista, che insegna a una vittima di ictus a ripeti singole parole.

Ti viene esplicitamente ordinato di implementarlo nel modo che ritieni inadatto

Il tentativo di separare la vista dal modello non sopravvive alla recensione, perché "è troppo complicato, perché non fai semplicemente query sql?". Ti execute_sqlviene inscatolato perché "un programmatore con disciplina non ne ha bisogno".

Questo caso fa schifo. Nella mia esperienza, di solito viene fornito con microgestione e leader della squadra che sono stati promossi lì per motivi politici, non per i loro successi. Il vero problema è che sei incaricato di qualcosa (il codice) che non puoi controllare (devi farlo a modo loro). La soluzione migliore sarebbe quella di risolvere la causa principale (cioè che sei trattato come un grugnito). La seconda soluzione migliore (e nella mia esperienza, la solita) è smettere.

Il lato positivo è che in questo scenario è probabile che il tuo nome non venga pubblicato comunque, perché il leader della squadra si prende il merito di tutto il successo.

Sono abbastanza fiducioso che il tuo capo ti chieda di consegnare qualcosa in fretta, ma non che tu faccia uno sforzo extra per renderlo deliberatamente cattivo. Ciò significa che ogni volta che hai la possibilità di scegliere tra un codice veramente cattivo e un codice leggermente meno cattivo, ed entrambe le opzioni richiederebbero altrettanto tempo per l'implementazione, scegli l'opzione leggermente meno male. Questa è la soluzione a breve termine e non richiede alcuno sforzo.

A lungo termine, parla con il tuo capo. Spiega come investire 15 minuti qui può farti risparmiare ore lì. Assicurati di avere esempi convincenti - non il tipo "se avessi fatto questo e quello qui, la mia speranza è che sarei in grado di fare quest'altra cosa il prossimo anno", ma piuttosto "guarda, qui ho fatto questo, e perché di ciò, mi ci sono volute tre ore per trovare il problema lì, se l'avessi fatto in questo modo e in quel modo, il bug sarebbe stato subito evidente ". Un avvertimento qui: mentre il codice elegante e gestibile sembra molto meglio e più efficiente, a volte non lo è. Ci sono situazioni in cui una correzione rapida sciatta è perfettamente giustificata: a volte stai scrivendo codice monouso, a volte stai mantenendo in vita un pezzo di spazzatura obsoleto, in attesa della cosa reale; a volte, il vantaggio di una soluzione adeguata non

Se tutto il resto fallisce, vai a cercare un altro lavoro.

Nessuno ti obbliga a scrivere un codice errato. Puoi invertire questa situazione e renderla positiva. Cambiamento pionieristico per politiche e procedure. E non puoi nemmeno essere sempre l'uomo / donna "sì". Se dicono di aver bisogno della funzionalità x prima della fine della giornata, digli che non è fattibile, ma dai giustificazioni perché in effetti non lo è. In caso di problemi, offrire soluzioni. Non solo un occhio cieco, o peggio ... aggiungendolo.

Il tuo negozio di sviluppo non è il primo ad avere scadenze rigorose, pur avendo il desiderio di mantenere un codice ben progettato.

Ogni azienda deve trovare un equilibrio tra la scrittura di un codice brillante, con un'ampia documentazione e test unitari e l'immissione sul mercato di prodotti con un budget e uno spazio di tempo ragionevoli.

Il miglior codice al mondo non importa se è obsoleto prima di essere rilasciato.

Essere pragmatici significa cercare di trovare quell'equilibrio. Ottenere funzioni riparate rapidamente può essere commercialmente essenziale al momento, non significa che lo sarà sempre.

Ci vuole molta esperienza (più di quanto la maggior parte dei programmatori abbia mai avuto), per ottenere questo equilibrio giusto. È molto facile scegliere uno dei due estremi. Trovare una via di mezzo è più difficile.

Non sto dicendo che il tuo capo ha ragione. Come programmatore c'è la tentazione di provare a creare costantemente un bellissimo codice che non è commercialmente praticabile. Essere consapevoli di questa tentazione può aiutarti a capire che alcuni di questi hack non sono poi così male.

La maggior parte del codice dopo abbastanza tempo conterrà degli hack per situazioni specifiche che erano troppo costose per essere trasformate in un quadro generale.

Vorrei aggiungere che non dovresti semplicemente continuare come stai facendo ora, senza dire nulla e solo hacking e hacking.

Devi alzarti e indicare un codice concreto e dire loro cosa fa schifo al riguardo. Sii specifico e utilizza le metriche del codice per eseguire il backup dei tuoi reclami. Niente è più imbarazzante di affermare che un codice è male quando in realtà non lo è, non hai appena capito cosa è stato fatto.

Sono sicuro che ci sono molti strumenti disponibili gratuitamente da usare per l'analisi del codice php http://en.wikipedia.org/wiki/Code_analysis

Inoltre, ovviamente questo http://en.wikipedia.org/wiki/Code_smell

Leggilo, riassumi ciò che puoi trovare nella tua applicazione e ovviamente elenca le alternative . È una cattiva pratica alzarsi e gridare "Non mi piace come viene fatto" senza presentare un modo alternativo (preferibilmente) migliore per farlo.

Gli hack rapidi costano denaro. E non vederlo come completamente negativo: puoi imparare molto da questo lavoro ora e puoi trarre profitto dalle esperienze che fai ora nel tuo prossimo.

hth

Prima di ogni altra cosa, usi il controllo del codice sorgente in qualche modo, giusto? Altrimenti, inizia da lì. Ti aiuterà per primo e sarà rapidamente adottato dal resto della squadra.

Se hai il controllo del codice sorgente, non dovresti inserire il tuo nome nel codice, ma solo il nome della tua azienda. È comune nel codice errato inserire una cronologia delle revisioni nei commenti all'inizio dei file, questo è meglio delegato al controllo del codice sorgente.

Ora, per quanto riguarda la qualità del codice, non sarai in grado di cambiarlo come un approccio big bang. Lentamente, uno per uno, aggiungi nuovi approcci a diversi problemi. Se lo fai nel modo giusto, ti farà risparmiare un po 'di tempo e lo userai per migliorare la qualità complessiva.

Per darvi un mio esempio, una volta sono arrivato nel mezzo di un progetto con un'applicazione Perl / CGI in cui tutto il codice HTML era nel codice. L'intera app era in un unico file senza struttura chiara. Nulla è stato aggiornato. Ho iniziato configurando un repository CVS (nessun SVN disponibile al momento), inserendo un'interfaccia web per il cliente. All'inizio, gestivo personalmente gli impegni dai miei colleghi. Quindi, ho diviso tutti i metodi in diversi moduli (file). A quel punto, i colleghi hanno iniziato ad adottare CVS. Quindi, ho spostato l'HTML dal codice. Quindi, ogni volta che dovevo apportare una modifica in una parte del codice, mi sono preso un po 'di tempo per riformattare parte di esso. Alla fine, la velocità di sviluppo era aumentata così tanto che il cliente era estremamente felice. Richiederebbero un cambio estetico e invece di noi dicendo loro "ci vorranno 2 giorni",

Questo approccio tuttavia funzionerà solo se si padroneggia abbastanza bene il codice generale. Se non capisci il quadro generale, se alcune parti dell'applicazione rimangono incomprensibili, il tuo lavoro sarà davvero difficile.

Un'ultima cosa, una riscrittura completa è a volte l'unica soluzione, ma di solito è molto difficile giustificare i suoi costi di gestione.

Dato che sei uno sviluppatore junior, questa è in realtà una buona cosa. Essere gettati nel bel mezzo di un grande pasticcio di codice ti insegnerà molto di più su cosa non fare che lavorare solo su un codice perfettamente "pulito". Approfitta della situazione e impara come riformattare il codice errato e convertirlo lentamente in qualcosa di più gestibile. E non lamentarti del fatto che deve essere al più presto. Questo è il punto: impara a riformattare e ripulire il codice mentre fai le cose in tempi stretti. Dopotutto, chiunque può scrivere il codice perfetto se ha tempo infinito disponibile.