要約： この記事では、ソフトウェア開発プロセスにおける役割、リファクタリング、および品質の問題について説明します。
「毎日、より多くのテクノロジーが発生し、すべての企業がインターネット上にあり、すべての企業がテクノロジー企業になります。」OKTACOOと共同創設者のFredericKerrestは、誰がソフトウェアを使用しているかを知る必要があるため、より良い方法。ソフトウェアは必需品になるだけでなく、競争上の優位性にもなりました。多くの企業がソフトウェアをめぐって競争しているため、ソフトウェア開発に関連する問題がより重要になっています。ソフトウェアを開発する人々-ソフトウェアエンジニアはますます重要になっています。
「知識のためには、喉が渇いているかどうかを知る必要があります。自分自身にとっては、想像上のものでなければなりません。」優れたソフトウェアエンジニアは、ソフトウェア開発の先駆者でなければなりません。自習はその成長の重要な手段であり、自習の過程で、私たちは試験を通して心を収束させ、勉強を促し、基本的な資質を向上させることができます。原則とパターンがソフトウェアエンジニアリングの品質の基礎であることは事実です。しかし、テクノロジーはツールであり、人々に役立つものであり、その逆ではありません。特定の技術に対応するためだけに、特に不快感を覚えることはできません。同時に、ソフトウェアエンジニアリングの核となる要素は人的要素であるため、自分の能力を最大化するためには、良い気分が必要です。
確かに、ソフトウェア開発の過程では、社内のスキルを磨くだけでなく、「製品と話す」必要があります。では、このプロセスで、どうすれば開発の品質を確保できるでしょうか。開発プロセスで得意なことにどのように焦点を合わせますか？この記事では、ソフトウェア開発プロセスにおける役割、リファクタリング、および品質の問題について説明します。
役割
：私たちはしばしば、文言及のみ分業に革命仕事異なり、かつハイとローの区別はありません。ここでの分業は、実際には役割の分担です。役割分担は、個人の作業負荷を最小限に抑えることです。これにより、私たちは赤テープから解放され、得意なことに集中できます。では、そのような概念をソフトウェアエンジニアリングにどのように実装する必要がありますか？
ソフトウェアは汚い子供の中で働くので、難しい子供は一般的に古い技術を指し、仕事のいくつかは維持しなければなりませんでした。汚い仕事や疲れた仕事とも呼ばれるいくつかの反復的なタスクもあります。
この種の作業では、平均的なエンジニアはそれを取り除きたいと考えています。主な理由は、この種の作業を行うスキルには改善の余地がほとんどなく、廃止されたテクノロジーと相まって、これらのスキルは習得した後は使用されず、比較的退屈であるためです。
この種の作業のエンジニアは通常、割り当てられます。関連するエンジニアに必要な技術トレーニングを実施するか、関連する技術を理解しているエンジニアを直接採用して作業に参加する必要があります。
効率と価値は主に、顧客が既存のソフトウェアシステムの問題を解決するのを支援したり、新しい機能を追加したりすることに反映されます。価格が比較的高いため、顧客が新しいシステムを購入することはめったにないかもしれません。そのため、修理作業に費やす費用を減らして、緊急のニーズを解決できます。
運用保守作業の価値は、開発されたコンポーネントとシステムを統合作業に統合することです。これは、ユーザー指向のソフトウェアシステム製品を発売する上で重要なステップです。私はそれが残っているとは思わない仕事。
運用および保守に関連する作業が単純で明確であればあるほど、優れています。関連ドキュメントのこの部分は、通常、readmeマークダウンの形式でソフトウェアシステムのリポジトリに保存されます。これらのドキュメントを表示することで、システム全体を自分で展開できるはずです。
システムの展開は、一般に、開発モード、qaモード、ステージングモード、および実稼働モードのいくつかのカテゴリに分類されます。
業界は、ソフトウェア開発プロセスにおける役割についてさまざまな理解と見解を持っています。著者の意見は次のとおりです。
1。プロジェクトプロダクトマネージャーは、ビジネスニーズの処理、顧客および開発チームへの対応を担当します。
2.プロジェクト開発チームのリーダーはフルスタックである必要があり、全体として計画を立て、プロジェクトマネージャーと要件分析について話し合い、開発設計、タスクの割り当て、および開発の実現について開発チームのメンバーと話し合う必要があります。
3.フロントエンドエンジニアは、Webページプログラムの開発、携帯電話アプリケーションの開発、デスクトップアプリケーションの開発などを担当します。
4.バックエンドエンジニアは、APIの設計と開発、データの分析と処理、およびメッセージのプッシュを担当します。
5.運用および保守エンジニアは、展開環境の確立と管理に責任があります。
6.特定のビジネスニーズに対応するだけでなく、大規模データエンジニア、アルゴリズムエンジニア、AIエンジニア、機械学習エンジニアリング、深層学習エンジニア、 ミドルウェアエンジニアなどの役割カテゴリの内訳も増えます。
7.テストエンジニアは、システム統合後のビジネス要件のケーステストを担当します。この部分の入力は、ユーザーのニーズである開発チームの入力と同じです。出力は、デマンドケースに対応するテストレポートです。開発チームの成果は、ソフトウェアシステム全体です。
リファクター
コードとデザインをリファクタリングする必要があるのはなぜですか？主な理由は、効率の向上、メンテナンスの容易さなど、より良い方法を見つけたからです。
私たちは皆、単純なコードのリファクタリングに精通しています。たとえば、ツールを使用して並べ替えを行うことができます。
一般的に、リファクタリングは複雑さの問題を解決することです。
現在、より厄介なトピックの1つは、古い製品の再構築です。一部の古い製品には、数千万行のコードが含まれています。
古い製品の修正について。縫製と補修だけでは、複雑さを単純化する目的を達成できない場合があります。実際、同様の作業を行う場合は、より実行可能な計画があります。既存の製品を成形システム、つまり既存の実行中の製品として扱うことです。大きな変更を加えないでください。せいぜいバグを修正してください。
次に、これらの形成されたシステムをベンチマークとして使用して、新しいシステムを作成します。これは、大きな白いボックスを参照して小さな白いボックスを作成するのと同じです。このように、新しい小さな白いボックスは、大きな白いボックスのパフォーマンスよりも確実に有利になります。
このように段階的に行うと、信頼性が高まります。
上記の方法は書き直しであり、文字通りの意味で正しいと言う友人もいます。
実際には矛盾していません。違いは、再構築の方法は下から上、または上から下でなければならないということです。たとえば、現在の再構築のほとんどは、ボトムアップで行われると理解されています。つまり、このファイルに悪いコードの匂いがしてから、このファイルを変更します。これは問題ありません。この作業のコンテキストは比較的単純であり、技術的な負債がないことが前提です。
多くの状況はそれほど幸運ではありません。たとえば、一部の人々が現在直面している問題は、コンテキストがあまり明確でないことです。なぜこのコードはこのように書かれているのですか？ファイルに10,000行または30,000行があるのはなぜですか？インとアウトはあまり明確ではありません。
このとき、サブモジュール全体からトップダウン分析を行う必要があるかもしれません。このサブモジュールの機能要件と、必要なパブリックインターフェイスの数を整理しますか？内部パブリックインターフェイスを現在のように実装する必要がありますか？
ファイルは10,000行または30,000行に書き込むことができますが、いくつかの歴史的な理由があるはずです。これは、全体的な状況を把握するためのプログラミング能力が不十分であることが主な原因です。
この場合、ファイル自体から再構築することは非常に困難ですが、モジュールの設計全体の観点から上から下に再構築する方が簡単な場合があります。
そのような巨大なものにとって、最良の方法は分割して征服することです。まず、システムの機能ロジックポイントを決定する必要があります。これらのロジックポイントについては、対応する検査ポイントを配置する必要があります。つまり、再構築が完了した後、再構築が正しいことを確認する必要があります。これらの検査ポイントは実行されます。これは、統合テストとして理解できます。
これらの統合クラスのテストでは、リファクタリングする前に、現在のシステムで正常に実行できることを確認する必要があります。
この施設で、再建工事を行うことができます。より優れたツールの使用、関数と変数の名前の変更、呼び出しメソッドの変更など、多くのリファクタリングメソッドがあります。これらは、既存のコードに基づくリファクタリングです。ここでは、再構築を実現する方法を書き直すことに焦点を当てます。いわゆる書き換えは、別のコードベースを作成することです。さまざまなプログラミング言語を選択することもできます。
この場合、再構築では、最初に既存のビジネスロジックを再利用して、ビジネスロジック統合テストの合格率を100％にする必要があります。
どちらの方法を採用する場合でも、モジュールごとに高度化する必要があります。1つの検証は1つです。成功を急がず、一度にいくつかの問題を解決しようとしないでください。多くの失敗がある場合、それはあなたの自信を損なうかもしれません。したがって、私たちは常に進行中の、少しずつ前進しなければなりません。この方法を採用した後は、現在のシステムがどんなに大きくても、それに固執すれば、完全に再構築作業を完了することができます。
この時点で実行する必要のある特定の手順は、以下を参照できます。
1.機能要件に従ってパブリックインターフェイスを定義します。
2.パブリックインターフェイスに従ってテストケースコードを記述します。
3.この時点で、テスト駆動型開発の概念に従ってコードを入力できます。
4.既存のコードからコードを抽出できます。
5.抽出プロセス中に整理および再構築します。
このようにして、このサブモジュールが完了した後、既存のサブモジュールを置き換えて、システム全体で安全に実行できるかどうかを確認できます。
システム全体で、システムを多くのサブモジュールに分割できます。次に、各サブモジュールを分解して、システム全体の再構築を完了することができます。
システム全体が最初にリファクタリングされている場合は、トップダウンの観点から表示することもできます。
たとえば、最初は、すべてのサブモジュールがインターフェイスを完了していると想定して、いくつかのプレースホルダーと見なします。システム全体では、それ自体がサブモジュールであり、アウトラインの下のモジュールに属します。
このプロセスは、文字通りの意味での書き換えとして理解できます。実際には、システム自体の既存のコードと既存のロジックを確実に再利用するため、リファクタリングプロセスでもあります。
上記では、システムが完了した後にリファクタリングされていると想定しています。実際、リファクタリングはソフトウェア開発プロセス全体で実行できます。ソフトウェア開発の主な目標は、ビジネスロジックを実装し、顧客の問題を解決できるようにすることです。この目標が達成された後、コードのクリーンさを追求し、複雑さを最小限に抑え、現在のテクノロジーで最も高度なものを使用できるようにします。
したがって、機会があればいつでも、コードとデザインをリファクタリングする必要があります。
品質
品質は、お客様が当社の製品に満足しているかどうかに直接関係しています。では、ソフトウェア開発の品質をどのように確保する必要がありますか？
品質がしなければならない保証開発チーム全体の合意に従うことによって。コンセンサスとは、理想、哲学、人生観など、ソフトウェアの設計原則、設計パターン、コードスタイルなど、大きくても小さくてもかまいません。チームを構築することである場合、それは長期的な目標であり、コンセンサスは一般的な方向から開始する必要があります。プロジェクトの開発のみの場合、コンセンサスは特定の詳細から開始できます。
ソフトウェアの品質を保証するには、チーム全体がコンセンサスを形成する必要があり、全員がこのコンセンサスに従います。このコンセンサスは、開発原則、設計パターン、コード、特にアーキテクチャコードとテンプレートコードに具体化されています。プロジェクトの初期開発段階では、検討と統合を繰り返した後、コードのコンセンサス部分を確立するために、開発速度を遅くする必要があります。起きなさい。
スタイルの目標は、チームに何人の人がいても、書かれたコードが同じスタイルの1人のコードと同じになることです。
コードの品質も複雑さに反映されます。複雑さの目標は、現在の技術的条件下で、現在のコードの複雑さを最も低くすることです。
ソフトウェア品質のもう1つの重要な指標は、コードのホワイトボックステスト容易性です。テストフレームワークは、プロジェクトの開始時に取り上げる必要があります。コードの一部が形になったら、必要なテストケースを徐々に追加します。テストケースの選択は、ループの複雑さの計算方法に従って、または統合テストに対応するユーザー要件に従って決定できます。
次に、ソフトウェア開発でのテストについて詳しく説明します。コード関連のテストには、通常、ユニットテスト、統合テスト、およびシステムレベルのテストが含まれます。
ユニットテストは一般的に非常に面倒だと考えられています。ユニットテストの煩わしさは、主にテストケースの選択に反映されます。フルカバレッジ方式を使用してテストケースを選択すると、大量のテストコードが生成され、将来のメンテナンスの負担にもなります。場合リングの複雑さは、テストケースを選択するために使用され、テストコードの適切な量が生成されるが、リングの複雑さの計算はまた、大きな時間のオーバーヘッドです。
統合テストは、顧客の実際のビジネスニーズに関連しています。このプロセスでは、インターフェイスの入力と出力、および実行パスを明確にしてから、それに応じてテストケースを設計し、テストケースコードを記述する必要があります。
開発者は通常、統合テストの作成を拒否しません。それがもたらすメリットは明白であるため、開発効率とデバッグ効率が大幅に向上します。特に非インターフェースプログラミングの場合、インターフェースは特に重要です。
システムレベルのテストは、大規模システムのサブシステム間の統合テストです。これには主に2つの側面が含まれます。
1つの側面は、インターフェイスを使用した自動テストです。このようなテストアーキテクチャを通じて、人間のユーザーの使用プロセスがシミュレートされ、システムのいくつかの脆弱性を見つけるためにいくつかのランダムな動作が追加されます。
もう1つはインターフェースレステストであり、複数のサービスシステム間の呼び出しまたは同様のブラウザー自動化フレームワークの使用に反映されます。
完全なテストシステムは、エンジニアが開発効率を改善し、将来のシステムのメンテナンスと再構築のコストを削減するのに役立ちます。
テストの緊急性の観点から、統合テストが最も必要です。システム間のテストは、一部のテストツールを使用した手動テストに置き換えられる場合があります。ユニットテストは非常に広いディスカッションスペースを持つことができます。この部分では、特定の問題の特定の分析が必要です。
検査に対処するためだけにテストコードを書くことは無意味です。
テストコードが本来の価値を発揮しない場合、テストコードを書くことも無意味です。
エンジニアは、高品質のソフトウェアの主要な実行者です。プロジェクトチームのリーダー、アーキテクト、開発マネージャーは、高品質のソフトウェアの護衛と保護者です。
したがって、エンジニアがソフトウェアの品質をボトムアップで保証することを許可されるべきではありません。この要件はエンジニアにとって高すぎます。
概要
最後に、エンジニアリング文化と所有の精神について触れさせてください。エンジニア文化の意味については、以下の点が含まれていると思います。
- （1）自分のやることに熱意を持っている職人の精神。
- （2）試行錯誤の文化、挑戦する勇気があり、カニを最初に食べる人になることをいとわない。
- （3）自己規律、この自己規律は「私の日と私の体」を指します。継続的な自己修正と自己反射の改善。
オーナーシップの精神については、どんな仕事をしていても、自分の能力をフルに発揮して本当に何かをしたいのであれば、レベルや給与に関係なく、簡単に言えば、自分のやっていることを常に自分のものとしています。そうでなければ、私たちは常にすべてを気にし、物事を行うときに最善を尽くすことはできません。
損益に苦しむ精神があると、作業効率が低下します。時間が経つにつれて、自分が稼ぎたい「大金」が稼げなくなるだけでなく、能力や気分の向上にも支障をきたし、ゴマを拾い、スイカを失ったと言えます。時間は貴重であり、本当に無駄にすべきではありません。
所有の精神には、「これは私のビジネスではない」と決して言わない、短期的な利益のために長期的な利益を犠牲にすることなく物事を行うなど、多くの具体的な兆候があります。
この記事を通じて、著者は20年以上にわたってソフトウェアで作業した経験と経験を整理し、有意義な啓蒙をもたらすことを望んでいます。