「糞山コード」はどのように作られたのか
Shishan コードは、ソフトウェア業界のほとんどの人から常に批判されてきました。不規則に積み重なった、見たくもないコードの束のことです。これらのコードは実行できますが反復できず、効率的ではありませんが破棄することはできないため、注意を払う必要があるコンテンツを形成します。私はコードのクリーンな開発者であり、この業界に参入した最初の日から、見た悪いコードを最適化したいと思っていました。同時に、私は先人たちの考えを理解しようと最善を尽くし、Shishan コードが形成されたいくつかの重要な理由を要約します。
- プロジェクトの初期段階では、ビジネス アーキテクチャやテクニカル アーキテクチャを含めたアーキテクチャ計画やアーキテクチャ設計はありませんでした (ビジネス アーキテクチャを考慮しないテクニカル アーキテクチャ設計は、最終的にナンセンスになります)。
- プロジェクトの途中で事業規模が形成された後、事業のイテレーションのみが考慮され、技術のスケーラビリティが考慮されないため、最終的な技術が更新されず、事業開発が複雑になる
- 技術チームの構築は体系的ではありません.多くのチームは、初期および中期に優れた技術者を持っていません.チームの技術的な雰囲気は遅れており、コア技術者の設計能力は不足しています.システム機能。
- 製品の技術的認知が不完全で一貫性がない、つまり、多くの製品技術テスターは自分が作りたいシステムとシステム製品を明確に理解していないため、開発プロセス中に立ち上げられたプロジェクトが良いか悪いかの概念がありません。
- チームのコアメンバーには、物事の本来の姿を理解するのに役立つ建築的思考が欠けています. このような思考なしで作業すると、コードの山に直面したときに混乱します.
上記の理由から、実際には、ほとんどの問題はチームとチームのコアメンバーによって引き起こされます。Shishan コードの形成は、一人の人間が原因ではなく、チームの長期にわたる不規則な開発によって形成されます。それを避けたいのであれば、チームビルディングとコア人材のトレーニングが必要です。
コードを最適化するための重要なステップ
たわごと山のコードのほとんどは貴重です。価値のないものについては、更新する必要がないか、直接破棄できます。あきらめてはいけない。さまざまなシステムで、さまざまなコードがさまざまな問題に直面しています。プロジェクトのリファクタリングと最適化における私の長年の経験に基づいて、次の手順を要約します。
1. ビジネス価値の深い理解
多くの人が他人のコードが悪いと文句を言うでしょうが、彼にこのコードをどのように最適化すればよいでしょうか? 理由がわからない人が多いです。コードが読みにくく、理解しにくく、保守しにくく、単に悪いと感じています。その程度であれば、数年後にはあなたのコードも他の人からそのような評価を受けることになると考えられます。これらにつながる主な問題点の 1 つは、ビジネスの価値を深く理解していないことです (さらに、個人の技術的能力も重要です)。
ビジネス価値によって、対応するビジネス モジュールに費やす労力と、記述するコードの行数が決まります。そして、拡張などのために保存する必要があるもの。重要なビジネス価値のない一部のコードについては、関数が完成している限り、過度の最適化を行う必要はありません。
ビジネス価値は、私たちのソフトウェア プロジェクトの究極の目標です。ビジネス価値を理解することによってのみ、最終的な方向性を決定し、どの方向に最適化することができます。テクノロジーに合わせてコードを最適化するだけという目標がなければ、最終的に十分な価値が得られないため、多くの時間を費やす必要はありません。
2. 本来の事業構造と技術構造の分析
ビジネスを深く理解する過程で、元のビジネス アーキテクチャと技術アーキテクチャの分析に焦点を当てることも重要です。このプロセスでは、元のビジネス シナリオ、ビジネス機能、ビジネス機能、およびビジネス要素をグローバルに抽象的に理解する必要があります。また、元のビジネス アーキテクチャの概要を説明するだけでなく、元の技術アーキテクチャも把握します。
テクノロジーの反復により、さまざまなシステムの実装には多くの選択肢があり、同じ機能に対して、さまざまなテクノロジーを使用して、さまざまな困難とビジネスアプリケーション機能を実現します。たとえば、メッセージ イベント、データベース、キャッシュなど、これらには多くの実装があります。実装方法が異なり、直面する問題も異なります。これは、技術的なアーキテクチャ コードの最適化を行う際の考慮事項の範囲内でもあります。
3. 新しいビジネス アーキテクチャと技術アーキテクチャを設計する
既存のビジネス システムとビジネス アーキテクチャの技術アーキテクチャを理解した後、コードを最適化する必要があります。次に、将来のビジネス バリュー システムに基づいて、このビジネス アーキテクチャと技術アーキテクチャを再設計および最適化する必要があります。新しいビジネス アーキテクチャは、元のコードを再計画し、ビジネス モジュールを分割し、ビジネス ロジックを階層化するのに役立ちます。新しいテクニカル アーキテクチャは、コード ロジックをできるだけ省いた新しいテクニカル フレームワーク システムを導入するのに役立ち、システムのサポート機能が強化されます。
第四に、コードは機能ブロックに分割され、分類されます
コード変換計画では、コードを機能ブロックに分類する必要があります。ブロッキングは、主に新しいビジネス アーキテクチャに基づいています。等級付けは、主にビジネス価値に基づいています。さまざまな状況での変更提案の優先度は次のとおりです。
- ビジネスモジュールの高いビジネス価値と高い再利用率
- ビジネス価値が高い、ロジックのスケーラビリティが低い、再利用性が高い、リファクタリングが考慮される場合がある
- ビジネス価値が高い、ロジックのスケーラビリティが低い、再利用性が低い、リファクタリングが考慮される場合がある
- 平均的なビジネス価値、ビジネス モジュールの高い再利用性
- ビジネスモジュールの再利用性が高く、価値がない
一般的には業務モジュールの最適化を優先し、同時に再利用性の高いものを優先的に最適化する必要があります。再利用性が低いため、基本的に価値の低いものを処理する必要はありません。再利用性の高いコードは、適時に最適化してリファクタリングする必要があります。
5. Shishan コードの最適化を促進する
前の 4 つの手順はすべて理論レベルです。実際に最適化したい場合は、コードを変換する過程で必要ないくつかの機能が基本的に必要です。個人的には以下の要素が不可欠だと考えています。
- コードを理解するには、さまざまな設計パラダイムとパターン コード、およびプロジェクト ソース コードを読み取り、分析し、デバッグできる必要があります。
- 以前の履歴コードをブロックに分割できる. 最適化プロセス中にロジックを急いで変更しないでください. ブロッキングはコードを小さなモジュールに分割することです, より多くの人が一緒に最適化できるようにする. 分割プロセスは主に構造を改良することです.標準化されたコーディング スタイル
- 協調的変革、最適化プロセス中にリソースが許す場合、密室で作業することを忘れないでください。他の人と協力し、同時に一緒に最適化し、コードブロックを自分でリードする必要があります。そうすれば、全員が協力して効率を最適化し、改善することができます
Shishanコードを完全に認識
Shishanコードを完全に最適化するには? 理論的には、彼らのコードが完全に完璧であるとは誰も言えません。ほとんどのコードは、技術理論と将来の拡張機能の点で改善と最適化の余地があるため、システムのリファクタリングと最適化を完了し、Shishan コードを完全に理解したと見なせるコードはどのようなものでしょうか? 次の基準が必要と見なされます。
- 事業拡大のポイントが明確であり、事業価値を継続的に向上させることができます。
- 高いスケーラビリティ、長期間にわたる迅速な反復
- 保守性が高く、故障しにくい
- コードの標準化と管理が可能