人的要因または「契約が機能しない」
状況を想像してください。 あなたとあなたのチームは、次のイテレーションの後、テストで脆弱なコードカバレッジについて議論し、現在の月曜日から誰もが新しいコードとポップアップバグの両方のテストを書くことを決定します。 合理的であると思われ（最後に失敗した展開を思い出す人もいます）、全員が同意し、満足している人は、今はすべてがうまくいくという考えに同意しません。 次の会議の時が来ました。その間、「テストはどうですか？」という質問の中で大多数が目をそらしました。 結果は明確で、すべてが以前のままです。
もちろん、そうでない人を見つけ出し、その理由を見つけ、教育的な会話をすることもできます）、これはしばらくの間も役立ちます。 そして時間が経ち、すべてが同じになります。 さらに、この問題に関する合意に従う人々は、別の問題ではすべてを自分のやり方で行うことができ、逆もまた同様です。
別の状況。 このプロジェクトには、アクセス権システムが必要であり、チームメンバーの1人によって実装されました。 ライブラリは、強力で柔軟性があり、一般的に便利であることが判明しました。 彼らはそれを積極的に使用し始め、しばらくすると、多くの人がライブラリを操作するためのルールを無視することに同意します（契約）アクセスルールの複雑さ。
これらの状況を結び付けるものは何ですか？ 不十分なプロセス制御。 あなたは完全に異なる方法で制御することができます。以下に、それをどのように行うのが最善か、その理由についての考えを共有したいと思います。
そもそも、制御は条件付きで（この記事のコンテキストで）2つのカテゴリに分類できます。内部と外部です。 内部統制は、プロジェクトレベル全体および特定のライブラリの設計（インターフェイス設計）の両方で、特定のアーキテクチャソリューションの助けを借りた自動化されたチェックと制限です。 外部は、レビュー担当者（静的分析ツールを含む）による準備状況の確認です。
例：
データベースの外部キー-内部管理。
デフォルトでは、acl-内部制御を使用して「すべてが禁止されています」。
マネージャはチケットのコミットを監視します-外部制御。
静的コード分析-外部制御。
両方のタイプの制御が重要です。 同時に、自動的に制御できるすべてのものを自動化して、外部制御を内部に変換する必要があります。 基本的に、「最小限の制御で最大限のコード品質を達成し、人的要因を排除する」方法に関する記事です。 これはあなたの神経を節約し、ソフトウェア製品の品質に対する人間の影響を最大限に排除するのに役立ちます。
-ベースは独立してその整合性（fk、check）を維持し、入力データに関して可能な限り厳密でなければなりません。 その後、ほとんどの開発エラーは最も早い段階で特定されます。
-「許可されていないものはすべて禁止」という原則が常に使用されます。
-内部コンポーネントを設計するときは、プロセスと使用で従わなければならないルールを最小限に抑えるよう努力する必要があります。 場合によっては、柔軟性が失われます（ただし、問題や障害にならないようにします）。 Pythonの哲学が役立ちます。
-テストでmokasを使用するのは、緊急の必要がある場合（外部サービス）のみです。そうしないと、実際のコードの各行について、テストで複数の行を変更する必要があり、最終的にはチーム全体の負担になります。
-内部ライブラリ（アプリケーション自体のコードとは異なります）は、メイン開発者の同意がなければ変更できません。 ここでは、制御なしでは実行できませんが、必要な条件に従ってコードをコミットできないようにするバージョン管理システムでフックを作成することで、問題を部分的に解決できます。
-開発中、「忘れることができない」ことを常に念頭に置いておく必要がある場合、何かが間違っている可能性があります。 リファクタリングを実行できないため考えられない場合は、少なくともコード自体が要件をチェックし、それらについてレポートするようにする必要があります（たとえば、例外をスローする）。
-最初に記述または使用されるコード（最初のデーモン、aclまたは他のコンポーネントの最初の使用）は、将来的に誰もがそれに集中するため、非常に高品質で記述する必要があります。
-ペアでプログラミングすると、コードの品質が向上します。
-可能な限り、タスクを変更し、「Vasyaだけが理解しているが、2週間目は病気である」という状況に陥らないようにする必要があります。
-すべてのコードが「メイン開発者」を通過するように開発プロセスを整理します。 契約ではなく、VCSルール自体を使用します。これにより、トランク（マスター）への書き込みアクセス権は彼だけに与えられます。
-継続的インテグレーションを使用します。 そして、赤旗が標準になるべきではありません。
-コード要件を作成してレビューします。
もちろん、これだけではありません。 以下に、説明したアプローチを実際のコードに適用する例をいくつか示します。
プロジェクトには多数のデーモンがあり、フレームワークはクラスを継承し、runメソッドをオーバーライドすることを提案しています。 当然、この方法では、小さなデーモンのコード全体を書くことができます（これは実際に行われることがよくあります）。 そのコードにアクセスしてテストすることはほとんど不可能です。 論理的な解決策は、各デーモンに個別のクラスを記述するように全員に依頼し、runメソッドでは呼び出しのみを行うことです。 ただし、これは最大限の外部制御でのみ機能するため、フレームワークのこの部分への直接アクセスをブロックし、デーモンクラスをプロキシコードに転送する必要があります。 彼はすべての打ち上げ作業を行いますが、間違って書くことは単に不可能または非常に困難です。 これはおそらく「構文酢©」です。
別のプロジェクトでは、すべてのビジネスロジックがデータベース内にあり、データベースへのアクセスはプロシージャコールによってのみ実行されました。 データベースへのアクセスの編成は、通常のsqlコマンドを許可しない限定バージョンで実装されました。 したがって、この側面を監視する必要はありませんでした。
一般的に言えば、正しいことは簡単かつ自然に行われ、望ましくないものは不可能であるか非常に困難な方法でシステムを作成してください。
updこれは人々を制御することではありません！ これは非常に重要です。 ひもにつないで、すべてのステップを制御する必要はありません。 冷静にコードをコミットさせますが、レビューのために欠陥を特定し、修正のためにコードを送信できます。
多くの人がここに追加するものがあると思います。 あなたの経験を聞いてうれしいです。
psは、編集と改善に感謝します。
もちろん、そうでない人を見つけ出し、その理由を見つけ、教育的な会話をすることもできます）、これはしばらくの間も役立ちます。 そして時間が経ち、すべてが同じになります。 さらに、この問題に関する合意に従う人々は、別の問題ではすべてを自分のやり方で行うことができ、逆もまた同様です。
別の状況。 このプロジェクトには、アクセス権システムが必要であり、チームメンバーの1人によって実装されました。 ライブラリは、強力で柔軟性があり、一般的に便利であることが判明しました。 彼らはそれを積極的に使用し始め、しばらくすると、多くの人がライブラリを操作するためのルールを無視することに同意します（契約）アクセスルールの複雑さ。
これらの状況を結び付けるものは何ですか？ 不十分なプロセス制御。 あなたは完全に異なる方法で制御することができます。以下に、それをどのように行うのが最善か、その理由についての考えを共有したいと思います。
そもそも、制御は条件付きで（この記事のコンテキストで）2つのカテゴリに分類できます。内部と外部です。 内部統制は、プロジェクトレベル全体および特定のライブラリの設計（インターフェイス設計）の両方で、特定のアーキテクチャソリューションの助けを借りた自動化されたチェックと制限です。 外部は、レビュー担当者（静的分析ツールを含む）による準備状況の確認です。
例：
データベースの外部キー-内部管理。
デフォルトでは、acl-内部制御を使用して「すべてが禁止されています」。
マネージャはチケットのコミットを監視します-外部制御。
静的コード分析-外部制御。
両方のタイプの制御が重要です。 同時に、自動的に制御できるすべてのものを自動化して、外部制御を内部に変換する必要があります。 基本的に、「最小限の制御で最大限のコード品質を達成し、人的要因を排除する」方法に関する記事です。 これはあなたの神経を節約し、ソフトウェア製品の品質に対する人間の影響を最大限に排除するのに役立ちます。
内部統制
-ベースは独立してその整合性（fk、check）を維持し、入力データに関して可能な限り厳密でなければなりません。 その後、ほとんどの開発エラーは最も早い段階で特定されます。
-「許可されていないものはすべて禁止」という原則が常に使用されます。
-内部コンポーネントを設計するときは、プロセスと使用で従わなければならないルールを最小限に抑えるよう努力する必要があります。 場合によっては、柔軟性が失われます（ただし、問題や障害にならないようにします）。 Pythonの哲学が役立ちます。
-テストでmokasを使用するのは、緊急の必要がある場合（外部サービス）のみです。そうしないと、実際のコードの各行について、テストで複数の行を変更する必要があり、最終的にはチーム全体の負担になります。
-内部ライブラリ（アプリケーション自体のコードとは異なります）は、メイン開発者の同意がなければ変更できません。 ここでは、制御なしでは実行できませんが、必要な条件に従ってコードをコミットできないようにするバージョン管理システムでフックを作成することで、問題を部分的に解決できます。
-開発中、「忘れることができない」ことを常に念頭に置いておく必要がある場合、何かが間違っている可能性があります。 リファクタリングを実行できないため考えられない場合は、少なくともコード自体が要件をチェックし、それらについてレポートするようにする必要があります（たとえば、例外をスローする）。
-最初に記述または使用されるコード（最初のデーモン、aclまたは他のコンポーネントの最初の使用）は、将来的に誰もがそれに集中するため、非常に高品質で記述する必要があります。
-ペアでプログラミングすると、コードの品質が向上します。
外部制御
-可能な限り、タスクを変更し、「Vasyaだけが理解しているが、2週間目は病気である」という状況に陥らないようにする必要があります。
-すべてのコードが「メイン開発者」を通過するように開発プロセスを整理します。 契約ではなく、VCSルール自体を使用します。これにより、トランク（マスター）への書き込みアクセス権は彼だけに与えられます。
-継続的インテグレーションを使用します。 そして、赤旗が標準になるべきではありません。
-コード要件を作成してレビューします。
もちろん、これだけではありません。 以下に、説明したアプローチを実際のコードに適用する例をいくつか示します。
プロジェクトには多数のデーモンがあり、フレームワークはクラスを継承し、runメソッドをオーバーライドすることを提案しています。 当然、この方法では、小さなデーモンのコード全体を書くことができます（これは実際に行われることがよくあります）。 そのコードにアクセスしてテストすることはほとんど不可能です。 論理的な解決策は、各デーモンに個別のクラスを記述するように全員に依頼し、runメソッドでは呼び出しのみを行うことです。 ただし、これは最大限の外部制御でのみ機能するため、フレームワークのこの部分への直接アクセスをブロックし、デーモンクラスをプロキシコードに転送する必要があります。 彼はすべての打ち上げ作業を行いますが、間違って書くことは単に不可能または非常に困難です。 これはおそらく「構文酢©」です。
別のプロジェクトでは、すべてのビジネスロジックがデータベース内にあり、データベースへのアクセスはプロシージャコールによってのみ実行されました。 データベースへのアクセスの編成は、通常のsqlコマンドを許可しない限定バージョンで実装されました。 したがって、この側面を監視する必要はありませんでした。
一般的に言えば、正しいことは簡単かつ自然に行われ、望ましくないものは不可能であるか非常に困難な方法でシステムを作成してください。
updこれは人々を制御することではありません！ これは非常に重要です。 ひもにつないで、すべてのステップを制御する必要はありません。 冷静にコードをコミットさせますが、レビューのために欠陥を特定し、修正のためにコードを送信できます。
多くの人がここに追加するものがあると思います。 あなたの経験を聞いてうれしいです。
psは、編集と改善に感謝します。
All Articles