IT担当者以外の人とビジネスロジックをプログラミングする
IT以外の人がコーディングプロセス中にプログラマーと一緒に作業した経験はありますか？
ペアプログラミングのようなものですが、1人はビジネスについてよく知っている非IT担当者であり、計算の方法を知っていて、非慣用的な手続き型コードを理解できる数学のバックグラウンドを持つプロセスエンジニアかもしれません。
PL/SQLのような一部の手続き型のドメイン固有言語は、IT以外のエンジニアでも理解できることがわかりました。これらの人々は結局、コードの共著者となり、公式、因子などの正確さを保証します。
この種のペアプログラミングは非常に生産的であることがわかりました。この種のエンジニアリングタイプのユーザーは、コードの「所有者」および「作成者」でもあり、通信プロセスの誤解を最小限に抑えるのに役立つと感じています。テストケースの設計にも役立ちます。
- この習慣は一般的ですか？
- 名前はありますか？
- 同様の経験はありますか？
これを共有コーディングセッションとして説明していますが（1人しか「運転」していないため、ペアプログラミングとは言えません。ペアプログラミングでは、両方の当事者がキーボードを使用してコードを記述します）、それを受け入れ基準と呼びます。 。
つまり、ビジネスユーザー（非常に技術的な役割を持つエンジニア）を使用してビジネスルール（正しい計算とプロセス）を検証しています。
この場合、それはすぐに書かれたコード（SQL）に変換されますが、他の多くのアクティビティはそうではありませんが、さまざまな言語およびプラットフォーム用の自動受け入れテストツールがあります（特に ガーキン言語）について考えています =および関連するツール）。
この慣行は一般的ではありませんが、ますます多くのフォロワーを獲得しており、フォローする人は（実行可能な形式で受け入れ基準を取得）、ビジネスとのコミュニケーションと推進の両方のツールとして非常に貴重であると感じています開発。
はい。私が仕事をしているときは、筋金入りのプログラミングタイプのことをしていますが、ストラテジストは、ええと戦略に取り組んでいます。つまり、彼らの取引モデルを実装するプログラムを書いているということです。
その鍵となるのは、右の隣に座って、アイデアが何であるかを正確に理解し、それらに付随する可能性があるが実行側にとって重要なことについて多くの質問をすることです。たとえば、モデルに影響するかどうかに関係なく、取引を実行する必要がある速さについて尋ねます。これは、コードの記述方法に大きな影響を与えます。実際、私たちは毎日座って作業しているので、質問を部屋に吹きかける傾向があります。
双方向のフィードバックがあります。トレーディングスキームを簡単に構築できないと彼らに言った場合、彼らは戻って意思決定側でどのトレードオフを行うことができるかについて考えます。新しい戦略に新機能が必要だと彼らが判断した場合、構築にかかる時間と潜在的な落とし穴についてチャットで話します。
彼らは時々取引戦略のいくつかの側面をカプセル化するコードモジュールを実行しますが、私はすべての異なる戦略とバックエンドの運用に関するものを追跡できるようにするアーキテクチャにそれらを一緒にマッサージします。そうすれば、システムの核心を知る必要がなくなります。