はじめに
本記事は、私のポートフォリオサイト「KidsPlayGround」の技術選定、アーキテクチャ、そして開発プロセスにおけるこだわりを解説するものです。単に動くものを作るだけでなく、保守性、拡張性、テスト容易性を重視し、実務で通用する品質を目指しました。
ポートフォリオサイト
1. プロジェクト概要と主要技術スタック
「KidsPlayGround」は、子供と遊べる施設情報を提供するWebアプリケーションです。ユーザーは様々な施設の情報を検索・閲覧し、お出かけの計画に役立てることができます。
このプロジェクトを支える主要な技術スタックは以下の通りです。
- バックエンド: Python 3.12.3, Django 5.1.5, PostgreSQL
- フロントエンド: プレーンなJavaScript, jQuery
- インフラ/開発環境: Docker, Docker Compose
- コード品質/テスト: pytest, mypy (django-stubs), flake8, black, ESLint, Prettier
- CI/CD: GitHub Actions
2. 堅牢なアーキテクチャ設計
プロジェクトの基盤となるアーキテクチャは、開発効率と将来的な拡張性を考慮して設計しました。
バックエンド (Django) とフロントエンドの連携
アプリケーションは、Djangoのテンプレートエンジンを主軸とし、サーバーサイドレンダリングによってユーザーインターフェースを構築しています。
- Djangoの標準ビュー: 堅牢なバックエンド機能を提供し、データ管理とビジネスロジック、そしてHTMLのレンダリングを担当
- プレーンなJavaScriptとjQuery: 必要に応じて、クライアントサイドでのインタラクティブな要素や動的なUI操作を実現するために補助的に使用しています
この構成により、Djangoの持つ強力な機能を最大限に活用しつつ、ユーザー体験を向上させるための柔軟性も確保しています。
データベース
信頼性と豊富な機能を考慮し、リレーショナルデータベースにはPostgreSQLを採用しました。
3. 品質を担保する開発プロセスとツール
本プロジェクトでは、コードの品質と開発効率を両立させるため、厳格な開発プロセスと多様なツールを導入しています。
TDD (テスト駆動開発) の実践
開発の核として、TDDスタイルを全面的に採用しました。
「Red → Green → Refactor」のサイクルを徹底し、小さなステップで開発を進めることで、バグの早期発見と設計の改善を促しました。
テストコードは、単に機能が動くことを確認するだけでなく、アプリケーションの「振る舞い」を明確に記述する「動く仕様書」として設計しました。特に、テストケース名には日本語を積極的に採用し、非エンジニアを含む関係者でも仕様を理解しやすいように工夫しています。また、「振る舞いをテストし、実装の詳細はテストしない」という原則を遵守することで、リファクタリングに強く、壊れにくいテストコードを実現しています。
-
テストフレームワーク: Pythonには
pytestを、JavaScriptにはJestを採用し、それぞれの言語・フレームワークに最適化されたテスト環境を構築しています。
静的解析と型チェックによる品質向上
コードの品質と保守性を高めるため、以下の静的解析ツールと型チェッカーを導入しています。
-
Python:
-
flake8: コード規約違反や潜在的なバグを検出。 -
black: コードフォーマットを自動で統一。 -
Mypyとdjango-stubsによる厳格な型チェック:
mypy.iniでdisallow_untyped_defs = Trueを設定し、全ての関数定義に型ヒントの記述を強制しています。これにより、開発初期段階での型関連のバグを排除し、大規模開発におけるコードの安全性を飛躍的に高めました。
-
-
JavaScript:
-
ESLint: コード品質とスタイルを自動でチェック。 -
Prettier: コードフォーマットを自動で統一。
-
CI/CD (GitHub Actions) による自動化
開発プロセスを効率化し、常に高品質なコードを維持するため、GitHub Actionsを用いたCI/CDパイプラインを構築しています。
mainブランチへのPushをトリガーに、静的解析、テスト、Dockerイメージのビルドとプッシュ、そしてRenderへのデプロイを自動で実行するようにしています。
これにより、コード品質のゲートウェイを設け、バグの早期発見と開発プロセスの効率化を実現しています。Dockerを活用することで、本番環境と開発環境の差異を最小限に抑え、安定したデプロイを実現しています。
4. 各技術領域における工夫と学び
保守性と可読性を意識した設計
単一責任の原則(SRP)を始めとするSOLID原則を意識し、クラスや関数の責務を明確に分離しました。
適切なディレクトリ構造
Django標準のディレクトリ構造に準拠しつつ、大規模化に備えて各アプリケーション内の構造も整理しています。特にtemplates, static, testsを明確に分離し、コードの見通しを良くしています。
/home/jam/kidsPlayGround/
├───accounts/
│ ├───__init__.py
│ ├───admin.py
│ ├───apps.py
│ ├───models.py
│ ├───README.md
│ ├───tests.py
│ ├───urls.py
│ ├───views.py
│ ├───__pycache__/
│ ├───migrations/
│ └───templates/
├───myapp/
│ ├───__init__.py
│ ├───admin.py
│ ├───apps.py
│ ├───models.py
│ ├───urls.py
│ ├───__pycache__/
│ ├───management/
│ ├───migrations/
│ ├───scripts/
│ ├───static/
│ ├───templates/
│ ├───templatetags/
│ ├───tests/
│ └───views/ # viewsディレクトリ以下にさらにファイルを分割
├───mysite/
│ ├───__init__.py
│ ├───asgi.py
│ ├───urls.py
│ ├───wsgi.py
│ ├───__pycache__/
│ └───settings/ # settingsディレクトリ以下にbase.pyなどを配置
├───users/
│ ├───__init__.py
│ ├───admin.py
│ ├───apps.py
│ ├───models.py
│ ├───views.py
│ ├───__pycache__/
│ ├───migrations/
│ └───tests/
例えば、myapp/views/以下にさらにファイルを分割することで、ビューの責務を細分化し、可読性と保守性を高めています。
5. まとめと今後の展望
本プロジェクトを通じて、単一技術の習得に留まらず、モダンなWebアプリケーション開発における一連のプロセス(設計、実装、テスト、品質管理、CI/CD)を実践的に経験しました。特に、TDDや厳格な型チェック、CI/CDの導入は、コードの品質と開発効率を両立させる上で不可欠であることを実感しました。