これらの3つのポイント
序文
「テクニカルマネージャー」は、システムを一緒に作成した開発チーム全体を担当する開発チームのプログラマーが担う役割です。通常、彼は最終的に提供されるソフトウェアシステムを担当するだけでなく、プログラマーのようにシステムを開発および実装します。
テクニカルマネージャーの時間の60％から70％は、開発タスクの分解と割り当て、開発プラクティス、テクニカルアーキテクチャのレビュー、コードのレビュー、およびリスクの特定に
費やされ、残りの30％から40％はシステムのセキュリティ保護に費やされます。必要なすべての計画、コラボレーション、コミュニケーション、および管理を時間どおりに提供します。チームマネージャーとは異なり、テクニカルマネージャーの管理作業のほとんどは、特定のR＆Dタスクおよび技術業務を対象としています。次に、テクノロジーTLでの私の役割、開発仕様、開発プロセス、技術管理および計画などでの私の精神的発達の一部に基づいて、皆さんに励ましたいと思います。
開発仕様
当時私が担当していたのは、グループによる子会社の買収でしたが、全体的な技術基準という点では、グループの技術基準とは大きく異なりました。このチームに来て最初にやったのは開発仕様と言えますが、当時直面していた問題は、APIインターフェースのフォーマットがわかりづらく、標準のRPCサービスがなく、コードに標準の開発仕様が統一されておらず、テクニカルフレームワークのコンポーネントが標準化されていなかったことです。一連の質問ビジネスの新参者として、私はすぐに比較的標準的で包括的な技術開発仕様のセットを作成しました。開発仕様を整理しながらコードを記述し、チーム
を統一された標準化された開発パスに導きました。
チームのR＆D仕様によって明らかにされた上記の問題に対応して、次の仕様が策定されました。
命名規則
私自身、プロジェクト構造構築の初期段階を重視しており、命名規則、モジュール分割、ディレクトリ（パッケージ）命名を適用することは非常に重要だと思います。うまくいけば、プロジェクトをインポートしてから他の人が理解するのに10分しかかからないかもしれません。システム構造。
具体的な仕様は次のとおり包命名、类的命名、接口命名、方法命名、变量命名、常量命名です。
統合IDEコードテンプレート
IDEA / Eclipse IDEコードの統一されたテンプレートが合意され、異なるテンプレートを使用する異なる開発者によって引き起こされる差別化とコードマージのコストを回避するために、コードスタイルを統一する必要があります。IDEAを使用している学生は、Eclipse CodeFormatterプラグインとEclipse統合コードテンプレートをインストールできます。
Maven使用仕様
すべてのセカンドパーティライブラリとサードパーティライブラリのバージョンは親pomで一律に定義されているため、すべてのビジネスアプリケーションプロジェクトは、親pomで指定されたセカンドパーティライブラリとサードパーティライブラリのバージョン、および統合されたフレームワークとツールのバージョン（Spring、Apache commons）を継承します。ツール、ログコンポーネント、JSON処理、データベース接続プールなど）。ただし、実稼働環境ではSNAPSHOTバージョンを無効にする必要があります。このように、一般的なフレームワークとツールのバージョンをアップグレードするには、アプリケーションプロジェクトの親pomをアップグレードするだけで済みます。
コードコミット仕様
Angular Commit Message仕様に基づいて統合されたChangeLogが生成されるため、各リリースタグは非常に明確です。対応するプラグインをMacにインストールする必要があります。IDEAにも対応するプラグインがあります。詳細については、「教師RuanYifengのコミットメッセージと変更ログ」を参照してください。ガイドの作成。
この瞬間、プルリクエストでショーの操作に直面したとき、私は突然ライナスの試合を思い出しました：
それを取り除きます。そして、私はそのたわごとを二度と見たくありません。-ライナス
コードコミットの仕様はチームにとって非常に重要です。明確なコミット情報によって生成されたリリースタグは、実稼働環境の障害ロールバック業界にとって重要であり、いくつかの貴重な情報を提供できます。
統一されたAPI仕様
統合Rpcサービスインターフェイスの戻り値ResultDTO、特定のコードは次のとおりです。
Successは、応答結果を処理するインターフェイスの成功または失敗を表し、errorCodeおよびerrorMsgは、戻りエラーコードおよびエラーメッセージを表し、moduleは、戻り結果セットを表し、ResultDTOは、common-apiトップレベルのセカンドパーティライブラリに定義されているため、各アプリケーションは、戻り結果を前後に変換する必要はありません。
Http Restインターフェイス仕様の合意は、ResultDTOとほぼ同じです。暗号化と復号化の仕様、署名の仕様、およびバージョン管理の仕様に特に注意を払う必要があります。
例外処理仕様
例外処理は、狭義の例外の処理方法だけでなく、さまざまなビジネスロジックエラーの処理方法でもあります。サービスサービスレイヤーによってキャッチされる例外には、主にBusinessEx-ception（ビジネス例外）、common-apiに対するRetriableException（再試行可能例外）が含まれ、ビジネス例外を処理して例外を統一的に再試行するパブリック例外インターセプターを定義します。例外呼び出しのサービスインターフェイスは、その同一性を保証する必要があります。
さらに、インターセプターで処理する必要のない他のビジネスレイヤーには、いくつかの特別な例外があります。内部処理は自己消化できます。シーンの対応する処理原則に従って、主な原則は次のとおりです。
●直接リターン
●スロー例外
●再試行処理
●ヒューズ処理
●ダウングレード処理
これもまた、弾力性のある設計のトピックを含みます。私たちのシステムは、さまざまな外部サービスやAPIとドッキングすることがよくあります。ほとんどのサービスには、SLAがありません。大きな同時実行下でも、外部サービスが利用できないことによる影響を考慮する必要があります。 、あなたは自分を引きずって死にますか。私たちは常に次のことを望ん
でいます。
●可能な限り低いコストでビジネスを完了するようにします。●外部サービスが基本的に利用できず、外部サービスを同期的に呼び出す場合は、自分自身を保護して直接融合する必要があります。そうしないと、同時実行が継続されます。このような状況では、崩壊します。
●外部サービスが特に重要な場合は、同じタイプの複数のサービスを導入し、価格とサービス標準に基づいてルーティングし、問題が発生すると自動的にダウングレードすることを検討することがよくあります。
Netflixのオープンソースhystrix災害復旧フレームワークを使用することをお勧めします。これは、主にビジネスシステムのダウンや、外部依存関係が失敗した場合の雪崩の問題を解決します。現在、私のチームも使用しており、異常ヒューズ、タイムアウトヒューズ、電流制限ヒューズのダウングレード処理を同時数で解決できます。
ブランチ開発仕様
当初、ソースコードのバージョン管理はsvnに基づいていましたが、徐々にgitに切り替わりました。各企業によるブランチの管理方法（Gitflowに基づく）は少し異なります。
ブランチ開発仕様については、次の標準を指定します。
●ブランチ定義（マスター、開発、リリース、ホットホット、機能）
●ブランチ命名仕様
●チェックアウト、マージ要求プロセス
●テスト
プロセス
●オンラインプロセス●ホットフィックスプロセス
これはコードの品質やアーキテクチャとは関係ありませんが、この一連の標準に従って実装すると、R＆Dチーム全体に非常に便利
です。
●コード管理によって引き起こされるオンライン事故を削減または排除します。●開発とテストの効率を向上させます。多すぎて混沌としている;
●コード管理によって引き起こされるオンライン事故を減らすか、さらにはなくす;
●リリースとロールバックを処理するための便利な操作とメンテナンス;
●プロジェクト開発が変化するニーズに柔軟に適応できるようにし、複数の人が共同開発する。
統一ログ仕様
ログは製品に欠かせない機能であり、その独自の利点は、追跡可能性と、特に生産システムでの問題の位置付けに関して、問題のあるサイト情報をキャプチャできることです。これは、かけがえのない役割を果たします。
ここでは、次の点を強調します针对异常的日志规范。
●WARNとERRORの選択は慎重に検討する必要があります。WARNは一般に、自己回復するが注意に値するエラーを記録する傾向があります。ERRORは、それ自体では回復できないエラーを表します。ビジネス処理の問題にERRORを使用することは不合理であり、catch例外にすべてのERRORを使用するわけではありません。
●記録する情報は、スレッドスタックを印刷するだけでなく、特定のコンテキスト（リンクTraceId、ユーザーID、注文ID、外部からのキーデータ）を印刷することをお勧めします。
●上部と下部の質問が記録されますが、ログの感度低下を考慮する必要がありますか？ログバックを実装するClassicConverterなどのフレームワークレベルで実装できます。
ログを正しく合理的に使用することで、開発者はエラーをすばやく見つけて問題を見つけることができます。したがって、ログの使用に関する一連の標準仕様が合意されました。これで、「アリババ経済開発プロトコル-ログプロトコル」を参照できます。
統一されたMYSQL開発仕様
テーブルのデザインはApiの定義に似ており、最初は正しく開かず、後で変更するのに10倍の費用がかかる種類に属します。最初はビジネスが明確でない場合、優れたワンステップテーブル構造をデザインするのは難しいことを知っています。しかし、少なくとも私たちにできることは、良い基準を持つことです。
統合されたツールとフレームワーク
開発プロセスで使用される共通コンポーネントは、daoレイヤーフレームワークmybatis、キャッシュコンポーネントjetcache、httpclientコンポーネント、common-tools（共通ツール）など、統合されて抽象化およびカプセル化され、グローバル一意ID、分散ロック、電力を抽出します。パブリックコンポーネントを待ち、上記のパブリックコンポーネントを各アプリケーションに統合し、統合されたアップグレードとメンテナンスを実行することで、誰もがビジネス開発に集中できるようになります。