Sto perdendo traccia del flusso della mia app Web PHP, sta diventando difficile lavorare con


14

Sto programmando da alcuni anni e nel tempo ho acquisito familiarità con C # e JavaScript. Ho alcuni progetti C # e JavaScript più grandi che non ho problemi a navigare. Di recente ho avviato un progetto PHP e AngularJS per lavorare senza precedenti esperienze con PHP.

Il flusso del lato PHP delle cose sta diventando difficile da tenere traccia di (il lato JavaScript è più grande, ma facile da elaborare), quando provo a riflettere su di esso immagino un groviglio di fili intricato. I principali errori di progettazione che ho fatto quando ho iniziato stanno cominciando ad accumularsi e ad influenzare il mio design in futuro. Ci vuole sempre più tempo per implementare qualcosa di nuovo.

Sono in una scadenza molto stretta e trovo sempre più difficile scrivere un buon codice, DRY, SOLID. Sta diventando sempre più allettante copiare / incollare blocchi di codice per apportare lievi variazioni al suo comportamento man mano che il tempo di progettazione aumenta. Ci vuole anche molto tempo per tornare alla base di codice ogni volta che devo fare un cambio di contesto (da un progetto poi a questo), ho la sensazione di avere paura ogni volta che torno a lavorare su questo progetto.

Quali passi posso prendere per porre rimedio a questo? Anche il tempo extra potrebbe essere giustificabile, il mio capo non è uno sviluppatore e non ha familiarità con lo sviluppo o i cicli di vita del software, quindi spiegare potrebbe essere più difficile del normale.



1
Grazie @gnat Tuttavia, sono meno interessato a presentare un caso per il mio capo di quello che sto cercando di capire come risolvere effettivamente i problemi stessi. Presentare un caso al mio capo non gioverà se non conosco un buon metodo metodico per identificare e modificare i problemi.
Douglas Gaskell,

Risposte:


11

Stai assumendo un debito tecnico. Più giustifichi un codice sciatto con scadenze, più scadenze ti vedranno raggiungere sempre meno.

Comprendi che puoi farcela completamente. Nessuno ti sorprende a fare casino e a buttarti fuori. Un giorno ti sveglierai circondato dal disordine.

A quel punto o aggiornerai il tuo curriculum e lo trasformerai in un mio problema o deciderai di pagare il debito e passare un po 'di tempo a ripulire il codice.

Se segui il percorso di pulizia, capisci che non si tratta di "dedicare più tempo alla progettazione". Si tratta di rompere alcune abitudini pigre e portare fuori la spazzatura.

Eliminare il codice sporco all'ingrosso è una cattiva idea. Non a causa del lavoro svolto, ma perché il codice di lavoro acquisisce un'idea. Sposta l'idea in un codice pulito prima di eliminare il codice sporco.

Avere test unitari aiuta in questo, ma se hai creato i test con la stessa cura che metti nel caos, probabilmente hanno bisogno di essere riparati.

Non dare rigidità. Se non puoi cambiarlo, allora non è un software.


1
"Nessuno ti sorprende a fare casino e a buttarti fuori." ... A meno che non si esegua la revisione del codice. ;)
jpmc26

1
@ jpmc26 Se pensi che le recensioni dei codici ti salveranno da questo destino, ti sbagli. Le revisioni del codice ti aiutano solo quando sei disposto a imparare dagli altri. Non quando ti concentri su una scadenza. Funzionante, disordinato, il codice vincerà le opinioni ancora e ancora. Ho visto i manager risolvere queste controversie lanciando un quarto. Se non ti interessa la qualità, nessuno sarà in grado di trascinartelo fuori. Non pensare di poter contare sugli altri per impedirti di fare casino. In questo caso, ti assegneranno semplicemente per aggiornare la documentazione.
candied_orange

Se leggi il mio commento e pensi che stavo dicendo che le recensioni di codice sono magiche come unicorni e arcobaleni che risolveranno tutto senza alcuno sforzo o volontà, ti sbagli incredibilmente. Ma danno a qualcuno la possibilità di chiamarti fuori.
jpmc26

1
@ jpmc26 Se leggi la mia risposta e pensi che stavo dicendo che non c'è speranza di arrendersi, ti sbagli incredibilmente. Chiedo ai programmatori di assumersi la responsabilità personale per il codice pulito piuttosto che fare affidamento su qualsiasi processo per realizzarlo. Solo una cosa matura. O ti importa o no.
candied_orange

Certo, ma anche il miglior programmatore prenderà decisioni stupide di tanto in tanto. Le revisioni del codice con un'altra persona ti danno la possibilità di mettere il tuo codice di fronte a qualcun altro che può catturarlo prima. Questo è il punto . È difficile vedere i punti problematici da soli fino a quando non si tenta effettivamente di cambiare qualcosa e diventa difficile. Naturalmente le revisioni del codice e qualsiasi altra tecnica sono inutili se non ti interessa.
jpmc26,

9

Ci vuole sempre più tempo per implementare qualcosa di nuovo.

Questa è la tua giustificazione. 'confessa, mangia un po' di corvo e spiega perché le cose stanno impiegando più tempo e che è necessario dedicare un po 'di tempo al refactoring + alla riprogettazione del sistema.

Se non lo fai, dovrai refactoring a poco a poco, verso il basso. Le attività stanno già impiegando più tempo del previsto: prenditi un po 'di tempo extra ogni volta che tocchi la base di codice per cercare di migliorare. Aggiungi un test di integrazione. Estrai un'astrazione.

La stupida risposta a "Come refactoring un grande progetto?" è "Un pezzo alla volta".

MODIFICARE

Stavo leggendo post correlati e mi sono imbattuto in questo post del blog: http://ronjeffries.com/xprog/articles/refactoring-not-on-the-backlog/ . TLDR : non tentare di creare un'enorme "fase" di refactoring nel tuo progetto; è improbabile che tu ottenga un buy-in dai proprietari del progetto e non sarai guidato nelle tue scelte su cosa affrontare durante il tempo che hai. Invece, prenditi il ​​tempo per ogni nuova modifica o correzione di bug per eliminare il codice con cui stai lavorando in questo momento. Non lasciare che gli odori rimangano intorno quando hai l'opportunità di risolverli.


3
Questo è esattamente quello che ho fatto con i miei patrimoni in passato. La cosa bella: una volta che hai ottenuto la svolta, il progetto inizia a brillare come con la polvere delle fate.
qwerty_so,

-2

Sonarqube supporta PHP in modo che tu possa aiutarti a tenere traccia del tuo debito attuale e di nuove perdite. http://docs.sonarqube.org/display/PLUG/PHP+Plugin

Esempio live con Drupal https://sonarqube.com/dashboard?id=drupal


1
Purtroppo non riesco a installare JVM sul mio dispositivo di lavoro. Questo sembra un ottimo strumento altrimenti.
Douglas Gaskell,

È piuttosto draconiano per una workstation di sviluppo.
Archimede Trajano,

Non ho un amministratore locale, né permessi di installazione, né permessi di esecuzione per nessuna applicazione elencata non bianca. Andava molto peggio .... purtroppo.
Douglas Gaskell,

Non posso dire di entrare in empatia, anche se simpatizzo.
Archimede Trajano,

ridimensionato poiché è solo un annuncio / collegamento a uno strumento, non una risposta alla domanda del PO.
James Snell,
Utilizzando il nostro sito, riconosci di aver letto e compreso le nostre Informativa sui cookie e Informativa sulla privacy.
Licensed under cc by-sa 3.0 with attribution required.