Evitare tutte le situazioni più nette nello sviluppo di software [chiuso]

Or have you faced such situations?

Non credo che ci sia un programmatore che non ha passato ore e ore a cercare di correggere uno stupido errore di battitura.

Does facing this issue frequently suggest inefficiency?

No, non suggerisce inefficienza, ma piuttosto mancanza di disciplina durante lo sviluppo. Ci sono molti studi e tecniche per questo, e alcuni di loro sono piuttosto personali, ma il punto è: più sei disciplinato mentre scrivi il codice, meno probabile è avere bug e passare un sacco di tempo per il debug.

Alcuni suggerimenti sono:

• Apporta modifiche incrementali e, dopo ogni modifica, verifica se il codice funziona (controlla anche le regressioni - controlla se non hai rotto nulla durante l'implementazione della tua nuova piccola funzione).

• Scrivi test. Esistono diversi tipi di test e metodologie di sviluppo che li coinvolgono, a partire da semplici test unitari scritti durante lo sviluppo fino allo sviluppo basato su test. Ciò aiuta anche ad automatizzare i test e a controllare rapidamente le regressioni.

• Scrivi documentazione. Rende il codice più chiaro, che può essere d'aiuto durante il debug. Inoltre, per alcune persone, scrivere i loro pensieri aiuta a svuotare la mente.

• Critica il codice e cerca di renderlo il più chiaro e leggibile possibile.

• Piano. È molto più facile prendere un pezzo di carta e pensare un po 'al design dell'applicazione, e creare un piano successivo, piuttosto che rimanere bloccato con un pasticcio dopo un po' di tempo.

• I messaggi di debug che possono essere disattivati possono essere utili in alcuni casi.

Fondamentalmente, l'intero punto è scrivere un codice di alta qualità, che sia testato con attenzione, per catturare il maggior numero possibile di bug possibile all'inizio dello sviluppo. Ma ci saranno dei bug e l'unica cosa che puoi fare su di loro è accettarli e pianificare di conseguenza. Qualsiasi stima valida per lo sviluppo del software include un po 'di tempo per la correzione dei bug.

Per quanto riguarda gli approcci sulla correzione dei bug, li trovo un po 'più personali, ma concordo sul fatto che cercare di ridurre il numero di componenti interagenti commentando parte del codice è un approccio valido (non sempre il migliore, ma solo la pratica può dirti di più)

TL; DR: passare molto tempo a inseguire i bug è frustrante e tutti gli sviluppatori devono affrontarli. Questo è semplicemente parte del lavoro. Essere più disciplinati di solito riduce il numero di bug e la loro gravità, ma comunque dovrai affrontare la frustrazione e perdere tempo.

Se vuoi eliminare tutte le notti, vai a letto quando sei stanco.

Se il tuo capo / manager ritiene che il software sia reso migliore affrettandosi a rispettare una scadenza, si sbagliano.

O trovi un datore di lavoro diverso che sa qualcosa su come trattare correttamente i suoi dipendenti, o semplicemente andare a dormire quando sei stanco e tornare al problema il giorno lavorativo successivo.

"Comment all code and start by uncommenting a line at a time. Iteratively running the code"

Lo faccio anche oggi. Beh qualcosa di simile. Esprimo il mio commento su tutto il codice. Correre. Decifra la metà del codice. Correre. Scopri da dove proviene la metà degli affari divertenti. Taglia quello a metà. Rince e ripeti. Lo chiamo facendo una ricerca binaria dai bug. È un po 'più veloce di una linea alla volta. È molto utile quando ti trovi in lunghi procedimenti. Forse smettere di scrivere quelli.

Begin to Think that the issue that I am expecting is not the problem. Something else is!

Quando il debugging è sempre disposto a imparare qualcosa. Mi sorprendo a perdere tempo a insistere affinché l'universo funzioni nel modo in cui penso che dovrebbe.

It's time to talk to someone.

A volte è solo il momento di parlare. Inizia con anatra di gomma . Sono bravi ascoltatori.

It's probably a data issue.

Non mi fido mai di nulla funziona finché non ho un modo per visualizzare i dati. Perché pensi che tutti siano così ossessionati dal vedere "ciao mondo"?

integration testing

Of recent my experience has been when I started integration testing as a part of a new development. The test fixture setup was the thing taking most time than actual test case or the development itself. It was like I spent more than 2 days fighting with test setup for a single test class.

Would really help to know how can I reduce the stress involved in such situations. Or have you faced such situations? Or any other thoughts from the Masters ? Does facing this issue frequently suggest inefficiency ?

I test di integrazione dovrebbero essere automatizzati. Periodo.

Questo è tristemente seguito raramente. Per questo motivo è senza dubbio l'esperienza più misera che ho avuto in tutto l'IT (nemmeno lo sviluppo).

I test di integrazione richiedono ripetibilità automatica. Raggiungere questo può metterti alla prova dal momento che a volte il tuo programma di programmazione non può farlo. Potrebbe essere necessario imparare effettivamente come gettare il peso nel tuo sistema operativo.

In realtà ho imparato a scrivere iDSL perché ero stufo dei test di integrazione manuale. Ho scritto un mini linguaggio che mi consente di configurare tutto ciò di cui avevo bisogno per eseguire il mio codice esattamente come sarebbe stato nella produzione. Quando ho finito potevo facilmente abbandonare le mie nuove cose in alcune espressioni che hanno dato vita al sistema. Certo, avrei potuto seguire la sceneggiatura, avrei potuto farlo a mano. Ma dannazione, io sono un programmatore, non un operatore. Ho fatto questo a un sistema che non è stato nemmeno progettato per questo tipo di test.

Sinceramente quello che avevo era un test end-to-end. Questo non ha toccato la gui e stava accadendo nel mio ambiente di sviluppo. Ma c'erano così tanti bug di configurazione perché il test manuale era un incubo che dovevo fare. L'allestimento ha richiesto tempo. Ma l'uomo ha pagato.

Ora puoi ottenere strumenti di terze parti che si vantano di poter fare questa merda per te, ma nessuno conosce il tuo sistema meglio di te. Se stai pensando che ci deve essere un modo migliore, c'è. Devi solo preoccuparti di farlo.

Evitare gli ospiti notturni nello sviluppo del software inizia con la pianificazione e la corretta tecnica di stima. In molti casi, se stai ancora programmando l'ultimo minuto, è perché lo sforzo è stato sottovalutato o non è stato affrontato in anticipo.

Non sei certo da solo - ogni sviluppatore ha affrontato questo tipo di situazione. Il momento di parlare con qualcuno è spesso all'inizio, gestendo l'approccio o il progetto proposto contro qualcun altro, per ottenere la loro opinione.

Quando effettui una stima, non assumere lo scenario migliore o il peggiore, ma considera la possibilità che il tuo approccio tecnico sia errato e quali attività aggiuntive dovresti fare per risolvere il problema. Assicurati di aver preso in considerazione il test delle unità, i test di integrazione e la risoluzione dei difetti.

L'iter iterativo del codice, come descritto, può essere un buon approccio durante la risoluzione dei problemi, semplificando e isolando l'area del problema in modo da poter rilevare il problema specifico.

Scrivere test, come in TDD, può davvero aiutare anche in questo scenario, perché ti fa lavorare un po 'alla volta, verificando la tua funzionalità mentre procedi. Mentre crei più test, è più facile capire quando e dove il tuo codice si è rotto.