複雑なシステムの開発に関するルール。 1つのプロジェクトの歴史

こんにちは、Habr。 私の名前はアレクサンダーです。 そして、1つの大規模で複雑なプロジェクトに取り組んだ私の話を共有したいと思います。



この記事では、コードとスキームはありません。プロジェクトの「from and to」を作成した履歴のみがあります。 多くの人がこの記事に興味を持っていると思います。 さあ、行こう！

開始する

それはすべて2011年の夏に始まりました。当時、私は3歳の純血種のフリーランサーでした。 つまり、私の仕事はフリーランスです。 欧米の顧客のみと仕事をし、現在も働いています。 主な専門分野は、画像、テキストなどの認識に関連するプロジェクトの開発です。



それはすべて、いつものように、午前中にメールをチェックし、スパムを除去し、日常業務を行ったという事実から始まりました。 通常、スパムの内容は調べませんが、実際のアドレスからの手紙を見ました。 私は、ある企業が西部の大規模プロジェクトを完了するためのプログラマーを探しているという手紙を開きました。 さらに、この会社には私の市のプログラマーが必要であり、常に認識の分野での経験があります。 好奇心のために、私はこの手紙に答えました。 文字通り1時間後に私は答えを受け取りました。 そして2年後、私たちはすでにプロジェクトマネージャーに電話をかけました。 最初は、通常の機能セットであるファイナライズするのに複雑なものは何もないように思えました。 マネージャーとの短い会話の後、価格表、つまり1時間あたりの料金を発表しました。 そしてこれについて私たちはさよならを言いました。 翌日、彼らは私の値札に同意し、テストタスクを与えたと私に言った。 私は1時間以内にそれを無事に完了し、次に進みました。 そして、ここから楽しみが始まります。 まず、私は秘密保持契約に署名するためにオフィスに招待されました。 第二に、これは論理的であり、プロジェクトのソースは、契約に署名した後にのみ私に与えると約束した。 正直なところ、それは私を混乱させました、私は理由さえ知りません。 そして、私の直感は私を失望させませんでした。 作業の複雑さを評価するためにソースコードの少なくとも一部を要求し、プロジェクトについて詳しく説明するように依頼しました。 結局のところ、プロジェクトはすでに3年間進行中で、私は4（！）パフォーマーでした。 アメリカの会社が私の前に働き、次にインディアン、そして私を雇った会社が少女プログラマーの助けを借りてプロジェクトを実行しようとし、彼らは私にこの奇跡を掻き立てることを申し出ました。 これは私を驚かせただけではありませんでしたが、非常に不安でした。 その後、私は多くの驚くべきことを学びました。たとえば、顧客はプログラムを2年間見なかったが、スクリーンショットだけを見たことがあり、インド人はこの顧客の約束を与えられました。 これがどのように実装されるか想像できませんでした。 ヒンズー教のマネージャーには、「機知にこだわる」ためのメダルが与えられるべきです。



すばらしい話を聞いた後、私たちはマネージャーに彼がソースコードをくれて、悲劇の規模に感謝することに同意しました。 より明確にするために、プロジェクトについて詳しく説明します。 このプロジェクトは、エンジニア、建築家、電気技師、および住宅、高層ビル、一言で言えば建物の建設に携わる人々のためのツールです。 建築計画のさまざまな要素を数え、面積を計算し、長さを測定し、推定を行うのに役立ちます。 大まかに言って、建設計画があり、その上にソケットがあります。 これらのアウトレットの数を認識して数える必要があります。 認識のために、別のプログラマーによって書かれたライブラリが使用されました。 プロジェクト自体はC＃で記述されています。 私の仕事は、すべてをまとめて追加の機能を変更し、プログラムを安定性の低い状態にすることでした。 すべてがシンプルで初歩的なようです。 私もそう思いました。 しかし、そこにありました。



ソースを入手した後、プロジェクトをコンパイルしようとしました。 私は成功しませんでした。 簡単な分析の後、エラーを修正し、プロジェクトを開始しました。 しかし、残念ながら、期待どおりに機能しませんでした。 数時間のコード分析の後、問題全体が認識ライブラリにあるという結論に達しました。 当時、私は64ビットの「7」、およびマネージャーは32ビットでした。 すべては彼のために働いた、私はしない。 64ビットプラットフォーム用にコンパイルするライブラリを要求しました。 しかし、口に泡があるライブラリの開発者は、それはビットの問題ではないと主張しました。 彼は彼のライブラリーについてほとんど情報を提供せず、一般にそれを一見のように大事にしていたので、彼に何も証明できませんでした。 時間が経ち、検索プロセスを少なくとも完全に実施する必要がありました。 私はすべてのことを考えて、32ビットバージョンのOSを自分で設定しました。 そして見よ！ すべてがうまくいきました。 気を散らす、私は図書館について言いたい、将来的には、それにもかかわらず、そのケースはその能力であることが判明した。



