🛠️
【DAY49】過去のバックエンド実装を徹底分解：ポートフォリオ再学習ログ
はじめに
過去に自分で作ったバックエンドのポートフォリオを、今の視点であらためて読み返してみた。
「どうやって作ったか」よりも「なぜこう書いたか？」を考えることで、自分の理解や設計力の変化に気づくことができた。
今回は、その分析ログとして「何が課題だったか」「どう改善できるか」を中心にまとめていく。
使用技術（当時）
- Node.js / Express
- MySQL
- Sequelize（ORM）
- MVC構成（部分的）
当時は「動けばOK」の思考で、細かい設計原則や保守性にはほとんど意識が向いていなかった。
課題点と改善方針
1. ルーティング構成が粗い
問題点：
すべてのAPIエンドポイントが /api/users に詰め込まれており、認証やプロフィール処理も同一ファイルで管理。役割分離ができておらず、可読性・保守性が低い。
改善案：
-
/api/auth,/api/profile,/api/adminなど、機能単位でルーティングを分離 -
routes,controllers,servicesのディレクトリ構成に整理
2. バリデーションが不十分
問題点：
リクエストデータのバリデーションをController内で簡単に済ませており、条件分岐も曖昧。XSSやSQLインジェクションへの対策も弱い。
改善案：
-
JoiやZodを導入し、リクエストごとにバリデーションスキーマを定義 - ミドルウェア層での事前チェックを徹底
3. ロジックの分離が甘い
問題点：
Controllerの中にDB操作ロジックがベタ書きされていて、テストしにくく、再利用も困難。
改善案：
- ビジネスロジックを
services層に分離 - Controllerはリクエスト/レスポンスの制御に集中させる
学びと気づき
- 昔のコードは「黒歴史」ではなく「教材」。
- あいまいな設計でも、一度形にした経験は今の自分の思考の土台になっている。
- 書いたコードを「読む力」もまた、開発者にとって重要なスキルのひとつ。
今後やりたいこと
- Sequelizeに頼りすぎず、生SQLにも触れて理解を深める
- ユニットテスト（Jest）やE2Eテストの導入
- CI/CDパイプライン（GitHub Actions）の構築
- Docker対応による環境統一と再現性の確保
おわりに
過去のバックエンド実装を振り返ることは、単なるノスタルジーではない。
自分の理解力、設計力、そして“成長の軌跡”を確認するための最高の材料だ。
これからも「書いたら終わり」ではなく、「書いたあとからがスタート」という意識で、技術を育てていきたい。
Discussion