執筆目的
- この記事は主に、実際のソフトウェア開発プロセスにおけるソフトウェア工学理論の適用を記録するために使用されます。
- 開発プロセスで使用されたより優れたツールを記録します（労働者が仕事をうまくやりたい場合は、まず自分のツールを研ぐ必要があります）。
テキスト
- 優れたソフトウェアエンジニアリングプロジェクトは、少なくとも次の開発プロセス
1、需要計画フェーズ
2、開発フェーズ
3、デバッグフェーズ
4、テストフェーズ
5、本番展開フェーズ
6、運用および保守フェーズに分けられます。
1.需要計画段階
-
[1.1。開発モードを決定する]
- ウォーターフォール開発モデル、アジャイル開発モデル。。。
-
[1.2。要件の分析]
- 使用するフローチャート、スイムレーン図、アクティビティ図、ユースケース図、クラス図UMLクラス図が要件と実装プロセスを分析するのを待ち、描画ツールを推奨StarUML、PowerDesign。
- 使用するバーンダウンチャートとフィッシュボーンチャート工数を評価し、プロジェクトの時間を管理します。各反復では、前の反復のエクスペリエンスの概要を確認します。次に、次のイテレーションを計画し、人々に責任を割り当て、オンラインの描画Webサイトを推奨しますProcessOn。
- プロジェクト仕様を作成します。
- コード提出仕様：実用的なブランチ管理戦略を参照してください。
- コミット仕様：複数のグループを支援する場合は、この問題に注意を払う必要があります。
- コードウェアハウス部門：
- 倉庫はバージョンを管理するのに便利ですが、衝突が発生しやすくなります。
- 複数のウェアハウスは開発に便利です（開発の競合の数は少ない）が、複数のウェアハウスのバージョン管理には問題があり、展開時に間違ったバージョンを取得することは簡単です（たとえば、ミラーウェアハウスが解決するために製品ライブラリーが手動で操作せずに最新のものを直接k8にプッシュする必要があるなど）。制作上の問題を回避してください）。
-
[1.3。プロジェクトの構造]
- プロジェクト開発プロセスで使用されたことを確認する開発言語、ミドルウェアそして選択の理由。
- プロジェクトで発生する可能性のある問題に対処するためのソリューションを提供する繰り返し送信、べき等、キャッシュ整合性、最終整合性、整合性のあるハッシュ、100％メッセージ配信、分散トランザクションそして他の問題。
2.開発段階
-
[2.1。プロジェクト仕様の開発]
- 統合チームコーディングスタイル
- 統一されたプロジェクトドキュメントとストレージの仕様、ストレージの権限
-
【2.2。CI / CD構築プロセス】
- オープンソースが推奨されますGit + Jenkins + Gerrit：Gitはコードを送信し、jenkinsは継続的インテグレーションのデプロイメントを行い、gerritはアクセス制御とCodeReviewを行います。
- CIに推奨SonarQube或者Tsunamiコードスキャンを実行します。
- バグ追跡に推奨ジラ。
- オープンソースプロジェクトは使用する必要がありますFossid使用するソフトウェアのオープンソース認定を実施し、BlackDuckスキャンを使用してオープンソースソフトウェアを評価します。
- 紺碧DevOps
-
[2.3。倉庫を建てる]
- 独自のプロジェクトチームを構築するメイベン倉庫：リソースの公開とプルが簡単です。
- 使用するhttpd自分のプロジェクトチームに属するソフトウェアサービスカタログを作成します。時間内にツールソフトウェアを入手すると便利です。
- 独自のプロジェクトチームを構築する製品ライブラリー：できるコンテナーミラーの倉庫またはフォルダー、後続のバージョン管理、製品版リリースに備えるため。
-
[2.4。開発ツール]
- 開発ツール：IDEA、Eclipse / MyEclipse、VisualStudio、VsCode
- データベース接続ツール：Navicat
- 表示ツール：NotePad ++、Beyond Compare
- sshツール：MultiDesk、Mobaxterm
3.デバッグ段階
-
[3.1。ネットワークの問題]
- ポート占領
- ファイアウォールがオフになっていない、ポートが開いていない（ping、telnet）
- 使用するtcpダンプ+ワイヤーシャークパケットをキャプチャして特定のリクエストを表示する
-
[3.2。オペレーティングシステムの問題]
- いくつか文字セットのエンコード異なるオペレーティングシステム、または同じオペレーティングシステムでも、異なる構成、操作の異常、文字化けエラー
-
[3.3、OOMの問題]
4.テスト段階
-
[4.1、単体テスト]
- テストガイドラインに従ってテストケースを記述し、クラスとメソッドの機能テストを実行します。コードを検討する必要がありますラインカバレッジ（ステートメントカバレッジとも呼ばれます）、決定カバレッジ（分岐カバレッジ）、条件カバレッジ、パスカバレッジ。
- テスト中は、パスカバレッジを直接使用することをお勧めします。
-
[4.2。マイクロベンチマークテスト]
- 提供されているJavaを使用JMHメソッドでパフォーマンステストを実行します。詳細については、マイクロベンチマークテストでのJMHの使用を参照してください。
-
[4.3。インターフェイス/パフォーマンステスト]
- 使用する郵便配達インターフェイスで機能テストを実行します。
- 使用するJmeterまたはLoadRunnerインターフェースで高並行性テストを実行します。
-
[4.4、SITテスト]
- 統合テスト：複数のモジュール開発またはインクリメンタル開発が完了すると、
-
[4.5、模擬テスト]
- 独立したユニットが作成され、統合テストが必要な場合、ダウンストリームリソースを取得するのが難しいか、ダウンストリームが作成されていないため、パス郵便屋さんのモックサーバーまたはYAPIテストのためにダウンストリームリソースをシミュレートします。このテスト方法は、インターフェイスとマイクロサービスを疎結合します。詳細については、「モックテスト方法」を参照してください
- YAPIはPM管理開発インターフェースにも使用できることに注意してください。
-
[4.6、UATテスト]
- プロジェクトが稼働する前に、実際の運用で発生するさまざまな問題を事前に発見するために、社内で多数のユーザーテストが実施されました。
-
[4.7。破壊テスト]
- ソフトウェアのテストには、ユーザーオペレーションマニュアルで禁止されていない方法と手順を使用します。具体的な方法については、Baiduに問い合わせてください。
-
[4.8、サルテスト]
- 破壊テストと同様に、サルのように無意味でランダムです。一般に、疑似ランダムイベントストリームは、開発中のアプリケーションのストレステストを実行するスクリプトを記述することによって生成されます。主にAndroidシステムで使用されます。
-
[4.9、セキュリティテスト]
- セキュリティテストは、ソフトウェアが安全で安定しているかどうか、権限の取得、ユーザー情報の漏えい、プログラムのクラッシュが簡単に発生するかどうかを検出することです。
- セキュリティテストの範囲は非常に広く、重要なポイントは次のとおりです。権限、ユーザー情報、データベースセキュリティ。
- 例：
- アドミッションウェブサイトがアドミッションリストを発表する前に、アドミッションリストはパケットキャプチャによって取得されました。
- ウェブサイトの管理者とユーザーを切り替えた場合、再度ログインする必要はありません。
-
[4.10。回帰テストと煙テスト]
5.運用展開段階
- [5.1。物理アーキテクチャ図]
- 使用するVisio運用する全体の状況が把握しやすいように、本番に投入するプロジェクトの物理構造図を描きます。
- Excelで書く統合要件フォーム統合された需要テーブルの機能は、仮想マシンの申請、IPアドレスの申請、データベースAlwaysOnのセットアップなど、能力を超えた問題を解決するために社内の他の同僚グループを探すことです。
- 統合された需要表を用意するだけでは十分ではありません。タイムスケジュール、各グループ、特に依存関係のあるプロジェクトグループの支援の時間をスケジュールするには、次を使用します。トポロジーあなたにとても役立ちます。
- 【5.2、部署脚本化】
- Linuxでの多くのインストールおよび検索プロセスは、スクリプトを使用して自動化できます。
- よく使用される手順：見つける| grep | sed | 猫| ソース| chmod | sudo | タール| scp | 作る| vim
- [5.3。システムサービス]ダウンしたノードが再起動後もサービスを開始できるようにシステムサービスを作成します。
- システムサービスとしてのウィンドウ：ダウンロードレジストリと組み合わせたInstsrv.exeおよびSrvany.exe実現できる
- システムサービスとしてのLinux：覚えておいてくださいchkconfig --add ｜ systemctl enabl ｜ service命令
- [5.4、高可用性設計]
- キープアライブ生き続ける能力とVIPを提供する能力を実現する
- HAProxy、Nginx、F5、LVS、LBロードバランシングの機能を実現するために、Nginxに関する要点がここに記録されています。非常に興味深いNginxオンライントラブルシューティングを覚えておいてください
- bashスクリプトの実装VIPドリフト
- 高可用性構築ケース
6.運用および保守段階
運用と保守の段階は、主にサービスのSLAを保証することです。優れたWebサイトでは、少なくとも4つの9のSLAを提供しています。
全年拿365天做计算，看看几个9要停机多久时间做能才能达到！
1年 = 365天 = 8760小时
99.9 = 8760 * （100-99.9）% = 8760 * 0.001 = 8.76小时
99.99 = 8760 * 0.0001 = 0.876小时 = 0.876 * 60 = 52.6分钟
99.999 = 8760 * 0.00001 = 0.0876小时 = 0.0876 * 60 = 5.26分钟
- 【6.1。モニタリング】：
- システム監視：
- pingコマンドを使用すると、ノードが停止しているかどうかを簡単に判別できます。
- インストールZabbixメール通知機能を設定することで、サーバーシステムやアプリケーションの監視レベルを実現することができます。
- アプリケーションの監視：
- 使用するHAProxy監視ポートにより、アプリケーションの生存を簡単に監視できます。
- ログ監視：
- 沿ってElasticsearch+Filebeat+Kibana(简称EFK)、特に分散環境でのログの収集、マルチマシンノードのログ収集を実現するには、インストールプロセスを参照してください：EFKログレベル監視システムを手動で構築します
- 分散監視システム：
- プロメテウス
- システム監視：
- [6と2の新バージョンが製品化され、置き換えられました]
- グレースケールリリース
- 青緑リリース
- カナリアリリース