品質モニター-設計エクスペリエンスの向上

同僚、こんにちは！



今日は、品質保証の方法とツールの作成と実装を促進する理由について話し、問題の履歴を調べ、既知のリスクを強調し、 十分な品質のWebソリューションを確保するための勝利戦略を心に「確立」しようとします。 最後に、Bitrixプラットフォームの第11バージョンの新しいツールである「品質モニター」について説明します。

完璧な世界-滝

はい、はい。 Webプロジェクトの高品質を確保するための手法があります。これにより、バグが発生せず、クライアントがフォーラムやtwitterでエラーメッセージを表示して攻撃することはありません。



これを行うには、次のものが必要です。

1. 5年の経験と成功したプロジェクトの大規模なポートフォリオを備えたPHP言語での開発が認定されたプログラマーを見つけてください。
2. 最新バージョンのすべての一般的なブラウザでHTML / CSSの複雑さを理解し、朝から昼食までプロのフォーラムでぶら下がっているコーダーを見つけます（私は書いて、涙が私の目に見えます:-)）。 しかし、これは十分ではありません、なぜなら タイプセッターはjavascript用にプログラムできなければなりません（そして、すべての一般的なブラウザーでこの言語の方言を知っている必要があります）。 非常勤の経験豊富なプログラマーになるため。
3. 少なくとも1つのオペレーティングシステムに精通しており、10年以上の実務経験があるシステム管理者を見つけます。
4. 単体テストと機能テストで生成されたWebプロジェクトコードを100％網羅したシステムを編成できるテスターを見つけます。 このテスターは、Webプロジェクトのサブジェクト領域の複雑さを理解し、クライアントよりもよく知る必要があります。
5. そして、もちろん、a）この主題分野のアナリストよりも優れていることを複雑に知っているクライアントを見つけるために、b）Webプロジェクトが運用されるまで、要件を変更しません。
6. チームが組み立てられたら、Webサイトの設計、描画、タイプセットを開始し、管理パネルとパブリック部分の両方で各Webページの説明をTORに含めます。ユーザーの画面解像度に応じてピクセルとさまざまなページオプションが正確です。 結果は、約6か月で書かれた、なんらかの500ページのイラスト付きTKです。
7. 次に、作業指示書の各ページを評価し、毎日の詳細な開発計画を作成し、Webプロジェクトを運用する日付を設定する必要があります。
8. もちろん、起動する前に、作成されたWebサイトを徹底的にテストしてTORおよび設計レイアウトに準拠するために、TKのピクセルと文字に対して正確な時間を割り当てます。 長時間テストする必要があります。いくつかのアプローチでは、クライアントに対してエラーのある機能を開くことはできません。多相テストには、2〜3か月かかります。

そして、Webプロジェクトでエラーが発生することはほとんどなく、システムは予定どおりに起動します。 しかし、おそらくサイトは時代遅れになり、ユーザーはそれを必要としなくなり、クライアントは望んでいるものではなく、仕事の明細書に書いたものを受け取ります:-)



残念なことに、多くの人々は、Webプロジェクトが数学を応用した厳格な「ブール」ロジックを持つソフトウェアシステムであり、美意識を持っていないことを忘れています。 このエンジニアリング構造は、他の構造（橋、家、飛行機）と同様に、適切な方法でねじまで設計し、ねじまでテストする必要があります。変更するには、すべての設計文書を確認する必要があります。 そして、徹底的かつ科学的に、彼らは以前にソフトウェアシステムを開発しました- カスケードアプローチ（ウォーターフォール） 。



しかし、直感的には、この方法でウェブサイトを立ち上げることは非常に費用がかかり、明らかに非常に長いことを示唆しています。 また、チーム内で高度な資格を持つ専門家を見つけることは簡単なことではありません。 数学で宿題をやるのではなく、「安くチート」する方法を見つけたいと思います。複数のボリュームの技術仕様がなくても、どのようにしてWebプロジェクトを迅速かつ十分な品質で開始しますか？ :-)

スカウティング-反復アプローチ

人々は、クライアントと一緒に座って会議室から出て、2〜3日でWebソリューションを設計することは不可能であることに気付きました。 また、オフィスでシステムアナリストを1週間ロックしても、問題は解決しません。 毎回システム部品について議論し、作成し、完了した段階の結果を分析し、次の段階を設計する際にそれらを考慮することがより効率的であることを理解するようになりました。 3か月など、さらに先を見ることなく、少しずつ前進します。