私はコードを分析し始めました。 第一印象はただ嫌だった。 私はショックを受けました。 プロジェクトで私が激怒したもののリストを提供します。

1.コンポーネントとコントロール。

このプロジェクトはグラフィックスと非常に関連していますが、出力と処理には通常のPictureBoxが使用されました。 最小の計画サイズは5400x3600ピクセルです。 知識のある人は、PictureBoxの場合、これが大きな画像の出力とその処理に関するかなり問題のあるトピックであることを理解するでしょう。 計画自体に加えて、はるかに多くの情報が表示されることを忘れないでください（エリア、テキスト、見つかった文字など）。 5つの小さな計画でプロジェクトを開始すると、プログラムは確かに「メモリ不足」エラーでクラッシュします。 これは非常に大きな問題でした。主なアイデアは、ツールは「実行して忘れる」という原則に基づいて機能する必要があるということでした。

2.プログラムのソースコードアーキテクチャのロジック。

むしろ、その不在。 このアーキテクチャを理解するために6か月を費やしましたが、それでも成功しませんでした。 クラスは理解できないだけでなく、単にランダムに接続されます。 1つのクラスでは、論理的に無関係なさまざまな操作を担当するメソッドを作成できます。 特に「RubberBand」と呼ばれるクラスを「快楽にした」、正しく理解できれば、英語から「ゴムバンド」と訳されますが、それはある種の用語かもしれません。 知りません したがって、このクラスは非常に包括的なものでした。 その中には、データベース、グラフィック、インターフェース、および計算部分を操作するためのメソッドがあります。 当初から、ドラフトとして使用されるクラスだと思っていました。 つまり、使用されず、一部の開発のみが保存されます。 なぜなら、一見するとロジックはなく、個々のコードだけだからです。 しかし、私は間違っていました-これが主な統治クラスです。

3.変数、メソッド、およびコメント。

ここでもすべてがあいまいです。 いくつかの企業がプロジェクトに関与しているという事実により、コードは異なるスタイルとスペルでした。 変数の命名は「ブルドーザーから」という印象を受けました。 多くの場合、変数はint rjik、double opgddなどのように名前が付けられています。 しかし、これは最も基本的なものではありません。 数日間のリファクタリングの後、変数の問題は解決されました。



以下はメソッドです。 ここではもう少し簡単です。 いいえ、簡単ではありません。 難点は、多くのメソッドが無意味であるか、セマンティックの負荷をまったく受けないとも呼ばれることです。 気を散らすのは、コードを解析したときに、命名が私が見ている原則に基づいているという印象を受けたので書きます。 たとえば、インドの「テーブル」にある名前付き変数というテーブルがあります。



「bindingDB（bool Draw）」と呼ばれる1つのメソッドは特に印象的でした。 800（！）行以上のコードが含まれていました。 それが何らかの形でデータベースに接続されていると考えた場合、あなたも私も間違っています。 私は彼がなぜそうだったかを理解し、それを破るために数日を費やしました。 この方法はユニークでした。 他のほとんどすべてのクラスから呼び出されました。 彼は、統計の計算、グラフィックスの描画、GUIとの対話などを担当していました。 そして、前述のRubberBandクラスから多くのコード行がコピーされました。



コメントに移りましょう。 コメントはほとんどありませんでした。 それらのほとんどは取るに足らないものでした。 以前の開発者はこのタイプのコメントを残しました：「ここで変数i 0を割り当てます」。 そして、いくつかの混乱する場所では、単にコメントがありませんでした。



また、codeprojectから盗まれて盗まれたコードがいくつかあったことにも注意してください。

4.データベース

建築について何も悪いことは言えません。 それはアメリカ人によって設計されたからです。 ただし、ストアドプロシージャについては、クエリを記述しない方法に関する本全体を書くことができます。

5.クライアントサーバー

プログラムの所有者の考えによると、このアーキテクチャは組織のローカルネットワークでの継続的な運用を保証することになっていることにすぐに気付きました。 サーバー部分をサーバーにインストールし、最も困難な操作、つまり認識手順をすべて処理する必要がありました。 また、クライアント部分は、サーバー上で発生するはずだったプロジェクトを単純に作成し、分析のために実行するワーカーのマシン上に立つ必要がありました。 分析後、すべてのデータをデータベースに書き込む必要があります。その後、すべてのクライアント部分をデータベースと同期する必要があります。



実際には、すべてが異なって見えました。 クライアントでプロジェクトが形成された後、サーバー上のキューに送信されました。 キューに入った後、サーバーでの分析がパスするまでクライアントはブロックされました。 5台のクライアントマシンを持つ組織があるとします。 各マシンで1つのプロジェクトが形成されます（平均的なプロジェクトは10ページと10枚の目的のイメージです）。 このような平均的なプロジェクトでは、約1時間の誤った計算が行われます。 つまり、5つのプロジェクトが形成された場合、最後のプロジェクトは4時間後にのみ開始されます。 そして、これらすべての4時間はクライアントが凍結されます。 私の意見では、ヒンドゥー教徒はマルチスレッドとは何かを知りません。

