はじめまして、飯沼です。
社内ツールの開発を行う部署に所属しています。
チームに合流するときにまず、業務理解、システムの現状把握をしますが ソースコードを読んでも理解できないとき、役立ったことを紹介したいと思います。
- UMLなどのモデリングでモデルの関係性と構造を理解する
- ユビキタス言語(用語集)でチーム内の共通認識を作る
UML、モデリングについてツールのインストール、使い方の例は、 前回のE野氏のわかりやすい記事がありますのでこちらをどうぞ。
記事中に、E野氏がおっしゃっています。
設計書が無い。
(コードが全てじゃ
はい。
私はチームに入ったとき、
- 開発途中からチームに加わった(現状把握が必要)
- 業務知識が足りていない(業務理解が必要)
- 慣れない開発環境(初めて触れる技術)
という状況でした。
ですがソースコードをみればなんとなくわかるだろうと思っていました。
コードを見て、
なるほど
なるほど
わからん。
これをループしてました。
プロジェクトに参加して気づいたことです。
私はコードを見ただけで仕様を理解できる人間ではなかった。
こりゃやばい
モデリングで関係性と構造を理解する
そこで、現状のプログラムの構成を理解するためモデリング(UML)してみることにしました。
始めるにあたり課題がありました。
- UMLの学習コスト
- UML描画のツールが高価、使いづらい(と思っていた)
- 見せる相手もUMLを理解している必要がある
過去、設計時にUMLを書いた経験はあります。(良い思い出はない)
ツールは検索してPlantUMLがすぐに見つかりました。(簡単に使えました)
チームは学習意欲が高いメンバーばかりなのでUMLを理解してくれる。(のはず)
ということで早速やってみました。
- クラス図を作ることで、システム内の登場人物の相関がわかる
- シーケンス図から、プログラムの流れがわかるようになる
- ユースケース図から、そのシステムに関わる人、システムで解決する課題が見えてくる
これらがやってみてわかったことです。
ソースコードからは見えなかったものが、
モデリングすることで見えるようになりました。
UMLを書くときのコツとして、 目的は仕様の理解とメンバーとのコミュニケーションとしてのツールと考え あまりUMLの形式にこだわらないようにしています。
一つの図の中に書き込みすぎない。 あれもこれも書きたくなるのですが、一枚の図に目的を1つにしぼるのがいいと思います。 クラス図の関連なんか書きすぎるとスパゲティになります。
今は新規機能開発やリファクタリング時にも活用しています。
ちなみに私は、Atom + PlantUML + MacOS でモデリングをしていました。
その後インフラチームが gitlab 上でも PlantUML を使えるように設定してくれまして ブラウザ上でUMLを埋め込めるようになりました。 マジリクのコメントなんかにシーケンス図を差し込むことが気軽にできるようになりました。 インフラチームすげー、オープンソースすげー、です。
ユビキタス言語(システムの用語集として)
業務知識が不足している解決策として、ユビキタス言語は有効だと思います。
ユビキタス言語とは、
Eric Evansが『Domain Driven Design』において、開発者とユーザーとの間で共通の厳格な意味を持つ用語を構築するというプラクティスを表すために使用した用語である。ユビキタス言語はソフトウェアにおけるドメインモデルに基づいている。ソフトウェアは曖昧さをうまく扱うことができないため、厳格さが必要となるのである。
ユビキタス言語とは、チームで共有する言語のことで、 プロジェクトチーム全体で、一つの言語を共有するツールになります。
例えば、次のように用語が登録されていたとします。
用語 | システム名称 | 概要 |
---|---|---|
ダック | duck | あひる。水鳥のカモ科のマガモのこと。このシステムではワンとなく。 |
これがあると、チーム内の会話の中で “ダック” という用語が出てきたときに、 ワンとなくあひるのことだなとイメージできます。
システム名称というのはプログラムでそのまま使われる言葉で、duckというクラスを見たら同様に それが何を指してどのような振る舞いをするのかが予測できるようになります。
クラス図を見たときも、クラス名からそれが何を指すのかイメージでき、 関連するクラスもわかりやすくなります。
言葉は抽象化された表現です。 1つの用語でも具体的なところまで意味を持たせると チーム内のコミュニケーションがはかどります。
ユビキタス言語を厳密に作ろうと思うとチームの協力が必要ですが、 まずは個人で用語集を作ってみるのがいいかもしれません。
詰まったら抽象で捉えてみる
サービスやシステム開発は、解決したい課題(抽象)から 何を使ってどう解決するか(具体)に落としていくのですが、 今回はシステムを理解するために具象(ソースコード)から 抽象(モデリングやユースケース)に視点を上げる作業をしました。
このように抽象と具象の視点を切り替えることで視界が広がり わからなかったことがわかるようになる というのを理解できた経験でした。
何か問題にぶつかった時、視点を変え抽象度を上げて捉えてみると 問題解決のヒントがひらめくかもしれません。
まとめ
モデリングやユビキタス言語を使うと、業務理解、システムの現状把握を することに役立ちましたという話をさせていただきました。
何かのお役に立てば幸いです。