システムを作るときにいつも何をしているのか残しとく
このページについて
新しくシステム作るときに、いつも自分が何してるのかを言語化しておくページ
唐突に暇になったので、やってることをツラツラと書いてみる。
システム開発手順
大概企画を渡されたり、構想渡されたりするので、そこからスタートする感じです。
私は企画をしたりとかはできない(できたら会社員してないと思う)ので、
こんな感じのことをしたい、を具現化するところからがスタートです。
先ずは企画を自分の言葉で説明できるようになる
企画を渡されて、じゃあDB設計する、コードを書く、みたいなことはしません。
先ずはやりたいこと、実現したいことなんかを自分の中で言語化します。
企画を渡されても、分からないことだらけなので、先ずは企画の意図だったりを理解して自分の中で腹落ちさせます。
腹落ちまでしたら、その理解が正しいかの認識を合わせるために、資料を書き殴ります。
初回の打ち合わせに向けて何を書いているか
正式な文章に落とすことはなくて、話し合うための資料を作っていきます。
ここ数年はずっとCaccoを使って書いてます。 cacoo.com
書く内容的には、
- ユースケース図
- 概念モデル
- 雑なスケッチのワイヤー
の順番で書いていってます。 ユースケースと概念モデルは割と行ったり来たりする感じ。
やりたいことをユースケースに落とし込んで、概念モデルを作ってユースケースの不足だったり概念モデルの矛盾を検証する。
概念モデルはあくまでも概念なので、イミュータブルになるように書く。 間違っても、ここは同じテーブルに入れて~とか実装詳細に立ち入ってはいけない。 粛々と発生するイベントや作られるリソースをモデル化していく。
ここを書きながら用語がずれないように、用語集(ユビキタス言語というやつ相当)とその和英辞書も作っている。
書いてて思ったけど、具体例がないと多分何も伝わらないんじゃないかなーと思ってきた。(が、気にせず書く)
この2点を曲がりなりにも書き上げたら、雑にワイヤーフレームを書いて、ユースケースのシナリオを最低限流せるようにしておく。
初回の打ち合わせでやること
ワイヤーでどんな流れかを説明していく。
仮定で作ったユースケースを満たすためだけのワイヤーなので、構成だったり流れは代わり得る(し、自分自身もそれがベストだなんて微塵も思っていない)
重要なのは、何ができるようになって、そのためには、何をしてもらわないといけないか?ということを擦り合わせしておくということに重点を置いてる。
後はこうしたい、ああしたいを議論したり、場合によっては持ち帰る。
立ち上げ時は分からないことの方が圧倒的に多かったり、企画した人たちもモヤモヤ~と思ってるだけだったりするので、議論して思考が整理されると、企画がブラッシュアップされたりする。
こんな感じのことをやって、
- ユースケース図
- 概念モデル
をブラッシュアップしていき、合わせてワイヤーも直していく感じ。
ここまでに同時にやっておくこと
- 開発環境を作って配れるようにしておく
最近はVagrant上にDockerを乗せて動かすことが多くなってる。
(ほんとはVagrant要らないと思ってるが。。。以前のサービスの開発環境との都合でHost型VMを捨てれない)
Vagrant上へのデプロイはSFTPを準同期(といってもほとんどリアルタイムだが)で行って、DockerからはVolumeマウントでそこを見てもらって動かすようにしている。
この辺は自分にとってはほぼ定型作業なので、以前の遺産を使いながら一寸ずつブラッシュアップするフェーズになってる。
ドキュメント作りは疲れるので、ちょうど良い気分転換にもなったりする。
開発するための設計をする
これ以上やってもしょうがないと思う程度に、消化できたらDB設計をする。 これのインプット資料は概念モデルになる。
概念モデルはイミュータブルに書かれているので、これを非正規化するところは非正規化して、 物理名も全部振る。
DB設計も最近はCacoo使ってやっている。
(ほんとはObject Browserでやりたいんだけど・・・料金が・・・)
そんなこんななので、型とかは入れないw
Cacooに一通り記入したら、DataGripを使ってスキーマを一気に構築してしまう。
自分以外の開発者へは、DataGripから吐き出したDDLを渡して実行してもらうスタイル。
用語集に出てくる単語については、バリューオブジェクトも一緒に作ってしまう。
自分の債務の捉え方としては、DB設計するなら、
- マイグレーションファイルは自分で用意しろ
- 値オブジェクトの柄だけでも用意しろ(required/min/max/dateかとかくらいまで)
- Eloquentのモデルは自分で作れ
です。
最後のは完全にFW依存してるけど、リレーションとか書くとER図を間違えてたことに気づいたりするので割とおススメ。
DB設計と言いつつ、結構コードも書いている。(時間が足らなくてギブアップすることもあるので、そのときは開発者よろしく~をする)
設計書に話を戻すと、必須で作るのはアクション一覧(URLとHTTP Method込み)くらい。
オフショアを使う箇所は、プログラム設計書相当のかなり詳細なモノを書いて出す。
プログラム設計書相当のものには以下を記載している。
- ラベルに表示する文字の取得元(言語ファイルからなら、そのキーもすべて指定する)
- 入力フィールドの名前とか入力ルールとか(クライアントサイドバリデーションについては、値オブジェクトとかは作れてないので)
- バックエンドのDB更新順序とか画面のどの項目がテーブル上のどこに入って欲しいとか(名前は和英辞典で付けるからほぼ一致するんだけど)
- 正常・異常時におけるそれぞれの通知メッセージはどこから取って表示すれば良いとか
そんなようなことを書く。
ここまで書かないと失敗が約束されてるので、書いている・・・。
ちなみにここまで書いても、2割くらいはおかしなコードが出てくるので、そこはメンドクサイから巻き取る感じになる。
開発する
みんな(大概自分 + オフショア)で開発する
同じオフィスの人ともシステム作りたいです、はい。
自分もコードをガツガツ書くけど、その合間にオフショアのプルリクのレビューしたり、
CI/CDを整備したりしていく。
ちなみにオフショアのレビューが一番しんどい。
体力的にも精神的にしんどい。ほんとしんどいです。
ステージングの実行環境はAWS上にインフラチームが必要なものを伝えておけば用意してくれるので自分のやるところは、
Blue/Greenデプロイの設定と、用意してもらったサービスの統合となる。
使ったことのないサービスを使う場合は、インフラチームと協力して検証も同時に行う。
なお、この間もコードはガツガツ書いている。
ちなみに作ってる最中も、想定外だったり思考の抜け漏れ、プラットフォームの理解不足でやり方が正攻法じゃないっぽい・・みたいなのは当然出てくるので、軌道修正したり、企画の意見も聞かないと分からん、みたいなところは都度判断してどうしていくかを決めていく。
画面にデザインを当ててもらう
会社にマークアップエンジニアがいるので、デザインをきれいにしてもらう。
ここは完全ノータッチ。
画面のロジック壊されなければ何でもOK。
終わったら動作確認してリリースへ。
リリース
開発中からステージングでCDを作りこんでいくので、本番設定を見るようにしてリリースするだけである。
非常にお手軽な感じになっている。
監視設定はインフラチームに丸投げしてしまっているので、ここは何かソフトレベルでも寄与したいとは思ってるけど、
現状そこまで手が回らない。
という課題。
リリースしたらお疲れさまでした。とはならないのがSaaS業者です。
終わりに
完全なるポエムになったwww
とりあえずユースケースと概念モデルを作って、作るものをみんなで知ることから始めると良いと思うし、
それを心掛けて生きてます。
開発とかめちゃくちゃしてるように映ったかもしれないけど、
私はほぼ定時帰宅民です。