Come garantire un progetto testato al 100%?

Risposta breve - non puoi. Non appena esporti un'applicazione su una rete, hai introdotto un numero infinito di possibili variazioni e condizioni che non puoi probabilmente prevedere con certezza del 100%. Cosa succede quando un utente fa qualcosa di incredibilmente stupido o imprevedibile? Cosa succede quando un utente malintenzionato elabora i tuoi processi e genera un trucco? Cosa succede quando reti o hardware non funzionano? Non riuscirai mai a prenderlo tutto.

Detto questo, devi giocare alle probabilità. La tua base di utenti, i clienti e i proprietari di attività commerciali dovrebbero essere in grado di identificare in che modo si aspettano che l'applicazione venga utilizzata. Cioè, i tuoi requisiti . Assicurati che ciascun requisito abbia sia casi di test positivi che negativi basati su un campione ragionevole di dati e azioni di test. Dopodiché, è davvero il caso di escogitare modi in cui l'applicazione potrebbe essere utilizzata in modo improprio e sviluppare casi di test intorno a loro. È sempre possibile fare un altro test, e quindi la mia precedente affermazione che il 100% è irraggiungibile.

È possibile misurare la copertura del codice fino al 100% (con il valore degli ultimi punti percentuali discutibili). Questo assicurerà che se qualcuno del tuo codice viene raggiunto ed eseguito, si comporterà in un modo atteso. La copertura del codice non garantisce la correttezza della tua domanda, solo che sai che tutto funzionerà sempre a volte.

Il problema con la codifica nella finanza è, almeno negli ambienti di mercato come i trading desk, che il codebase è costruito da programmatori non professionisti, per lo più matematici o in quantini. Questi ragazzi hanno hackerato copioni matlab e fogli Excel nel modo peggiore possibile.

Questo problema ha diverse fonti:

1. Queste persone non sono programmatori, ma commercianti. Costruire software privo di bug non è il loro lavoro, fare soldi è. Costruiscono script che li aiutano a identificare le opportunità di trading, e di solito sono usati solo in team molto piccoli, dove tutti sanno chi capisce quale parte del codice e quelli sono le uniche persone che usano il codice. Questo porta al punto 2.

2. Utente finale e programmatore sono la stessa persona. La maggior parte del codice che ho visto è Matlab o R, se qualcosa va storto, è fisso ad-hoc. Gli errori emergono durante la preparazione di una presentazione e devono essere corretti rapidamente, il che di solito significa sporco. Se qualcos'altro si rompe nel processo, sarà risolto quando diventa ovvio (probabilmente la prossima presentazione). Questo è il motivo per cui ho cercato di convincere il mio vecchio capo a far rispettare i test unitari, invece ha deciso di far rispettare "il doppio controllo del risultato", e ho deciso di chiudere.

3. C'è un motivo per cui i "math wizards of wall street" sono chiamati quants. Si occupano di modelli finanziari incredibilmente complessi che pochi capiscono, mentre per "pochi" escludo la maggior parte delle persone anche nei lavori quantistici. Una grande parte di questi modelli è spazzatura, e questo ha un impatto molto più grande di un piccolo bug che è in grado di passare inosservato (dopo tutto, i risultati sono sempre soggetti all'interpretazione dell'utente finale - vedi 2).

Ecco quali sono i punti su cui credo possano iniziare:

1. Introduci il controllo della versione. Se sei qui, non ho bisogno di dirti perché. Ma i quants non vengono qui.

2. Test di unità, almeno a livello di script. Invitali a configurare un ambiente di test e quindi a eseguire un test per verificare se i risultati sono ancora buoni. Il requisito minimo è disporre di una serie di dati di test e controllare gli script con questo per vedere se i risultati sono coerenti con i risultati precedenti per evitare di volare ciechi. Ho visto persone modificare il codice e testarlo su una nuova serie di dati, senza alcun indizio se questi numeri hanno senso. Cerca di evitarlo a tutti i costi; almeno avere un'idea di base in cui ti trovi.

3. Revisioni del codice e una base di codice comune. Invece di fare in modo che tutti possano hackerare pezzi di codice individuali che sono stati incollati dai tutorial di Matlab, cerca di far usare a tutti un codice comune e di discutere il codice che essi impegnano con gli altri. Questo ha diversi vantaggi:

   • Il tuo codice è compreso da più membri del team. Questo è importante, poiché il codice viene spesso utilizzato in modo interattivo. Il codice è usato di più e da più persone, che non solo fanno risparmiare tempo, ma anche il prossimo punto.

   • I bug sono più probabili da trovare quando il codice produce risultati inaspettati.

   • Le persone inizieranno ad aggiungere alcuni commenti, almeno nella mia esperienza. Le persone che fanno domande sono solo una perdita di tempo, quindi offri loro la possibilità di capirlo da soli.

4. Sbarazzati di Excel il più possibile. Prova ad utilizzare una sorta di database (cvs va bene per i principianti) che conserva i dati in modo affidabile e non è soggetto a modifiche esterne. Ho avuto situazioni in cui qualcuno ha "pulito" i dati (correggendo le scorte di magazzino ecc.) E ha modificato i dati originali, mentre qualcun altro ha creato un codice da interpolare sui dati mancanti. Excel rende troppo facile rovinare tutto, soprattutto se gli utenti non comprendono completamente il codice.

In questa situazione, il tuo obiettivo non è quello di essere privi di bug (se mai lo è), è quello di far capire al maggior numero possibile di persone il codice. Se hanno un'idea di cosa sta succedendo da dove e da dove provengono i loro numeri, di solito rispettano maggiormente il codice e lavorano più attentamente. Ciò porta a molto meno errori e aumenta la fiducia nei risultati. Una volta che sei lì, puoi iniziare con le tecniche di sviluppo del software avanzate.

Nota ovvia: sto parlando di codice relativo alla strategia di trading qui, non di ciò che sta dietro ai sistemi di contabilità, ecc., perché questi sistemi di back-end sono solitamente costruiti da professionisti. Chiaramente, non sto parlando di professionisti, e nemmeno io ne sono uno.