Associare la logica di business di programmazione a una persona non IT [chiuso]

Hai avuto esperienza in cui una persona non IT lavora con un programmatore durante il processo di codifica?

È come la programmazione di coppia, ma una persona è una persona non IT che conosce molto il business, forse un ingegnere di processo con background matematico che sa come vengono calcolate le cose e può capire un codice procedurale non idiomatico.

Ho scoperto che alcuni linguaggi procedurali specifici del dominio come PL / SQL sono abbastanza comprensibili da ingegneri non IT. Queste persone finiscono per essere coautrici del codice e garantiscono la correttezza di formule, fattori, ecc.

Ho trovato questo tipo di programmazione di coppia abbastanza produttivo, questo tipo di utenti di tipo ingegneristico sentono di essere anche "proprietari" e "autori" del codice e aiutano a minimizzare i malintesi nel processo di comunicazione. Aiutano persino a progettare casi di test.

• Questa pratica è comune?
• ha un nome?
• Hai avuto esperienze simili?

Sebbene tu lo descriva come una sessione di codifica condivisa (non posso chiamarla programmazione di coppia, poiché solo una persona sta "guidando" - nella programmazione di coppia, entrambe le parti prendono la tastiera e scrivono il codice), la chiamerei raccogliendo criteri di accettazione .

Cioè, stai convalidando le regole di business (calcoli e processi corretti) con l'utente aziendale (anche se uno con un ruolo molto tecnico, un ingegnere).

In questo caso, si traduce immediatamente in codice scritto (SQL), ma per molte altre attività non lo sarà, anche se esistono strumenti di test di accettazione automatizzati per lingue e piattaforme diverse (sto pensando specificamente al linguaggio gherkin e agli strumenti correlati).

Questa pratica non è così comune come dovrebbe essere, ma sta guadagnando sempre più follower e coloro che la seguono (ottenendo criteri di accettazione in una forma che può essere eseguita) la trovano preziosa sia come uno strumento per comunicare con l'azienda sia per guidare sviluppo.

Sì. Dove lavoro, faccio roba di programmazione hardcore, mentre gli strateghi lavorano sulla strategia uhm. Vale a dire che scrivo i programmi che implementano i loro modelli di trading.

La chiave di tutto ciò sta nel giusto accanto a loro e capire esattamente quali sono le idee, e porre molte domande su cose che potrebbero essere secondarie a loro, ma importanti per il lato dell'esecuzione. Ad esempio, vorrei sapere quanto velocemente deve essere eseguita una transazione, se ciò influisce sul loro modello. Questo ha un impatto enorme su come scriverò il codice. In realtà tendo a spruzzare domande nella stanza mentre siamo seduti lì a lavorare ogni giorno.

C'è un feedback a due vie. Se dico loro che alcuni schemi di trading non saranno facili da costruire, tornano indietro e pensano a quali compromessi possono essere fatti dal lato decisionale. Se decidono che la loro nuova strategia necessita di alcune nuove funzionalità, ho una chat con loro su quanto tempo ci vorrebbe per costruire e quali sono le potenziali insidie.

Fanno moduli di codice che incapsulano di volta in volta alcuni aspetti della strategia di trading, ma io massaggio i pezzi insieme in un'architettura che ci consente di tenere traccia di tutte le diverse strategie e di operazioni operative di back-end. In questo modo non hanno bisogno di conoscere il nocciolo del sistema.