UI開発するときは機能名だけでなく、各部品に名前をつけた方がいいなと思うようになった。 とにかく部品に名前をつける。汎用的ではなく、一意に意味がとれる名前にする。
例えばクリックすると記事が追加できるボタンなら「記事追加ボタン」とか。リソースを削除する場合は「〇〇削除ボタン」といった具合に無理矢理名前をつける。
フロントエンド領域でドキュメントを書きたくない理由の一つに、UIの変更にドキュメントを追従させる手間がかかる、というのがあると思う。ワイヤーフレームや画面キャプチャに①：〇〇するなど書いてしまうと、ちょっとした修正で要素の配置がずれるとドキュメントの意味がなくなってしまう。ドキュメントをメンテナンスする工数が高すぎる。
仕様を知らない状態で入ってきた人が知りたいのは、「このボタンはいつクリックできるのだろう」とか「このフォームには何が入力できるのだろう？バリデーションチェックは？」という内容。UIは変わるものとわかっているし、開発環境でアプリを確認すればそれが最新であるとわかる。つまり、欲しいドキュメントは見た目に関するものではない。部品の挙動に関する内容を文章化しておいて欲しい。
挙動だけであれば文章でも書けるはず。心配なら機能追加時のissueやPull Requestにスクリーンショットを貼っておけば良い。で、文章でドキュメントを完結させるには部品名が必要となる。画面全ての項目に名前をつけておき、ドキュメント、チケット、ステークホルダーのやりとり…全ての領域でその名前を使う。そうすれば人が変わってもある程度項目と挙動が一致する状態にできる。
部品は画面（機能）名 + 動作という命名でつけることが多い。フォームであれば入力項目内容 + フォームとしている。名前が付けられない部品はそもそも存在意義が怪しいので本当に必要か見直すきっかけになる。役割がない部品はユーザーに見せる必要はないし、ただメンテナンスコストがかかるだけである。使用上必要だけど名前が付けられない場合、自分の機能に対する理解が不足している。そのような場合は作ろうとしている機能の仕様を再確認した方が良い。
名前をつける = 部品の役割の設計と同義だよなあー。
