アジャイル時代のモデリングで、すでにコードがある場合の維持モデル作りの第一歩として、ソースコード中の単語頻度分析と用語辞書作りをやるといいと教えてもらったので実際にやってみる
- 分析ツール作った https://github.com/nishio/wordfreq
- Regroup に適用して、予約語などを捨てたもの
- 上から順に、プロジェクトのことを何も知らない人が「これなんですか？」って言った想定で解説していく
- item
- よくない名前
- キャンバス上に表示されてるものをPaperItem、それのビューと切り離されたモデルをStateItemと呼んでる
- state
- Reactを見様見真似で使い始めたときだったので、Reactの文脈でのStateに関するものがこれで呼ばれてる
- それってMVCでいうところのモデルにmodelって名前をつけてるような状態なのでよくない
- 「これがシリアライズされてサーバに保存される」と当初は考えていたが、実際には時間のかかる計算結果のキャッシュなども入ってる
- paper
- いわゆるキャンバス
- HTML5的な文脈でのcanvasエレメント
- ラッパーライブラリとしてPaper.jsを使っているのでその名前を引きずってる
- path
- キャンバスに書かれた手書きの線
- group
- 複数のitemをまとめたもの
- piece
- 付箋、四角い箱に文字が入ったもの
- 当初は文字だけだったが、今はその文字列が特定のパターンの時には画像として表示してる
- 画像付箋とテキスト付箋は概念として別れるべきだと思う
- stroke
- pathの線のスタイル、strokeWidth, strokeColor, strokeOpacityなどの形で使われる
- point
- 二次元ベクトル
- キャンバス上の一点
- position
- itemのキャンバス上での位置
- center
- キャンバスの視野(ビューポート)の中心
- 無限に広いキャンバスの一部を表示してるモデルになってる
- zoom
- ビューポートのズーム割合
- centerとの組み合わせで無限に広いキャンバスのどの範囲を描画するかが決まる
- tool
- ユーザのモード
- ペン描画モード=drawingTool
- Paper.jsのアーキテクチャに従って作ったが、良くない分割方法だと考えて修正しつつある
- items
- プロジェクトもしくはグループが持っている複数のitem
- update
- stateの更新
- width
- 幅
- mouse
- マウス
- app
- このプログラムのブラウザ上での一つのタブに一つ存在するシングルトンインスタンス
- lasso
- 投げ縄
- キャンバス上のアイテムを囲って選択するのに使うツール
- canvas
- キャンバス
- color
- 色
- 今のところ色を変えられるのはパスだけだが、付箋の色を変えたくなるかも
- open
- ダイアログを開いたり、付箋のリンク先を別のタブで開いたり
- target
- 主にマウスイベントの対象になっているitem
- menu
- メニュー
- 上にメニューバーとして出てるやつ、3点ボタンから出すメニュー、キャンバス上に出るバルーンメニュー、がある
- add
- 追加
- text
- 付箋に書かれている文字列
- view
- ビューポート
- root
- グループの子ではない、キャンバスに直接置かれているアイテムのことをrootItemと読んでいる
- canvasで描画されてるのでDOMのイベント伝搬的なやつがないので、自前でPaperItemの包含関係をたどってrootItemを特定している
- style
- スタイル。itemの場合もDOMの場合もある
- create
- 作る、主にItemを。
- click
- クリック
- height
- 高さ
- drag
- ドラッグ
- line
- 行、付箋テキストが複数行になる時の、そのそれぞれの行
- 線、スタイル変更ダイアログの中でパスの太さなどを表現している直線状のボタンがlineButtonと呼ばれてる
- down
- マウスダウンイベントのこと
- dialog
- ダイアログ
- url
- 外部リンク付箋が持ってる属性
- balloon
- バルーンメニュー
- parent
- アイテムの持っている属性で、自分の親を指している
- image
- 画像
- selected
- アイテムが選択されていること
- old
- 更新されるアイテムの、更新前の状態
- scale
- アイテム、特に画像付箋を拡大縮小をする場合の倍率
- ビューポートの倍率はzoomと呼ばれてるので別物
- top
- PaperItemの上端
- left
- PaperItemの左辺
- info
- local_infoの形で、stateの中のクラウド保存されない情報
- スタイル変更ダイアログの中で、ボタンが持っている「どういうスタイルに変更すべきか」という情報
- buffer
- 文字を書いている最中に全体の再描画が走ると良くないので一時的にバッファに溜めている、そのバッファ
- project
- Paper.jsの用語、1つのcanvasエレメントに1つ対応する。このアプリには3つある。
- last
- 最後の
- ghost
- アイテムのドラッグ中に全体再描画をするとカクツクので、代わりに表示される半透明オブジェクト
- opacity
- 透明度
- dash
- パスの点線
- present
- 現在のstate
- undo
- 取り消し
- start
- マウスイベントにおいて、マウスダウン時とドラッグ時にそれぞれ処理をしなければならない場合のマウスダウン時の処理、startMoveItemなど
- また、マウスダウンの位置 dragStartPoint
- initial
- 初期値
- points
- パスの各点
- button
- ボタン
- change
- スタイルの変更
- サーバ上での変更
- react
- React
- close
- ダイアログを閉じる
- title
- 付箋のtextにリンクなどの記法を持たせたことで「実際に表示する文字列」が必要になった、その値
- item
やってみた感想
- 説明してみて「いや、二通りの意味があるな…」みたいになることがある
- 今回あえて全部説明したけどlastとかは説明しなくて良い気がする、形容詞なので特定のエンティティではないし、特殊な使い方をしてるわけでもないので、単なる英語の意味になってる
- 動作のcloseもそうだが、こちらは「openが二通りの意味に使われてるな」という気づきはあった
- 実際のコードでは文脈で区別できるだろうけど
- 「これ何かな？」という単語はプロジェクト内で検索して観察することで「なるほどこういう使われ方をしてるのか」ってなる。lineはまさにそうだった。
- もはやいじることがレアになってるので、新メンバーに説明する時に「プロジェクトはキャンバスと1:1対応、アプリに3つある」って説明するのを忘れそうだと思った
- それに気づかせてくれる効果があった
- とここまでの話を踏まえて(インポートして)少し整理してみた
- 感想
- 単語としての出現頻度が高いところからやったので、コード上の実装ボリュームや、影響範囲の広い概念がピックアップされてる
- 出現頻度基準なので例えばtoolにはlassoの他にもdrawingがあるのだが、それは出ていない
- ソースコードを解析してすべてのグラフを出したりすると、過剰に詳細になる
- そういう図解は少しコードをいじっただけで「正しくない図」になる
- 出現頻度の高い概念はそれに修正を加えるとコードの影響範囲が広い
- なので「おいそれと修正できない」
- その結果、変わる速度がゆっくりになる
- だから出現頻度の高い概念だけを図解したものは寿命が長くなる
- 網羅的でないことが重要なのだな
- 単語をエンティティとしているので、クラス的なもの(item)、インスタンスなもの(app)、属性なもの(selected)が混ざっている
- 整理せずに隅に置いてる動詞とかは、リレーションになるのかも
- これはおかしなことではなくて、ER図はソースコードの一部の側面だけを抜き出して描くものなので、ソースコード全体の頻出単語がここに書かれるべきものとは限らない
- ものによってはシーケンス図に書くとか
