È normale sottoporre a critiche i prodotti di sviluppo del software?

3

Attualmente sono uno sviluppatore di software su Coop che si trovava in una situazione interessante oggi. Non posso dire troppo, dato che le cose che faccio sono sotto NDA, ma faccio i componenti di Grasshopper 3D (che è un plugin di Rhino).

La nostra azienda ha meno di tre sviluppatori di software, incluso me. Siamo tutti specializzati in diverse lingue. In questo progetto a cui stavo lavorando, ero incaricato di creare un software che avesse un uso generale molto ampio. È un'estensione dal tipico comportamento di Grasshopper.

Con questo detto, l'altro sviluppatore con cui ho lavorato è stato in questo settore per un buon decennio o due. È molto ben informato sull'uso di Grasshopper. La sua formazione precedente comportava un grande uso di esso, e il suo lavoro quotidiano comporta l'uso di Grasshopper (anche se non esplicitamente quello che sto facendo, che sta creando componenti C # per questo).

Detto questo, il mio componente finale ha attraversato un certo numero di iterazioni. Sembrava che ogni iterazione fosse migliore della precedente. Un punto interessante è che l'altro sviluppatore con cui ho lavorato (ero essenzialmente sotto la sua ala) riesce a rompere il mio componente ogni volta. Non intendo questo in modo malevolo.

Rompendo, intendevo, era in grado di traboccare liste particolari. È stato in grado, dopo quasi ogni iterazione, di trovare modi in cui il mio componente potesse essere migliorato. Onestamente, mi sento davvero grato per i suoi suggerimenti e critiche, perché queste erano onestamente cose che o ho trascurato, o che non sapevo, potrebbero accadere.

La mia domanda è triplice:

  1. È normale che le pratiche di sviluppo del software / le aziende abbiano critiche a qualcuno e migliorino il tuo codice? Non c'è stata una revisione del codice. Era semplicemente il modo di migliorare lo strumento migliorando UX o migliorando il back-end. E onestamente, anche se non c'era la revisione del codice, ho imparato tanto dai suoi suggerimenti che ho sempre trovato successo nell'implementazione.

  2. Ci sono suggerimenti per una procedura di test più "formale"? Sono relativamente nuovo al mondo dello sviluppo del software, quindi sono interessato alle procedure di test del software.

  3. Come posso migliorare il mio modo di "prevedere" i problemi?

Da un lato, sento che ci sono problemi che normalmente non riesco a scoprire da me perché tutti usano un software in modo diverso. Da un altro lato, sento che potrebbe essere la mia supervisione o incompetenza a causare questo.

Sto leggendo questo thread , e sembra in un certo senso, abbiamo una procedura di test libera, anche se dipende tutto da me per chiedere una critica.

    
posta theGreenCabbage 05.02.2014 - 02:28
fonte

2 risposte

3

Per migliorare la tua capacità di prevedere i problemi:

  • Cerca casi limite. Se la tua funzione opera su numeri, come gestisce 0? Numeri negativi? Numeri molto grandi? Se funziona su stringhe, può gestire una stringa vuota? Una stringa con 10.000 caratteri? Cosa non ti aspettavi di accadere quando lo hai scritto?
  • Cerca problemi simili ad altri che sono stati trovati prima. Hai detto che è stato in grado di traboccare liste particolari. Essere alla ricerca di problemi di overflow della lista.
  • Cerca i pattern negli errori. C'è qualcosa in particolare da "perdere" sempre? Allora stai attento.
  • Scopri questo software Grasshopper su cui stai lavorando meglio. Parte della capacità dello sviluppatore anziano di vedere i problemi può essere dovuta alla sua familiarità con esso.
  • Chiedi allo sviluppatore senior. Come qualcuno con molta esperienza, probabilmente ha buoni consigli su come trovare bug e scrivere codice in generale, e su Grasshopper in particolare.
risposta data 05.02.2014 - 17:10
fonte
8
  1. sì, si chiama QA

  2. Quando qualcuno scopre un bug, crea un test che lo riproduca, quindi correggi il codice in modo che il test passi. In questo modo, questo specifico problema non dovrebbe mai più apparire.

  3. pratica, pratica, pratica.

Per ridurre la tua dipendenza dai test esterni, assicurati di incorporare il maggior numero di test possibile nella stessa procedura di codifica. Considerare ogni specifica dei requisiti come fonte di test. Quindi scrivi il codice per far passare quei test.

    
risposta data 05.02.2014 - 02:52
fonte

Leggi altre domande sui tag