プロジェクト概要
- LINEBot
よかった
- LINEBotの開発経験を積めた
-
静的なドキュメントをある程度書いた
-
ERD
-
PlantUMLを使用した
-
メリット
- 差分管理できる
-
デメリット
- 編集が面倒くさい
-
- 今度はMySQL Workbenchを使って比較検討してみよう
-
-
ドメインモデル
- PlantUMLを使用した
-
-
JWT認証 + 認可付きCSVダウンロードの初実装
-
サーバ側は真面目にテスト書いた
- 変更箇所が甚大な修正も安心して行えた
-
きれいな設計の意識
-
依存性逆転
- サポートするLINEBotの返信タイプは追加が予想されるため、インタフェースに依存させるなど
-
デザインパターンの適用
-
GoF
-
Visitor
- ドメインオブジェクトからLINEBot依存の振る舞いの分離
-
-
PoEAA
-
DataMapper
- 複雑なドメインオブジェクトとテーブルとのマッピングに使用
-
-
-
よくなかった
-
永続化データ構造を自前で定義してしまった
- 具体的には、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調整する