この世界では、他の開発者が簡単にサポートできるようにコードを記述し、プロジェクトをいつでも他の人に転送してサポートできるようにする必要があると言われています。 しかし、私が数年間住んでいたプロジェクトをまったく別の人に移すのはどんな感じですか？ 誰がプロジェクトの新しいリーダーになりますか-第二の父または邪悪な継父（親愛なる読者、私はあなたの存在を覚えていますが、あなたは少数派です）？ 私たちの頭脳は発達し、強さを獲得するか、それとも死んで、それほど美しいものではなく、明らかにそれほど高品質ではないものになりますか？ 彼の将来を本当に気にする人のために、この記事は書かれています。 ABBYYでは、いくつかのプロジェクトで働いていましたが、さまざまな理由でそれらを残しています。 ほとんどのプロジェクトは、明確な解決策のないタスクです（認識、非公式に記述されたさまざまなオブジェクトの検索など）。
そのため、将来を恐れることなくいつでもプロジェクトを離れることができるように、何をする必要がありますか。 高品質のコード、直感的なインターフェイス、包括的なドキュメント（少なくともコードコメントの形式）に加えて、テストシステムが絶対に必要です。 そして、それ自体がプロジェクトの品質とパフォーマンスを測定し、2つのバージョンのどちらが優れているかを明確に答えます。 そのようなシステムが可能な場合-非常によく、それを作成します。 そうでない場合は、このソリューションにどのように近づくことができるかを検討してください。 開発には何らかのテストシステムが絶対に必要ですが、良くも悪くも明確な答えを出せば、「気分が良い」などのフレーズでプロジェクトへのダメージを避けることができ、真の価格を示すことができますこれらの「感覚」に。
テストシステムは理解可能で拡張可能である必要があります。 可能であれば、単体テストを作成し、難しい場合は、具体的な例を使用して一般的なプロジェクトテストを行います。 簡単なパフォーマンステストがあり、成功または失敗する場合は、これで十分です。 プログラムがどれだけ優れているかを測定できる場合は、2つのバージョンの比較テストを必ず行う必要があります。 そして、これらのテストがこのように配置されていればいいと思います-プログラムを実行し、作業のログを残し、2つのログを比較すると、プログラムの2つのバージョンのどちらが各テストケースで優れているかを簡単に理解できます。 推定値が相加的であることが判明した場合-優れていても、例のグループに結果が残っています。 うまくいかない場合は、これらの推定値を加算する方法を検討してください。
たとえば、画像内のバーコードを探している場合は、バーコードのある画像の束と、バーコードのない別の束が必要です。 テスターは、各ヒープで検出されたバーコード（正確には、バーコードとして解釈されるオブジェクト）の数と、それに費やされた時間を表示する必要があります。 これは最も単純な最小テストです。プロジェクトに真剣に取り組んでいる場合は、すべての画像にマークを付けて、どのバーコードと正確にどこにあるかを示す必要があります。 繰り返しますが、開発時にテストシステムが必要ですが、その答えの明快さと曖昧さは、まず最初に後継者に要求されます。
もう1つの重要なポイントは、小さな欠陥です。 長い間プロジェクトに携わっていると思われる場合、さまざまな些細なことに関するバグレポートを作成せず、手が届くとすぐに修正するように誘惑されます...バグレポート。 ケースの転送中に軽微な欠陥に関する知識だけが失われ、フォーラムに「これらのローファーはいくつかのバージョンでこのような単純な間違いを修正できなかった」というフレーズが表示されるためです。
何かをしようとして失敗したことについては、常にコードにコメントを残してください。 自由に記述してください：ここで、ダンジグアルゴリズムを適用しようとしましたが、このバイパス方法は、特にそのような例で、平均してより効果的であることが判明しました。 私たちがプロジェクトを自分で行っている間、私たちは失敗とその理由について覚えていますが、新しいプロジェクトの所有者はどのようにそれらについて知るのでしょうか？ データ構造についても同じことが言えます。 データを表示するためのオプションがいくつかある場合は、この特定のデータを選択した理由をお気軽にご説明ください。おそらく後継者は、ここで何かを変更する必要があるかどうかを考えるでしょう。
マーケティングによって発音される単語をコードに記述しないでください。顧客に新しいバージョンを購入するように説得してください。 「よりユーザーフレンドリーなインターフェイス」ではなく、「表形式のインターフェイス」であり、「外観の改善」ではなく、「元の色に近くなります」。 さらに、単一のインターフェースに販売するのが非常に便利だったという事実だけによって相互接続されている機能を組み合わせてはいけません。 彼らがそれを売ったクライアントが満足したとき、あなたの後継者は、それがどれほど価値があるかを考えずに、このインターフェース全体とそれに関連するすべてをコードから大胆に捨てることを覚えておいてください。
あなたはプロジェクトを離れています...
あなたの後継者は誰ですか？ あなたのチームの最高のプログラマーなら、何も恐れないでください。 これが最良のシナリオです。 プロジェクトだけでなく、あなたにも最適です。 あなたはできる限りのことをしました。後継者はきっと対処します。 あなたがしなければならないことは、あなたが来年か2年で実現するつもりだったあなたのアイデアで文書を書き、それを新しいリーダーに渡すことです。 ほとんどの場合、あなたの考えは一致します-あなたが長い間並んで働いてきたのは無駄ではありません。 文書を書いた後、後継者に渡して、去ります。 あなただけでプロジェクトの成功を喜ぶことを忘れないでください。正しい方向に発展するための推進力を彼に与えたのはあなただったことを思い出してください。
あなたの後継者が一目でお互いを理解することを学んだ人ではなく、「外から」の人であり、世界の彼の（明らかに間違った）認識であることが判明した場合、状況は多少悪くなります。 間違いなく、アイデアの説明と開発の方向性を記載したドキュメントが必要ですが、最初にこれらのアイデアを後継者に伝える必要があります。 本当に必要なもの：
- すべての機能を文書化します。 すべて、細部に至るまで。 一般的な言葉に限らず、プログラムでできることのリストを書いてください。 そして、あなたの製品がそれが何をするのかを本当に知っていることを誰も疑わないようにするためです。 そして、それを何回か書いてください：文書のあるパパ、ケースの転送に関する手紙、メインヘッダーへのコメント。
- あなたの製品がうまくいくことはできるがそうでないことを書くのは正直です。 どの例で問題なく動作し、どの微調整が必要か。 これらのどれが問題ですか（あなたの観点から）。
- すべてのアーキテクチャソリューションを説明します。 なぜこのようにアーキテクチャを開発したのですか。そうでない場合は、どのようなプロジェクト開発を期待していましたか。
- すべてのテストデータベースを公共の場所に保管してください。 テストシステムがどのように機能し、作業結果をどのように評価するかを後継者に示します。
- コード自体のドキュメントを作成します...しかし、私なしでこれを知らない場合（これはほとんどありません）、あなたはそれを行うことを余儀なくされます。
これをすべて実行した後、後継者が要求することと同様に、プロジェクトに「さようなら」と言うことができます。 あなたは今はその所有者ではないという考えに同意する必要があります。 しかし、もしあなたが情事の移転を大事にすれば、おそらく新しい秩序のスローガンで無意味な破壊を見る必要はないでしょう。
ドミトリー・デリヤギン、
技術開発局