多くのクライアントがこの方法で作業する方が便利です。結果を確認して計画を調整します。 開発者とテスターに​​とって、これはもちろん、面倒なことです。

1. すべてのプロジェクトドキュメント、スクリーンショット、図、TKを最新の状態に保つことはできません。 しばらくしてから、変更を加える必要があるでしょう。 したがって、彼らは「トリック」に進みます-彼らは同僚の記憶に依存して、 コンポーネント間の依存関係を追跡することなく、例えばWikiなどのシステムのあまり正式な説明を導きません:-)
2. 予想される変更を簡単でリスクの少ないプロセスにするために、プログラム/レイアウトが必要です。 これは、a） デザインパターンを知って正しく使用する必要があること（およびこの領域を知っている開発者を見つけることは容易ではないこと）、b）誘惑に負けず、あらゆる場所で普遍的で拡張的なシステムを作成できないことを意味します 開発時間が大幅に増加します
3. これをテストし、定期的にシステムを変更できる必要があります。 どこで何が変化し、どこで現れるかを知る。 つまり テスターの負荷が増加します-変更の説明、単体テストおよび統合テストの変更などが必要です。

反復的なアプローチでは、一方ではクライアントにとって、そしておそらくは彼と一緒に働くプロジェクトマネージャーにとってはより便利になり、他方では開発者や品質スペシャリストの負担が増え、資格の要件も増えていることがわかります。







同様のプロセスを、より正式に（ RUPなど）およびあまり正式に編成することは可能です。 それはすべて特定のWebプロジェクトに依存します。 したがって、 特殊なソフトウェアを使用できますが、すべてを「ひざの上に」構築することができます（Excel、Wiki、葉の壁など）。

曲芸飛行...カオスの瀬戸際-アジャイルフレキシブルプロセス

現在、ウェブサイトの開発プロセスが人気を集めています。 以下が想定されています。

1. 要件は常に変化しています 市場は変化しているため、詳細なTKを変更して最新の状態に保つことは時間の無駄です。 それ以外の場合は、システム分析部門、設計部門、およびアーキテクチャ設計部門が必要になります。
2. なぜなら 要件が変更されているため、プロジェクトの変更は常に行われるため、プロジェクトが破壊されず、変更が迅速かつ安価に行われるようにすべてを行う必要があります。
3. クライアントまたはその代理人は常に連絡を取り合うことができ、プロジェクトチームからの質問に答える必要があります。
4. 開発者と他のプロジェクト参加者は常に情報をやり取りし、情報交換し、官僚主義は最小限に抑えられ、人々は高度に組織化され、一緒に働きます（強制的に働く必要はありません）
5. Webプロジェクトは、2〜3週間で繰り返しリリースされます。 サイト訪問者はテストに積極的に参加します。

明らかに、このような「大失敗」には、チーム内の自己組織化された人々、その分野の専門家、専制君主の攻撃からのこの超創造的な雰囲気をサポートするリーダー、官僚の個人的なmerc兵の目標などが必要です。 さもなければ、拍手で-誰もが再びオフィスの机の周りに散らばり、手紙を投げ始め、文学的な批判に苦しむでしょう。



結果指向のクライアント、このプロセスは非常に便利です。 Webソリューションは、競合他社に遅れずに絶えず変更および開発できます。さもないと、クライアントは1年前に書いたようにTKの人質になります。 チームが予測可能なパフォーマンスに強い場合、クライアントはWebソリューションの今後のリリースを効果的に計画し始めます。





一方、ソリューションの技術的な複雑さは非常に急激に増加します。 「技術的健全性」の状態で絶えず変化するシステムをサポートすること（自信を持ってさらに開発でき、変更を行うコストが指数関数的に増加し始めないことを知っている場合）は、気弱な人の仕事ではなく、高度な資格を持つ開発者を必要とします。



そのようなシステムの品質を管理するために（多くの場合、正式な技術文書なしで）、効果的な技術の武器が使用されます。

1. 自動化された単体テスト 。 プログラマは、コードを作成してコードをテストします。
2. 機能テストまたは自動受け入れテスト-完了した機能とプロセスがテストされます。
3. Webプロジェクトのリリースがすぐに開始されます。 訪問者はすぐにソリューションをテストし、短時間でベータから適切な状態に移行します。
4. チェックリストは、生産のすべての段階で使用されます。 結論は簡単です-複数ページのマニュアルを書いて読んだ後、「生き残る」ためには、不要な質問をせずにこれらのポイントに従う必要があります。 戦闘憲章との直接の類似点。

