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

14

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

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

Ho scoperto che alcuni linguaggi procedurali e specifici del dominio come PL / SQL sono abbastanza comprensibili da parte di tecnici non IT. Queste persone diventano coautori del codice e garantiscono la correttezza di formule, fattori, ecc.

Ho trovato che questo tipo di programmazione di coppie è abbastanza produttivo, questo tipo di utenti di ingegneria si sentono anche "proprietari" e "autori" del codice e aiutano a minimizzare le incomprensioni nel processo di comunicazione. Aiutano persino a progettare casi di test.

  • Questa pratica è comune?
  • Ha un nome?
  • Hai avuto esperienze simili?
posta Tulains Córdova 20.10.2012 - 06:25
fonte

2 risposte

11

Sebbene tu lo stia descrivendo come una sessione di codifica condivisa (non posso chiamarla programmazione di coppia, dato che solo una persona sta "guidando" - nella programmazione in coppia, entrambe le parti prendono la tastiera e scrivono il codice), la chiamerei raccolta dei criteri di accettazione.

Cioè, stai convalidando le regole aziendali (calcoli e processi corretti) con l'utente aziendale (anche se 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à, sebbene ci siano strumenti di test di accettazione automatici per diverse lingue e piattaforme (sto pensando specificamente a gherkin language e strumenti correlati).

Questa pratica non è così comune come dovrebbe essere, ma sta guadagnando sempre più follower e chi la segue (ottenendo i criteri di accettazione in una forma che può essere eseguita) lo trova inestimabile sia come strumento per comunicare con il business e per guidare lo sviluppo.

    
risposta data 20.10.2012 - 07:20
fonte
2

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

La chiave di questo è sedersi accanto a loro giusto e capire esattamente quali sono le idee, e fare molte domande su cose che potrebbero essere secondarie a loro, ma importanti per il lato dell'esecuzione. Per esempio, chiederei sulla velocità con cui un trade deve essere eseguito, indipendentemente dal fatto che questo influenzi il loro modello. Questo ha un enorme impatto su come scriverò il codice. In effetti tendo a spruzzare domande nella stanza mentre siamo seduti lì a lavorare ogni giorno.

C'è un feedback bidirezionale. Se dico loro che alcuni schemi di trading non saranno facili da costruire, tornano indietro e pensano a quali trade-off possono essere fatti sul lato decisionale. Se decidono che la loro nuova strategia ha bisogno di qualche nuova funzionalità, ho una chat con loro su quanto tempo ci vorrebbe per costruire e quali sono le potenziali insidie.

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

    
risposta data 28.06.2013 - 14:59
fonte