勉強日記

チラ裏

LINEBotプロジェクト振り返り

Laravel Vue.js プロジェクト振り返り

プロジェクト概要

  • LINEBot

よかった

  • LINEBotの開発経験を積めた
  • 静的なドキュメントをある程度書いた
    • ERD
      • PlantUMLを使用した
        • メリット
          • 差分管理できる
        • デメリット
          • 編集が面倒くさい
      • 今度はMySQL Workbenchを使って比較検討してみよう
    • ドメインモデル
      • PlantUMLを使用した
  • JWT認証 + 認可付きCSVダウンロードの初実装
  • サーバ側は真面目にテスト書いた
    • 変更箇所が甚大な修正も安心して行えた
  • きれいな設計の意識
    • 依存性逆転
      • サポートするLINEBotの返信タイプは追加が予想されるため、インタフェースに依存させるなど
    • デザインパターンの適用

よくなかった

  • 永続化データ構造を自前で定義してしまった
    • 具体的には、LINEBotの返信オブジェクトのJSON表現
    • MessageBuilder@buildMessage()で返却されるJSON表現をそのまま使用するべきだった
    • プロジェクト初期に謎の自前フォーマットを定義し、そのまま突っ走ってしまった
      • LINE非依存であり、Slack等にも横展開できるため、一概に失敗とは言えないかも
  • CI構築をサボった
    • 当初はもっとサクッと終わる想定だったんですよ
      • CI構築するほどではない、と思っていた
    • Laradockコンテナのビルドに時間がかかるためCI構築の試行錯誤が億劫
      • そろそろLaradockやめたい
      • ビルド済イメージをdockerhubかどこかにpushしておきたい
  • Visitorパターンを適用した結果、Acceptor追加時の変更箇所が甚大になった
    • パターンの特徴なので、前もってわかってはいた
    • 今回はドメインオブジェクトからLINE実装を分離することを選んだ
  • ユースケース記述やロバストネス図を書かなかった
    • 「元気な時に書こう」は永久に書かない
  • migrationまわりの扱いが雑だった
    • migrationの編集はGitのrebaseと同じ感覚で実施したほうがよさそう
      • 一度作ってpushしたら二度と触ってはいけない
  • プロジェクトの全体像を理解できていなかった
    • 客との調整をプロキシに丸投げして実装オンリー
    • 認識齟齬による手戻りが何度かあった
    • 客の温度感もわからなかった
  • 見積もりが甘かった
  • フロントエンドはテスト書かなかった
  • emacsの調整不足
    • PHP(intelephense)
      • Carbon/Carbonなど巨大なファイルを読むと定義ジャンプで数秒〜十数秒固まる
    • Vue.js(忘れた)
      • なんか常に重い
      • <style lang="stylus">をちゃんと認識できてない

Keep

  • 静的なドキュメント書く
  • 真面目にテスト書く
  • きれいな設計
    • そのために勉強
      • PoEAAさっさと倒す
      • ほいでDDD読む

Problem

  • 「よくなかった」全部

Try

  • 外部サービスとの連携等がある場合は、そのデータ表現を真っ先に調べる
    • 今回で言うとLINEBotの返信のJSON表現
  • その次くらいに真っ先にCI環境を構築する
  • ユースケース記述やロバストネス図も書く
  • ERDの作成にMySQL Workbench使ってみる
  • そのために、客やプロキシとのコミュニケーションを密にする
  • Laradockそろそろやめる
  • 見積もり精度を上げる
    • タスクを細分化して積み上げて見積もる
    • 実績値と比較して開発速度データを蓄積する
  • emacs調整する