シーケンス図を書くとよい理由

要約

  • rubyは型チェックがないスクリプト言語
  • 引数になにをとるか、なにを返すかはメソッド名で表現するしかない

シーケンス図とは

こういう図です。 書き方はシーケンス図でググればたくさん出てきますが、なぜ書くといいかの個人的な意見を書きたいと思います。 図とかドキュメントの話になると、すべての実装項目やリポジトリ全体のものを作るという話と思う人もいるかも知れませんが、それはおすすめできません。(メンテできなくて実装とかけ離れたものになるので意味がない) ひとつの機能を実装するとき、小さい範囲で書いて、githubのプルリクとかissueに貼っておくといいです。その理由は

なぜ書くとよいか

  1. 自分の理解が進む
  2. 設計がブラッシュアップされる
  3. ドキュメントとして自分以外が見ても理解しやすい

自分の理解が進む

主に実装中に全体を俯瞰して見たいときに役立ちます。オブジェクト指向の特徴は抽象化なので、突き詰めればどんどんクラスが増えて抽象的になっていきます。全体としてどういうクラスがあったか、その間のメッセージ(メソッド)のやりとりはどうだったか、というのが自分が作ったものでもわからなくなってきます。 そういうときにシーケンス図があると、全体の地図として機能して、自分の頭のメモリーを全体像のリロードにとられることなく、目の前のコーディングに集中できます。

設計がブラッシュアップされる

一度作り始めると実装中は細かいことに目が行きがちで、最終的に出来上がってみると、「あれ、このクラスあったほうがきれいに書けたんじゃないか」ってことがよくあります。 全体の登場人物が足りてるか、その間のメッセージのやりとりであるメソッド名はそれで適切か(single responsibilityになっているか)、というのは作り始めちゃうと途中で軌道修正するのが結構大変になります。 そんなときにあらかじめシーケンス図でやりとりを書いてみると、実装の一番ライトなプロトタイプとして機能して、コードを書く前から(コードを書いてないので超ローコストで)リファクタリングができます。

ドキュメントとして自分以外が見ても理解しやすい

抽象化が進むと、人が書いたコードをひと目見ただけではわかりにくくなってきます。これはオブジェクト指向のウィークポイントなのかもしれませんが、それは置いておいて、そこを補うドキュメントとして見た上でソースコードを読むと理解度がぜんぜん違うと思います。 githubのプルリクを見返したときに、作者がシーケンス図とか貼ってあるともう感動的だと思うので、やるといいと思います。

参考

オブジェクト指向設計実践ガイド ~Rubyでわかる 進化しつづける柔軟なアプリケーションの育て方 この本の中でもシーケンス図のよさが語られてて参考になります。