下記の本を参考にしました。レガシーコードとはレガシーコードとは、一般的に以下のような特徴を持つコードのことを指します。テストがない自動化されたテストが存在しないため、変更が難しく、バグが発生しやすい。依存関係が多い他のコードやシステムに強く依存しているため、変更が困難。可読性が低いコードが複雑で理解しにくく、ドキュメントも不足していることが多い。最新の技術やベストプラクティスが適用されていない。これらの特徴により、レガシーコードは保守や拡張が非常に難しく、開発者にとって大きな負担となります。この非効率による失敗でとてつもない損額が発生していることがCHAOSレポートによっても明らかになっている。ためか」を説明することで、プロジェクトやタスクの方向性が明確になり、チーム全体の理解と協力が得られやすくなります。これにより、プロジェクトの成功率が高まり、より効果的な成果を得ることができます。目的を明確にすることで、プロジェクトやタスクの最終的なゴールがはっきりします。これにより、チーム全体が同じ方向を向いて努力することができます。理由を説明することで、なぜそのプロジェクトやタスクが重要なのかを理解できます。これにより、チームメンバーのモチベーションが高まり、プロジェクトに対するコミットメントが強くなります。誰のためか誰のためかを明確にすることで、プロジェクトやタスクの成果が誰にどのような影響を与えるのかを理解できます。これにより、ユーザーやステークホルダーのニーズに応じた最適な解決策を提供することができます。小さなバッチを作る「小さなバッチで作る」というプラクティスは、ソフトウェア開発において大きな機能やタスクを小さな部分に分割して進める方法です。これにより、開発プロセスがより効率的で柔軟になり、リスクを減らすことができます。大きな機能やプロジェクトを小さなタスクに分割します。これにより、各タスクが管理しやすくなり、進捗状況を把握しやすくなります。頻繁なリリース小さなバッチで作業を進めることで、頻繁にリリースすることが可能になります。これにより、ユーザーからのフィードバックを早期に得ることができ、必要な修正を迅速に行えます。小さなバッチで作業を進めることで、問題が発生した場合でも影響範囲が小さくなります。これにより、迅速に問題を特定し、修正することができます。小さなバッチでの作業は、継続的な改善を促進します。各リリースごとにフィードバックを受け取り、次のリリースに反映させることで、製品の品質を向上させることができます。継続的インテグレーション(CI)は、ソフトウェア開発において、開発者が書いたコードを頻繁にメインのコードベースに統合するプロセスです。これにより、コードの変更が小さな単位で行われ、問題の早期発見と修正が可能になります。開発者は自分のコード変更を頻繁に(通常は1日1回以上)リポジトリにマージします。これにより、統合の際に発生する競合やバグを早期に発見できます。自動化されたビルドとテストCIでは、コードがリポジトリにマージされるたびに自動的にビルドとテストが実行されます。これにより、コードの品質を保ちつつ、バグの早期発見が可能になります。自動化されたプロセスにより、問題が発生した場合にはすぐに開発者にフィードバックが返されます。これにより、迅速な対応が可能になります。リリースサイクルの短縮CIを導入することで、リリースサイクルが短縮され、頻繁に新しいバージョンをリリースすることが可能になります。これにより、ユーザーからのフィードバックを早期に得ることができます。協力しあう協力しあうプラクティスには、チームメンバーが共同で作業を進めるためのさまざまな方法があります。ペアプログラミングペアプログラミングは、二人の開発者が一緒にコードを書く手法です。一人が「ドライバー」として実際にコードを書き、もう一人が「ナビゲーター」としてコードをレビューし、提案を行います。この方法は、以下のようなメリットがありますコード品質の向上ナビゲーターがリアルタイムでコードをチェックするため、バグやミスが減少します。異なる視点やスキルを持つ二人が協力することで、互いの知識や技術が向上します。二人で問題に取り組むため、解決が早くなります。関連する機能やデータを一つのモジュールやクラスにまとめること。ユーザー認証に関する機能を一つのクラスにまとめることで、コードの理解と保守が容易になります。疎結合モジュールやクラス間の依存関係を最小限にすること。インターフェースを使用して、異なるモジュール間の依存を減らし、変更の影響を最小限に抑えます。カプセル化データやメソッドをクラス内に隠蔽し、外部から直接アクセスできないようにすること。クラスのプロパティをプライベートにし、必要な場合のみ公開メソッドを通じてアクセスさせます。断定的コードが明確で一貫性があり、意図がはっきりしていること。メソッド名や変数名を意味のあるものにし、コメントを適切に追加してコードの意図を明確にします。重複したコードを避け、シンプルで効率的なコードを書くこと。共通の処理をメソッドにまとめ、再利用することでコードの重複を減らします。テストを書くコードを書く前にテストを作成することも役に立ちます。新しい機能を追加する前に、その機能が正しく動作するかどうかを確認するためのテストケースを作成します。利点バグの早期発見コードを書く前にテストを作成することで、バグを早期に発見しやすくなります。リファクタリングの安心感テストがあることで、コードのリファクタリング(改善)を行う際に、既存の機能が壊れていないかを確認できます。ドキュメントとしての役割テストケースは、コードの仕様や期待される動作を示すドキュメントとしても機能します。小さなステップで進める一度に大きなテストを書くのではなく、小さな機能ごとにテストを作成し、段階的に進めます。ふるまい駆動開発テストを通じてシステムのふるまいを明確にする手法です。BDDでは、テストケースをユーザーの視点から記述し、システムがどのように動作するべきかを示します。「ユーザーがログインボタンをクリックしたとき、正しい資格情報が入力されていれば、ダッシュボードページにリダイレクトされるべき」というテストケースを作成します。明確な仕様テストケースがシステムの仕様を明確に示すため、開発者間のコミュニケーションが円滑になります。バグの早期発見ふるまいを明示することで、期待される動作と実際の動作のギャップを早期に発見できます。(Then)」の形式で記述します。設計は最後に行う最初から詳細な設計を行うのではなく、実際の開発プロセスを通じて設計を進化させることがプラクティスに挙げられてます。プロジェクトの初期段階では大まかな設計に留め、実際のコーディングやテストを通じて設計を改善していきます。要件や技術的な変更に柔軟に対応できるようになります。アプローチ開発サイクルごとに設計を見直し、必要に応じて改善を行います。(TDD)テストを先に書くことで、設計が自然と進化し、必要な機能に焦点を当てた設計が行われます。ピンニングテストピンニングテストは、既存のコードの動作を固定するためのテストです。これにより、リファクタリング中にコードの動作が変わらないことを確認できます。現在の動作をテストでキャプチャし、その後の変更が意図しない影響を与えないようにします。依存性の注入は、コードの依存関係を外部から注入することで、テストやメンテナンスを容易にする手法です。これにより、モジュール間の結合度が低くなり、個々のコンポーネントを独立してテストできるようになります。ストラングラーパターンと抽象化ブランチストラングラーパターンは、古いシステムを段階的に新しいシステムに置き換える方法です。新しい機能を新しいシステムに実装し、徐々に古いシステムの機能を移行します。抽象化ブランチは、コードの一部を抽象化して新しい実装に切り替えるための技術です。これにより、リファクタリングの影響を最小限に抑えながら、段階的に改善を進めることができます。オープンクローズド原則に基づくリファクタリングオープンクローズド原則は、ソフトウェアエンティティ(クラス、モジュール、関数など)は拡張に対して開かれており、修正に対して閉じているべきという原則です。これを実現するためには、既存のコードを変更せずに新しい機能を追加できるように設計します。インターフェースを使用して新しい機能を追加することで、既存のコードに影響を与えずに拡張できます。これらのプラクティスを実践することで、以下のような価値を得ることができますコードの信頼性向上ピンニングテストや依存性の注入により、コードの動作が安定し、バグの発生を防ぎます。依存性の注入やオープンクローズド原則に基づく設計により、コードの変更が容易になります。段階的な移行ストラングラーパターンと抽象化ブランチを使用することで、システム全体を一度に変更するリスクを避け、段階的に改善を進めることができます。読者になる広告を非表示にするもっと読むコメントを書く2024-08-14要件定義設計を学んだのでアウトプット!!こんにちは!最近、課題解決の業務を行うことが多く、その際に設計等を見直すことが多々あるのですが、私自身設計に詳しくなく結構苦労しています。「要件定義設計」です。下記の本を参考にしました。要件定義とは要件とは、作ってほしい人が作る人の間の合意事項のことです。この依頼が漠然としたものだと双方困ってしまいます。これを明確に定めた形にすることを要件定義といいます。まとめると、依頼した人が出来上がったものに対して、OKをいうために何がどうなればいいのかを明確に定めたもののことです。要望は、クライアントやステークホルダーからの初期の希望やアイデアです。この段階では、技術的な制約を考えずに、望むことを自由に出してもらいます。「アプリの使い勝手を改善してほしい」や「月次売上データをグラフで出力したい」といった内容です。要求は、要望を取捨選択し、整理、構造化したものです。具体的には、「ユーザーが少ないクリックで購入できるようにしたい」といった内容になります。この段階で、要望を実現するための具体的な手段が検討されます。検討では、要求をさらに詳細に分析し、実現可能性や費用対効果を評価します。グラフを画面に出力することが本当に必要か、他の手段(例えばCSV出力)で代替できないかを考えます。この段階で、技術的な制約やリスクも考慮します。提案は、検討結果を基に、最適な解決策をクライアントやステークホルダーに提示する段階です。「月次売上をCSVで出力し、Excelでグラフを作成する」という具体的な方法を提案します。合意は、提案内容に対してクライアントやステークホルダー全員が同意する段階です。ここで、最終的な要件が確定されます。「月次売上をCSVで出力する機能を開発する」という具体的な要件が合意されます。要件とは、ゴールから逆算して考えることが大切です。プログラマーがソフトウェアを完成させるために必要な情報を定義する必要があるのです。基本的には下記のようなものが挙げられます。企画を確認するまずは、プロジェクトの企画を確認します。これは、プロジェクトの目的や目標、期待される成果物を明確にする段階です。新しいアプリを開発する場合、そのアプリが解決する問題やターゲットユーザーを理解することが重要です。全体像を描く次に、プロジェクトの全体像を描きます。これは、プロジェクトの範囲や主要な機能、ステークホルダーを把握することを意味します。)をリストアップし、それぞれの機能がどのように連携するかを考えます。大まかに区分けするプロジェクトの全体像が見えたら、それを大まかに区分けします。これは、プロジェクトをいくつかの主要なフェーズやモジュールに分割することです。ユーザーインターフェース、バックエンド、データベースなどの主要な部分に分け、それぞれの部分で必要な作業をリストアップします。実装技術を決める次に、各部分を実現するための実装技術を決定します。これは、使用するプログラミング言語、フレームワーク、ツールなどを選定する段階です。フロントエンドにはReact、バックエンドにはNode.js、データベースにはMongoDBを使用する、といった具体的な技術選定を行います。実装したいことを整理整頓する最後に、実装したいことを整理整頓します。これは、各機能やモジュールの詳細な要件をリストアップし、優先順位をつけることです。ユーザー登録機能は最初に実装し、その後に商品検索機能を追加する、といった具体的な実装順序を決定します。利用者の行動シナリオを描く利用者の行動シナリオは、ユーザーがシステムやサービスをどのように利用するかを具体的に描いたものです。これにより、ユーザーの視点からシステムの使い勝手や必要な機能を明確にすることができます。ペルソナの作成まず、典型的なユーザー像(ペルソナ)を設定します。シナリオの作成ペルソナがシステムを利用する具体的なシナリオを描きます。「ユーザーがログインして商品を検索し、購入するまでの流れ」を詳細に記述します。実際のユーザー行動と照らし合わせて、シナリオが現実的かどうかを確認します。概念データモデルを作る概念データモデルは、システムで扱うデータの構造を高レベルで表現したものです。これにより、データの関係性や重要なデータ項目を明確にすることができます。主要なエンティティの特定システムで扱う主要なデータ項目(エンティティ)を特定します。各エンティティ間の関係性を定義します。「ユーザーは複数の注文を持つ」や「注文は複数の商品を含む」といった関係です。UIを考えるUI(ユーザーインターフェース)は、ユーザーがシステムと直接やり取りする部分です。使いやすく、直感的なデザインが求められます。画面のレイアウトを簡単に描いたワイヤーフレームを作成します。これにより、各画面の構成や要素の配置を視覚的に確認できます。ユーザビリティテストワイヤーフレームを基に、ユーザビリティテストを行い、ユーザーがどのように画面を操作するかを確認します。フィードバックを基に改善を行います。デザインの詳細化ワイヤーフレームを基に、色やフォント、アイコンなどのデザイン要素を追加し、詳細なUIデザインを作成します。機能について考える機能は、システムが提供する具体的な動作やサービスです。ユーザーのニーズに応じた機能を考えることが重要です。必要な機能をリストアップします。ユーザー登録、ログイン、商品検索、購入などです。各機能の重要度や実装の難易度を考慮し、優先順位を設定します。重要な機能から順に実装していきます。各機能の詳細な仕様を作成します。ユーザー登録機能では、入力項目やバリデーションルールを明確にします。データについて考えるデータは、システムが扱う情報のことです。データの構造や保存方法を考えることが重要です。データモデルの作成システムで扱うデータの構造を定義します。ユーザー、商品、注文などのエンティティとその関係性を図示します。データベース設計データモデルを基に、データベースの設計を行います。テーブルの構造やインデックスの設定などを行います。データのセキュリティデータの保存や通信におけるセキュリティ対策を考えます。パスワードのハッシュ化やSSL/TLSの使用などです。要件定義の仕上げ要件定義の仕上げは、これまでに検討した内容を最終的にまとめる段階です。要件定義書を作成し、全ての要件を文書化します。データモデル、UIデザインなどが含まれます。レビューとフィードバック要件定義書を関係者にレビューしてもらい、フィードバックを受け取ります。必要に応じて修正を行います。全ての関係者が要件定義書に同意し、最終的な合意を得ます。これにより、プロジェクトの進行が正式にスタートします。私が本を読んでのまとめとなりますので、他の読者と少し解釈が違うかもしれませんがそこはご容赦ください。間違っている場合は教えてください読んでいただきありがとうございます。ブログを報告する引用をストックしましたストック一覧を見る閉じる引用するにはまずログインしてくださいログイン閉じる引用をストックできませんでした。再度お試しください閉じる限定公開記事のため引用できません。