明らかに、以来 このような開発プロセスは、「制御されたカオス」の寸前でバランスを取ります。そうでない場合、市場では作業が許可されないことがよくあります。順序と予測可能性を確保する重要な役割は、チェックリスト（チェックリスト）によって補完される最大のテスト自動化に属します システムはそれ自体を検証し、重大なエラーを迅速に識別できる必要があります。また、レイアウトから負荷下での運用まで、生産のさまざまな段階で（自動化が困難な場合）迅速にチェックする必要があるものと場所を知る必要があります。



このプロセスの健全な進化は、通常、次のシナリオに従って進行します。

1. 2〜3週間で、新しいWebソリューションリリースが設計およびリリースされます。
2. 反復の経験が分析され、生産のさまざまな段階のチェックリストが改善されます
3. 以前の反復で設定されたいくつかの松葉杖-対応
4. ユニットおよび機能テストのグリッドで覆われた新しいシステムモジュール

時間が経つにつれて、Webプロジェクトの開発プロセスは安定し、変更を加えることは「それほど怖くない」ものになります。彼らはそれを待っており、システムは絶えず更新、改善し、外部だけでなく内部も比較的健全です。 「効果的な世界」の段階が来ていますが、これはまだ観察されていません。 偏りがあると、生産が混乱または愚かな形式化に陥り、コストの上昇が始まります。



成功を統合するために、このレベルに到達した人は、継続的な統合のサイクルを実装することがよくあります 。 これを行うには、 特殊なソフトウェアを使用する必要はありません。単純なスクリプトのグループと熱狂的なチームの温かい心に自分を制限することができます。

チェックリストの詳細

Webプロジェクトの開発方法（「Web」だけでなく）の進化を流repeatedに繰り返し、現在、システムの正式な系統的開発に十分な時間を費やしている人はいないことを確認しました（ただし、「ウォーターフォール」と依存関係マトリックスはエラーのコストが非常に高い産業-家、橋、飛行機の建設、米国でのヘルスケアソフトウェアの開発など）、チームは生き残り、非常に効果的なツールの限られたセットを使用して恐怖と戦う チェックリスト。











チェックリストは通常​​、経験豊富な従業員、システムおよびビジネスアナリスト、および機能マネージャーによって作成されます。 知識ベースに会社の知的荷物が蓄積されると、チェックリストが作成されて改善されます。 要点は簡単です-従業員がレーキを2回以上無意識に（場合によっては任意に）踏まないようにして時間とお金を節約します。







プログラマー向けの基本チェックリストの例：

1. 実装する必要があるものを理解します。 質問が残る場合は、アナリスト/マネージャー/クライアントを苦々しく振ってください。
2. これを実装する方法を考えてください。 時間をかけてコーディングしてください。 論理データモデル、3つのUMLダイアグラムを作成します-システムのロジックと動作の両方を反映します。
3. リード開発者に相談してください。
4. データベーステーブルを設計します。 同僚/部門長と話し合う。
5. システムをテストする方法を考えてください。
6. 設計パターンを覚えておいてください。それらのいくつかは役に立つかもしれません。
7. ユニットテストの記述を覚えている間に、遅かれ早かれ機能をエンコードします。
8. メインリポジトリにコードを追加する前に、単体テストを実行する必要があります。
9. wikiでロジックを説明します。

各項目は、Wikiの手法へのリンクにすることができます。



複雑なことはありませんが、これらのポイントの多くが無視される頻度です。



そして、ストレステストやサーバーメンテナンスのためにWebプロジェクトを準備するチェックリストに関しては、プロジェクトごとに繰り返される非常に多くの重要な小さなことがあります。 多くの場合、人々は覚えていると言います。実際、経験は、覚えていない、重要なポイントを見逃し、プロジェクトからプロジェクトへと「熊手を踏む」ことに従事していることを示しています。 経験豊富なプロジェクトマネージャーが、レイアウトデザイナーからシステム管理者まで、責任ある従業員によって作成されたチェックリストレポートがある場合にのみ、ステージ/リリースを閉じます。

品質モニター-Bitrixプラットフォームの第11バージョン

