IT 프로세스가 아닌 사람이 코딩 프로세스 중에 프로그래머와 함께 작업 한 경험이 있습니까?
페어 프로그래밍과 비슷하지만 한 사람은 비즈니스에 대해 많은 것을 알고있는 비 IT 사람 일 수 있습니다. 어쩌면 계산 방법을 알고 있고 비 아이디어적인 절차 적 코드를 이해할 수있는 수학 배경을 가진 프로세스 엔지니어 일 수도 있습니다.
PL / SQL과 같은 일부 절차 적 도메인 별 언어는 IT 전문가가 아닌 사람도 이해할 수 있습니다. 이 사람들은 결국 코드의 공동 저자가되고 공식, 요소 등의 정확성을 보장합니다.
나는 이런 종류의 페어 프로그래밍이 상당히 생산적이라는 것을 발견했다. 이런 종류의 엔지니어링 타입 사용자는 그들이 코드의 "소유자"및 "저자"라고 느끼고 통신 과정에서 오해를 최소화하는 데 도움이된다. 테스트 케이스 설계에도 도움이됩니다.
답변:
이것을 공유 코딩 세션으로 설명하고 있지만 (한 사람 만 운전하고 있기 때문에 페어 프로그래밍이라고 부를 수는 없습니다-페어 프로그래밍에서는 두 사람이 키보드를 사용하여 코드를 작성합니다), 나는 수용 기준을 수집한다고 부릅니다. .
즉, 비즈니스 사용자 (매우 기술적 인 역할이있는 엔지니어)와 함께 비즈니스 규칙 (정확한 계산 및 프로세스)을 검증하고 있습니다.
이 경우 즉시 작성된 코드 (SQL)로 변환되지만 다른 언어 및 플랫폼에 대한 자동 수락 테스트 툴링이 있지만 (특히 작은 오이 언어 및 관련 툴링에 대해 생각하고 있음) 많은 다른 활동에는 적용되지 않습니다 .
이 관행은 그다지 흔하지는 않지만 점점 더 많은 추종자와 점점 더 많은 추종자를 얻고 있습니다 (실행 가능한 형태로 수용 기준을 얻음). 개발.
예. 내가 일하는 곳에서 나는 하드 코어 프로그래밍 유형의 일을하는 반면, 전략가들은 움 전략을 연구한다. 즉, 거래 모델을 구현하는 프로그램을 작성합니다.
이것의 핵심은 바로 옆에 앉아 아이디어가 무엇인지 정확히 이해하고, 부수적이지만 실행 측면에 중요한 것에 대해 많은 질문을하는 것입니다. 예를 들어, 거래가 얼마나 빨리 실행되어야하는지, 그것이 모델에 영향을 미치는지 여부를 묻습니다. 이것은 코드 작성 방법에 큰 영향을 미칩니다. 사실 나는 매일 작업하면서 그곳에 질문을하는 경향이 있습니다.
양방향 피드백이 있습니다. 내가 그들에게 어떤 거래 계획을 세우기가 쉽지 않다고 말하면, 그들은 돌아가서 의사 결정 측면에서 어떤 트레이드 오프가 이루어질 수 있는지 생각합니다. 그들이 새로운 전략에 새로운 기능이 필요하다고 결정하면, 구축하는 데 걸리는 시간과 잠재적 인 함정에 대해 이야기합니다.
그들은 때때로 거래 전략의 일부 측면을 캡슐화하는 코드 모듈을 수행하지만, 백엔드 운영 항목뿐만 아니라 모든 다른 전략을 추적 할 수있는 아키텍처로 조각들을 함께 모아 놓습니다. 그렇게하면 시스템의 핵심을 알 필요가 없습니다.