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

Roma non è stata costruita in un giorno, ma puoi essere un buon "Boy Scout". Ogni volta che tocchi il codice, lascialo meglio di prima. Non impiega molto tempo per utilizzare nomi di funzioni ragionevoli, standard di codifica validi 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 assolutamente rinunciare e scrivere spazzatura.

Accetta 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 quello) si perde nelle migliori pratiche, "codice bello", ... qualunque cosa tu voglia chiamarlo ... e loro non ottengono molto; oppure lo fanno ma perdono molto tempo. Dicendo loro di scrivere codice errato (che è anche il codice che funziona anche) ottiene che "attraverso quello", solo li fa consegnare qualcosa. Con il passare del tempo, risulta che un dev (ora non più :) junior molto rapidamente si presenta con una soluzione rapida e sporca, ma trascorre il resto del tempo a migliorarlo. E con il passare del tempo, impari di più e ad un certo punto inizi a fornire soluzioni rapide e sporche che sono in realtà un buon codice.

Ma se sei andato per la tua strada e hai provato a scrivere codice perfetto fin dall'inizio probabilmente avresti speso un sacco di 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.

Dipende da come ti costringono.

Nella mia esperienza, ci sono due possibilità:

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

In questo caso, come la maggior parte delle altre risposte già dicono, spetta a te "ottimizzare per la freschezza". Potresti non avere il tempo di riscrivere il codice base in MVC, ma come primo passo, ad esempio, puoi smettere di incollare il tuo SQL manualmente e invece scrivere un bel execute_sql($query, $params) , che pone le basi per astrazioni come fetch_customer($filter_params) , ecc. Ricorda, tutte le migliori pratiche sono in definitiva lì che il tuo capo riceve un prodotto in precedenza, quindi c'è solo un conflitto in quanto tempo investire in futuro rispetto al momento.

Quando imposti il contesto giusto ('entro 6 mesi, senza richiedere altro tempo, ho rifattorizzato il codice monolitico in MVC') dovresti lasciare il tuo nome sul codice e provare ad essere orgoglioso come un terapeuta, che insegna un vittima di un ictus per dire di nuovo parole singole.

Ti viene esplicitamente ordinato di implementarlo in un modo che ritieni non idoneo

Il tentativo di separare la vista dal modello non sopravvive alla revisione, perché "è troppo complicato, perché non fai semplicemente query sql?". Il tuo execute_sql viene modificato perché "un coder con disciplina non ha bisogno di questo".

Questo caso fa schifo. Nella mia esperienza, di solito viene con microgestione e team leader che sono stati promossi lì per motivi politici, non per i loro successi. Il vero problema è che vieni messo a capo 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 secondo la mia esperienza, la solita) è uscire.

Il lato positivo è che, in questo scenario, il tuo nome non verrà pubblicato comunque, perché il leader del team prende il merito di tutto il successo.

Sono piuttosto fiducioso che il tuo capo richieda di consegnare qualcosa in fretta, ma non che tu prenda ulteriori sforzi per renderlo deliberatamente cattivo. Il che significa che ogni volta che si ha una scelta tra codice veramente scadente e codice leggermente meno cattivo, ed entrambe le opzioni richiedono tempi di implementazione ugualmente lunghi, si sceglie l'opzione leggermente meno cattiva. Questa è la soluzione a breve termine e non richiede alcuno sforzo.

Per il lungo termine, parla con il tuo capo. Spiega come investire quindici minuti qui può far risparmiare ore lì. Assicurati di avere esempi convincenti - non il tipo "se ho 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 questa cosa, e perché di quello, mi ci sono volute tre ore per trovare il problema, 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 si sente molto meglio e più efficiente, a volte non lo è. Ci sono situazioni in cui una soluzione rapida sciatta è perfettamente giustificata: a volte si scrive codice monouso, a volte si sta mantenendo un pezzo obsoleto di spazzatura viva, in attesa della cosa reale; a volte, il vantaggio di una soluzione adeguata non giustifica lo sforzo (in termini monetari, a cui interessa tutto il tuo capo).