ボックスプラットフォーム1C-Bitrix：Site ManagementでWebプロジェクトを開発する場合、上記のプロセスのいずれかを使用できます。 次のリスクが軽減されます。

1. 開発者は「最高度の献身」をする必要はありません。ZCE証明書を取得し 、OOPと設計パターンを詳細に理解します。 最も困難なのはプラットフォームのコア部分にあり、Bitrix社内で開発およびテストされています。 PHPプログラマーとレイアウトデザイナーは、基本的なスキルと最小限の経験を持ち、 トレーニングコースを受講するだけで十分です（数日で完了できます）。
2. システムのドキュメントを更新する必要はありません。なぜなら プラットフォームは、顧客と開発者の両方のための公式ドキュメントで非常に詳細に説明されています。 Webプロジェクトの統合中に行われた改善/機能変更のみを記述する必要があります。
3. テスターは、Webソリューション全体をテストする必要はありません。 プラットフォームは内部で徹底的にテストされています。 機能の改善/変更をテストするだけです。 これにより、時間とリスクが大幅に削減されます。

それでも、統合に必要な既知の要件に従わない場合、理想に近い条件で作業していても、Webプロジェクトをカオスに変えることができます。これは、維持と開発が非常に難しく、費用がかかります。 さらに、コードとアーキテクチャの秩序の欠如は専門家を強く動機づけ、スタッフの離職が始まります。これは、Webソリューションの開発により状況をさらに悪化させます。



上記のリスクから開発チームを保護するために、バージョン11からプラットフォームに品質モニターが組み込まれました。



Webプロジェクトのリリースを送信するには、レイアウトからホスティングまたはクラウドでの展開および負荷テストまで、生産のすべての段階で自動および手動の制御手順を実行する必要があります。







各テストにはいくつかの状態があり、一部のテスト、特に定期的なテストは自動化されています。











実際、プロジェクトマネージャーまたは開発者は、すべてのテストと自動テストを実行して、リリース/反復を完了するためにテストツリーを「グリーン化」する必要があります。







リリースがリリースされると、デスクトップとテストレポートのリストで確認できます。







特に「高度な」開発者向けのチェックリストを選びたいと思います。 これらの項目は、コードの品質とアーキテクチャに真剣に注意を払うAglle / XPチームで特に需要があります。







開発チームは、必須およびオプションのチェックリストと自動テスト項目を追加できます。たとえば、CodeStyle検証のカスタマイズ、バージョン管理システムとの正しい統合、 UnitTestsコードの存在とカバレッジ、 PHPDocumentorのスタイルのドキュメントなどです 。







カーネルお​​よびプラットフォームライブラリを変更するという事実も自動的にチェックされます。

未来へのアイデア

創造的なプロセスとしての開発は楽しいはずです。 そうすれば、Webプロジェクトは死んで怖くはなくなり、それらをサポートする方が簡単で面白くなります:-)



Bitrixプラットフォームでの開発プロセス全体をカバーするチェックリスト。社内チームのチェックリストで拡張できます。 これにより、プラットフォームの知識と理解の欠如、および一般に「グッドプラクティス」に関連するリスクが大幅に削減され、 振り返ってみると、チームが「品質モニター」に新しいアイテムを追加してプロセスを改善できます。



分散バージョン管理システム（ Mercurial 、 git ）との透過的かつ効率的な統合、 phingなどのビルドツールのサポート、マルチステージ開発環境（dev、テスト、ステージ、プロダクション）のサポート、 継続的インテグレーションシステムのサポート、地理的な効率的な作業のサポートなど、多くの興味深いタスク分散チーム-活発に議論されています。



「品質モニター」によって、チームが内なる可能性を解き放ち、創造的な開発プロセスに焦点を当て、アーキテクチャを改善し、振り返って得られる一種の知識ベースになることを心から願っています。



十分なサイト品質を確保するための勝利戦略を念頭に置いた「落ち着き」について...複雑で大規模なWebソリューションの開発（またはそのようなシステムのリファクタリング/リライト）の詳細な設計と形式化に時間をかけるには時間がかかると確信しており、品質は保証されませんカオスは生産から始まります。 「オープンでモダンな」クライアントを持つ中規模のプロジェクトには、反復方法論が適しています。 小規模なプロジェクトの場合、柔軟な方法論がその価値を証明しています。 実験して前進することを恐れないでください。 頑張って