問題解決

すべての問題を解決するために、2か月を与えられました。 実際、これにより7か月間の作業のやり直しだけでなく、新しい機能の改善も行われました。 その結果、私の魔術の後でも、使用できない製品を受け取りました。 いいえ、ここでのポイントは、私がそれを修正することができなかったということではありませんが、実際には、プロジェクトは最初は曲がって設計されていたため、非常に嘆かわしい結果をもたらしました。 ちらつき、完全なメモリ、遅い操作など。 削除することは単に不可能でした。 そして、顧客と私はプロジェクトをゼロから書き直さなければならないと決めました。

新しいプロジェクト

1か月間、デモ版を提供する必要がありました。 すべての機能の30％をカバーします。 2月に、プロジェクトの設計と開発を開始しました。

次に、設計時に自分が注意したことのリストを示します。

1.スケーラビリティと柔軟性

これは、多かれ少なかれ大規模なプロジェクトの前提条件です。 将来の開発でコードの大部分を書き換える必要がないように、それを尊重する必要があります。 どんなチップや小さなものでも、できるだけ早く参加する必要があります。 また、コードは明確で柔軟でなければなりません。

2.テクノロジー

開発の成功と品質は多くの場合、使用する技術に依存するため、デザイナーにとって重要なポイントです。 プログラミング言語として、C＃と.NET 4.0フレームワークを選択しました。 これはもともとプロジェクト自体に規定されていたため、何も変更しませんでした。



私はMSSQL 2008 r2を選択しました。私はMSを使うことに慣れているので、彼らを信頼しています。



グラフィックについては、XNA 4.0を選択しました。 優れた強力なものですが、欠点もありますが、利点よりも重要ではありません。

3.データベースのアーキテクチャとクラス

ここで、私は設計の際に非常に注意深い注意を払っていました。 コードをわかりやすく、わかりやすく、「インドのコード」を避けたいため、最初にA4シートのすべてのクラスについて説明しました。各シートには、「ImageProcessing」、「Rendering」、「Reporting」などの名前が付けられました。 さらに、これらのシートは論理的に接続されていました。たとえば、グラフィッククラスを持つシートは、データベースを操作するためのクラスとは別に接続されていました。 これらすべての操作の後、クラスアーキテクチャを取得しました。 DBアーキテクチャも行いました。 多くの人はこれが間違っていると言うかもしれませんが、私にとっては設計がとても便利で快適です。

4.変数、メソッド、コメント

メソッドと変数に名前を付けるとき、将来的にメソッドまたは変数の値を理解するのに混乱や時間の無駄がないように、それらに名前を付けようとしました。 コードには「a」、「b」、「c」などの変数はありません。そのような指定には意味がないからです。 例外はi、j変数です-私はループでそれらを使用することに慣れています。 また、変数x、y、zは座標です。



このメソッドが何であるかを理解するために、各メソッドの前にコメントを残します。 メソッド自体には、さらにコメントを残そうとします。 これにより、将来のコードの理解が大幅に簡素化されます。



多くの人が例外処理構造を使用しないことで罪を犯すことを知っています。 ただし、必ず使用する必要があります。

5.メモリ

負荷の高いシステムでは、メモリのクリーニングは製品の通常の動作に必要な条件です。 したがって、メモリを消去する必要があります。

6.コピーアンドペースト

以前は積極的に使用していました。 メソッドまたはクラスを作成しました。 次に、必要に応じて、コードを取得してコピーしました。 しかし、このプロジェクトから、私は基本的にこの方法を放棄しました。 デバッグやバグを1時間費やすよりも、コードを書くのに15分かかると思います。 コードをコピーしても、エラーが発生する可能性があるために、無意識のうちにコードの一部を変更しないことがよくあります。

7.大きいものから小さいものへ

最初に、いくつかの基本的なことを書いてみてから、チップをそれらにねじ込みます。 一度にすべてを書き始めると、「スプレー」が表示されるためです。 つまり、あなたは注意と時間を吹きかけます。 そして、多くの場合、問題の主要な点と追加の問題でも判明しています。 それは、「自分自身にも人にも」ではありません。

結果

私の仕事の結果は、すでに米国で発表されている製品でした。 そして、数日で販売が開始されます。 4か月で、以前の3社では3年間で開発できなかった製品を開発できました。 私は超クールなプログラマーだと言っているのではありません。 製品の品質、開発速度、エラーの修正は、上記で説明したポイントに依存すると言います。 そして今、あなたが2つの製品を比較する場合-新しいものと古いもの、そしてこれは天と地です。 そして、将来のプロジェクトでは、「デバッグと修正に多くの時間を費やさないように、計画と設計により多くの時間を費やすことをお勧めします」という単純なルールを遵守します。