※本記事は、Geminiによる意訳+翻訳を活用し、レイアウト調整したものです。
※感想は、オリジナルです。
原文
How I Achieved Maintanability, and Scalability in My Projects - DEV Community
意訳+要約
私のプロジェクトで保守性と拡張性を実現した方法
この記事では、プロジェクトの保守性とスケーラビリティを実現する方法について説明しています。コードベースが整理されていないと、開発の妨げになる可能性があるため、著者はプロジェクトの改善に取り組みました。
改善の5つの主要な目標
- 技術スタックの選択: 使いやすく、利点のあるものが理想的ですが、選択肢が多すぎると管理が難しくなるため、プロジェクトに適した技術を選択する必要があります。
- プロジェクト構造の構築: アトミックデザインシステムと機能ベースの構造を使用して、プロジェクトを適切に編成することが重要です。
- コードの結束性: コードの標準化により、チームのコラボレーションが容易になり、混乱が少なくなります。ESLintとStylelintを使用して、コードの品質を確保します。
- コード作成の指針: コードベースを文書化することは重要です。テンプレートコードベースを文書化し、開発者が理解できるようにする必要があります。
- 課題への適応: 開発者は継続的に学習し、さまざまなコーディングパターンを習得する必要があります。場合によっては、慣習から外れることも必要ですが、長期的な保守性を向上させることができます。
特に重要な部分
- 技術スタックは、プロジェクトのニーズに合致し、使いやすく、利点のあるものを選択する必要があります。
- アトミックデザインシステムと機能ベースの構造を使用して、プロジェクトを適切に編成することが重要です。
- コードの標準化により、チームのコラボレーションが容易になり、混乱が少なくなります。
- コードベースを文書化し、開発者が理解できるようにする必要があります。
- 開発者は継続的に学習し、さまざまなコーディングパターンを習得する必要があります。
このブログ記事は、コードベースの保守性とスケーラビリティを向上させるためのガイダンスを提供しています。特に、技術スタックの選択、プロジェクト構造、コードの標準化、コード作成の指針、課題への適応の重要性が強調されています。
GeminiへのQA
Ｑ：人の出入りが激しいと、改善も難しいのではないでしょうか？
人の出入りが激しいと、プロジェクトの保守性とスケーラビリティの向上は確かに難しい課題となります。しかし、以下の点に注意することで、その影響を軽減することは可能です。
1. ドキュメントの充実
- コードベースだけでなく、プロジェクトのアーキテクチャ、設計思想、技術スタックの選択理由などを詳細に文書化することで、後から参画したメンバーでもプロジェクトを理解しやすくなります。
- ドキュメントは常に最新の状態に保ち、変更履歴を残しておくことで、誰がいつどのような変更を行ったのかを把握しやすくなります。
2. ナレッジ共有の仕組み
- 定期的なコードレビューや技術共有会を開催することで、チームメンバー間の知識共有を促進します。
- 新規参画者向けに、オンボーディング資料や研修プログラムを用意することで、プロジェクトへの迅速なキャッチアップを支援します。
3. ツールの活用
- バージョン管理システムや静的解析ツールなどを活用することで、コードの変更履歴を追跡し、品質を維持しやすくなります。
- 自動テストツールを活用することで、コード変更による不具合の早期発見と修正を促進します。
4. チームワーク
- チームメンバー間でオープンなコミュニケーションを図り、積極的に質問し合う文化を醸成することで、問題を早期に発見し、解決しやすくなります。
- メンバー同士が互いに教え合い、学び合うことで、個々のスキルアップとチーム全体の成長につなげることができます。
5. 継続的な改善
- プロジェクトの状況を定期的にレビューし、必要に応じて改善点を洗い出します。
- 新しい技術や手法を取り入れることで、プロジェクトの保守性とスケーラビリティを向上させ続けることが重要です。
人材の流動化は避けられない課題ですが、上記の対策を講じることで、その影響を最小限に抑え、プロジェクトの持続的な発展を実現することが可能です。
Ｑ：プロジェクトに適した技術を選択するには、何に気をつければよいのでしょうか？
プロジェクトに適した技術を選択することは、プロジェクトの成功にとって非常に重要です。適切な技術を選択すれば、開発効率の向上、保守性の向上、スケーラビリティの向上など、様々なメリットを得ることができます。
技術を選択する際に気をつけべきポイントは、以下のとおりです。
1. プロジェクトの要件を明確にする
まず、プロジェクトの目的、目標、制約を明確にすることが重要です。どのような機能が必要なのか、どのようなパフォーマンスが求められるのか、どのような予算やスケジュールで開発を行うのかなどを明確にすることで、適切な技術を絞り込むことができます。
2. 技術の特性を理解する
候補となる技術のそれぞれについて、機能、性能、使いやすさ、コミュニティの規模、ドキュメントの充実度などを調査し、それぞれの特性を理解する必要があります。
3. 過去の事例を参考にする
類似するプロジェクトでどのような技術が使われているのかを参考にするのも良い方法です。成功事例だけでなく、失敗事例から学ぶこともできます。
4. チームのスキルを考慮する
チームメンバーがすでに習得している技術や、学習意欲などを考慮する必要があります。新しい技術を導入する場合は、メンバーへの教育・研修も必要となります。
5. 将来的にも利用できる技術かどうか
技術は常に進化しており、陳腐化してしまうものもあります。将来的にも利用できる可能性が高い技術を選択することが重要です。
6. コストを考慮する
ライセンス料や開発ツールの費用など、技術導入にかかるコストを考慮する必要があります。オープンソースソフトウェアであれば、ライセンス料はかかりませんが、導入や運用に時間がかかる場合があります。
7. テストを行う
実際に候補となる技術を使って、簡単なアプリケーションなどを開発してみて、使いやすさや性能などを評価してみるのも良い方法です。
Ｑ：事例を待たずに導入しているプロジェクトは、どういう考えでいるのでしょうか？
事例を待たずに導入を進めるプロジェクトは、以下のような考え方に基づいている可能性があります。
1. 市場投入の迅速化
競争が激しい市場では、少しでも早く製品やサービスを市場に投入することが重要です。事例を待って技術を検討していると、ライバルに先を越されてしまう可能性があります。そのため、リスクを承知で事例を待たずに導入を進めるプロジェクトもあります。
2. 最新技術の活用
技術は常に進化しており、新しい技術を活用することで、開発効率の向上や、競争力強化につながる可能性があります。事例に記載されている技術が陳腐化している可能性があるため、最新技術を活用したいプロジェクトでは、事例を待たずに導入を進めることがあります。
3. プロジェクトの独自性
類似プロジェクトがない場合、事例を参考に開発するよりも、独創的なプロジェクトを開発することができます。独創的なプロジェクトを開発することで、市場シェアを獲得しやすくなります。そのため、他社との差別化を図りたいプロジェクトでは、事例を待たずに導入を進めることがあります。
4. リスク許容度の高さ
事例を待たずに導入することには、技術選定の失敗、想定外の課題への対応、非効率な開発、品質問題、セキュリティリスクなどのリスクが存在します。しかし、これらのリスクを許容できるプロジェクトでは、事例を待たずに導入を進めることで、開発の迅速化や最新技術の活用、プロジェクトの独自性といったメリットを得ることができます。
5. 経験豊富なチーム
技術選定や開発に十分な経験と知識を持つチームであれば、事例を待たずに導入しても、高い成功確率を実現できる可能性があります。経験豊富なチームであれば、想定されるリスクを事前に予測し、対策を講じることができます。
6. 十分な予算
事例を待たずに導入することには、リスクが高いため、十分な予算を確保しておくことが重要です。十分な予算があれば、発生した問題を迅速に解決することができます。
7. 柔軟な開発プロセス
事例を待たずに導入する場合は、変化に柔軟に対応できる開発プロセスを構築する必要があります。開発状況に合わせて、計画を適宜変更していくことが重要です。
8. 継続的な改善
事例を待たずに導入したとしても、開発完了後も継続的に改善を進めていくことが重要です。ユーザーからのフィードバックを収集し、製品やサービスを改良していくことで、成功確率を高めることができます。
感想＋雑記
システム設計ができないと、保守性と拡張性の維持は難しいなと感じた。
小さい単位のやつじゃなくて、システム全体レベルで維持していくには、ちゃんとしたアーキテクチャの考えが必要なのだろう。
チーム開発となると、人の出入りがあっても大丈夫なように記録をちゃんと取っておかないと厳しそうだな。
指針の確認という意味では、ArchUnit などのアーキテクチャの担保をとるための機構が必要なのかも知れない。
小さな単位でやってると、ArchUnit の有用性がわからんかったけど、個人開発してるやつがデカくなってきたら、ArchUnit みたいなのを入れてみたくなってくる。
全部作ったのは自分だけど、今の自分と過去の自分は違うからな。
今のルールに全部沿っているのかは、どこかで確認したい感はある。
