IT以外の人とプログラミングビジネスロジックのペアリング[終了]

コーディングプロセス中に非IT担当者がプログラマーと連携する経験はありますか？

それはペアプログラミングのようなものですが、一人はビジネスについて多くのことを知っている非ITの人です。おそらく、物事の計算方法を知っており、非慣用的な手続きコードを理解できる数学のバックグラウンドを持つプロセスエンジニアです。

PL / SQLのような手続き型のドメイン固有言語は、IT以外のエンジニアでも非常に理解しやすいことがわかりました。これらの人物は最終的にコードの共著者となり、式、要因などの正確性を保証します。

この種のペアプログラミングは非常に生産的であり、この種のエンジニアリングタイプのユーザーは、コードの「所有者」および「作成者」であると感じ、コミュニケーションプロセスの誤解を最小限に抑えます。テストケースの設計にも役立ちます。

• この慣習は一般的ですか？
• 名前はありますか？
• 同様の経験がありますか？

これを共有コーディングセッションとして説明していますが（ペアプログラミングと呼ぶことはできません。1人の人が「運転」しているためです。ペアプログラミングでは、両方がキーボードを使用してコードを記述します）、受け入れ基準を収集すると呼びます。

つまり、ビジネスルール（非常に技術的な役割を持つエンジニア）でビジネスルール（正しい計算とプロセス）を検証しています。

この場合、すぐに記述されたコード（SQL）に変換されますが、他の多くのアクティビティではそうではありませんが、異なる言語およびプラットフォーム用の自動化された受け入れテストツールがあります（特にガーキン言語と関連ツールについて考えています）。

この慣習は本来あるべきほど一般的ではありませんが、ますます多くのフォロワーを獲得し、それに従う人（実行可能な形式で受け入れ基準を取得する）は、ビジネスと通信し、運転するためのツールとして非常に貴重であると感じています開発。

はい。私が働いているところでは筋金入りのプログラミングタイプの仕事をしていますが、ストラテジストはuhm戦略に取り組んでいます。つまり、取引モデルを実装するプログラムを作成します。

これの鍵は、彼らのすぐ隣に座って、アイデアが何であるかを正確に理解し、彼らにとって偶然かもしれないが実行側にとって重要なものについて多くの質問をすることです。たとえば、モデルに影響するかどうかにかかわらず、取引を実行する必要がある速さについて質問します。これは、コードの記述方法に大きな影響を及ぼします。実際、私たちは毎日そこに座っているので、部屋に質問を投げかける傾向があります。

双方向のフィードバックがあります。私は彼らにいくつかの取引スキームを構築するのは簡単ではないだろうと言ったら、彼らは戻って、意思決定側でどのトレードオフが作られるかについて考えます。新しい戦略に新しい機能が必要であると判断した場合、構築にかかる時間と潜在的な落とし穴について話し合います。

彼らは時々取引戦略のいくつかの側面をカプセル化するコードモジュールを実行しますが、私はすべての異なる戦略とバックエンド運用のものを追跡できるアーキテクチャにそれらの部分を一緒にマッサージします。そうすれば、システムの本質を知る必要がなくなります。