Se tutto il resto fallisce, trova un altro lavoro.

Nessuno ti obbliga a scrivere codice cattivo. Puoi cambiare questa situazione e renderla positiva. Cambiamento pioniere per politiche e procedure. E non puoi essere sempre il "sì" uomo / donna. Se dicono che hanno bisogno della funzionalità x prima della fine della giornata, digli che non è fattibile, ma fornisci giustificazioni perché in effetti non lo è. Dove c'è un problema, offri soluzioni. Non solo un occhio cieco, o peggio ... aggiungendo ad esso.

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

Qualsiasi azienda deve trovare un equilibrio tra la scrittura di un codice brillante, una vasta documentazione e test unitari e l'immissione di prodotti sul mercato in un budget e spazio di tempo ragionevole.

Il codice migliore del mondo non ha importanza se è obsoleto prima che venga rilasciato.

Essere pragmatici significa cercare di trovare quell'equilibrio. Ottenere funzionalità rapidamente risolte 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), per ottenere questo equilibrio giusto. È molto facile andare per entrambi gli estremi. Trovare una via di mezzo è più difficile.

Non sto dicendo che il tuo capo abbia ragione. Come programmatore c'è la tentazione di provare a creare costantemente codice bello che non sia commercialmente fattibile. 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 un tempo sufficiente conterrà gli hack per situazioni specifiche che sono state troppo costose per il refactoring in un quadro generale.

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

Devi alzarti in piedi e indicare il codice concreto e dire loro cosa fa schifo. Sii specifico e utilizza le metriche del codice per eseguire il backup delle tue attestazioni. Niente è più imbarazzante di quanto affermare che un codice è cattivo quando in realtà non lo è, semplicemente non hai capito cosa si stava facendo.

Sono sicuro che ci sono molti strumenti disponibili gratuitamente per l'analisi del codice php link

Inoltre, ovviamente questo link

Leggi, riassume ciò che puoi trovare nella tua applicazione e, naturalmente, elenca alternative . È una cattiva pratica alzarsi e gridare "Non mi piace come si fa" senza presentare un modo alternativo (preferibilmente) migliore per farlo.

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

hth

Prima di ogni altra cosa, si usa un controllo del codice sorgente di qualche tipo, giusto? In caso contrario, iniziare da lì. Ti aiuterà prima e sarà adottato dal resto del team rapidamente.

Se hai il controllo del codice sorgente, non dovresti inserire il tuo nome nel codice, basta mettere il nome della tua azienda. È comune nel codice errato inserire una cronologia di revisione nei commenti nella parte superiore 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 problemi diversi. Se lo fai bene, ti salverà un po 'di tempo e lo userai per migliorare la qualità generale.

Per darti un mio esempio, sono arrivato nel bel mezzo di un progetto con un'applicazione Perl / CGI in cui tutto il codice HTML era presente nel codice. L'intera app era in un unico file senza struttura chiara. Niente è stato versionato. Ho iniziato configurando un repository CVS (nessun SVN disponibile al momento), ho inserito un'interfaccia web per il cliente. All'inizio, stavo gestendo i commit 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 fuori dal codice. Poi, ogni volta che dovevo fare una modifica in qualche parte del codice, ho impiegato un po 'di tempo a rifattorici un po'. Alla fine, la velocità di sviluppo era aumentata a tal punto che il cliente era estremamente felice. Richiederebbero un cambiamento estetico e invece di dire loro "ci vorranno 2 giorni", l'ho cambiato al volo nell'ambiente di sviluppo.

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

Un'ultima cosa, una riscrittura completa a volte è l'unica soluzione, ma di solito è molto difficile giustificare il suo costo per la 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 piuttosto che lavorare solo su un codice perfettamente "pulito". Approfitta della situazione e impara come rifattorizzare il codice cattivo e convertilo lentamente in qualcosa di più gestibile. E non lamentatevi di dover essere al più presto. Questo è il punto - impara a refactoring e ripulire il codice mentre si fa le cose in una scadenza ristretta. Dopo tutto, chiunque può scrivere un codice perfetto se ha un tempo infinito a disposizione.