日々常々

ふつうのプログラマがあたりまえにしたいこと。

モデリングの二つのモード

モデリングには二つのモードがあるかなって。

一つは捨てる、もう一つは選ぶ。落書きするとこんな感じ。

f:id:irof:20200815220115p:plain

丸はなんか大事な要素。黄色はその中でも自身が大事だと思っている要素。

捨てる(削ぎ落とし、削り出し)は削ぎ落としたときに段階で落とすものがある。 削り出しでは損なう物は少ない。 出来上がった物の中に大事な要素は埋もれてる感じで、自分が思っていない大事な要素が残ってたりする。 贅肉が多く、大事な要素は見る側が識別しないといけない。

選ぶだと自分の認識しているもの以外はそもそも入らない。 そのあと繋ぐ必要があるのだけれど、繋ぎ方は元々の対象領域にあったものではない、後付けになる。 場合によっては変な繋ぎ方をしてしまう(いつもじゃないけど)。 大事な要素が剥き出しで目立ちやすいが、繋がりは本当に繋がるかわからない。

どちらがいい、とかは別にないけれど、向き不向きはあるかな。 ドキュメントやセミナーなど焦点を絞ったものは後者がいいかなと思う。 一方、コミュニティのセッションとかは前者の方がその人ならではのものが見出せていいかなって。

私は前者の作り方することが多い。 特に失敗談を含めた経験や検討経緯を自分が聞きたいから、自分のセッションはそう言う方向に向けてたりする。 後者の後付けされた接続の綺麗さが、物によっては舗装された一本道に見えるものもある。

f:id:irof:20200815215754p:plain

こう言うのは違うでしょって。あらかじめ全てを見通してたかのような、そんなのは参考にしづらいし、役立てるのも難しく感じてしまう。 やってもない大きな蛇行よりはマシだろうけど。

無駄なところも含んでいるけれど自分が重視していない部分も入って示唆に富む方法と、ポイントが強調されて力強く伝わりやすい方法。 どっちでやろうかって意識してると、なんかやりやすくなった。

ちなみにこのブログは選ぶ方で書いてます。なのに冗長?それはきっと後付けされた接続がうねってるんですよ……。

モデリングをはじめるまでの道筋

自分の描いたものが伝わりやすいかどうかとか、正直よくわかりません。 直接「わかりやすい」とか言ってもらっても、社交辞令かなーとどうしても思ってしまいます。 思ってしまうのは仕方ないし、でも社交辞令と決めつけるのも失礼だよなーと思ったりもしつつ。

それはそれとして、「どうやったら描けるようになるのか」みたいな話をちょいちょいされます。 そんな会話を集めてセッションにしたものが モデリングのきほん です。 ただこのセッションは半年前の私のスナップショットで、道筋は無い。なので改めて描いてみました。

f:id:irof:20200812233051j:plain

出発点は「わかりやすい」「わかりにくい」とか感じるところです。 この感覚を持てるかどうかで、モデリングの向き不向きがちょっとわかるんじゃないかなと。 たまにどのような表現物であっても咀嚼できてしまう方がいて、そう言う方はおそらく「わかりやすい表現」を作り出すのは難しいんじゃないかなって。 できるとしてもこことは違う道筋を辿りそう。

二段目は「そうだよ、これだよ!」みたいな合致を経験することです。 これを感じるような方は、曖昧ながらも脳内に自身の理解モデルが構築できています。 なればこそ「 これ が欲し かった 」と言う、代名詞と過去形の言葉が出るのです。 見たことがない物を思い描けるかが焦点で、かなり重要な段階。

三段目は改善系か深堀系の二パターンくらい思いつきました。

改善系は自分の理想とする形とのギャップが観測できています。二段目からの正当進化ですね。そこから自分が思い描くものをアウトプットするのはよくあるパターンでしょう。ただ既にあるものに疑問を抱かない素直な方もいらっしゃるので、万人が踏む段でもないと思います。

深堀系は個々の要素の意図に目が向きます。この矢印の方向の意味は?なんでこの場所に配置されてるんだろう?色は一体?とか。そのうちにパーツの使い方がわかり、描いてみる下地ができます。文房具を手にするような物ですね。

四段目はいよいよ書き始めます。 自分の理解の補助のための書き始め。ドッグフーディングですね。チラシの裏でもなんでも良いです。 「描けない」って言ってる方でも、何気に多くはこの段階なんじゃないかなーと思ったりします。見せてくれないので観測できないですけど。 これやってて「描けない」とか言ってる人はとっとと五段目に進んで欲しいところ。

ここでダークサイドというか、左側に流れるとオレオレモデルしかかかなくなったりします。 なんのルールもなく感性で描かれたもので、見させてもらうと強烈なインパクトはあります。なお見方は全くわからないから誤読しまくる。 これはこれでいいと思ったりもする。もしかしたら私はここかもしれない。ってか先の図とか完全にオレオレモデルだし。

五段目は描いた物を使っての人への説明です。 相手の反応やその後の行動を観測できてナンボ。 説明を意識するだけでも表現する対象の焦点が合ってきます。 また、ここの量は質に転化させやすいです。どんどん人に話してみましょう。ブログとかでもいい(実践なう)。

蛇足ですが、なんか派生で「他人が描いた物を使って説明する」ってのがある気がしました。 他人のスライドでセッションするって遊びをしたことあるんですが、あれはあれでいい訓練だったなぁ。

そして六段目、意図を込めるです。 三段目の個々の表現に目が向く視点が必要ですが、使用する(もしくは使用しない)表現を意図的に選択します。 ぼんやりして描いたものより、意図した物の方が伝わりやすいのは間違いないです。

このくらいまで来たら 完全にマスターした ってあたりかなと思います。 先にまだまだ道は続くので「はじめるまでの道筋」としています。

あとは素直にモデリングを勉強するか、場数踏むんでの強化かなって。 「できるようになりたい」の「できる」ってなんだろうとかをモデリングしてみるのもいいと思う。 たぶん案外描けないので、きっと面白い。これを面白いと思えるかも一つの試金石かな。

締め: これを書いた意図

「全然できるようならない」って話を耳に挟んだり相談されたりたまにします。 できるようになるまでの道筋が見えたら、取り組みやすいかなーって思いました。

できる/できないの言葉を使うとbooleanかのような印象を受けますが、実際は継ぎ目のない連続した状態変化です。決して真偽値ではない。評価基準を設ければその限りではないけれど。 ここで示した段階もミスリードを誘いますが、段を設けることで言葉での表現ができ、識別可能になる方を優先しました。

直接相談された時とかはここで挙げた一、二段目を指して「できてるやん」みたいなことを言うんですが、どうも下手な慰めにしか聞こえていない感じで。 ややもすれば「馬鹿にしてんの?」とか思われてるかもしれない。そんなつもりはないんだ……。 なので自己確認と説明用に描きました。突発的な会話でこれ伝えるのはだいぶ厳しそうだと再確認できた。

ともかく、最初からできることなんてないと思うんです。である以上、道筋や段階はあるはず。 あるに違いない、こんな感じじゃないかな、って描いたのがこの図と文なわけですね。

私は小心者なので、人に晒すのは想像するだけでも怖かったりします。この記事もおっかなびっくり書いてます。 でも「描けるようになる」にはアウトプットは欠かせないので仕方ない。 できるようになりたいことは、日常的にやる。 やり続けてふつうのことにできたら、ようやく「できるようになった」と言える。そんなふうに思ってます。

蛇足

なお私のモデリング、と言うかダイアグラミング(造語。特に描くモデリングを指す。私の中では箇条書きとかもモデリングなので。)は、文章や口頭説明などと併せて参照する前提で構成しています。コンテキスト無しで理解できるようには描いてないので、絵だけじゃ雰囲気くらいしか伝わらないんじゃないかなーっていつも思ってる。

あと、モデリングで捨てるのが大事って話はありますが、あれはあくまで手段です。伝えたいことが際立てばなんでもOK。捨てるのは万能なんでゴールデンハンマー的に振り回しても問題ないですが。

f:id:irof:20200813005545p:plain f:id:irof:20200813005605p:plain

対象ツイート

f:id:irof:20200813004826p:plain

対象ツイート

リファクタリングに関する何か

リファクタリングの話をするとき、焦点が合ってないなーと感じることがたまにあるのでざっくり描いてみた。

f:id:irof:20200811115944p:plain

自分のために描いたものなので、なんか違うなーって思ったらご自身で描いてみるといいと思います。レッツモデリング

破線は依存、実線は変換。長方形は名前などで明確に識別可能なもの、角丸は様々なものを包含する活動。雲は思いです。

描いた時の経緯と言うか

f:id:irof:20200809211246p:plain

該当ツイート: リファクタリングって常時やるものなんですよね。もちろん「よーしやるぞー」って感じで行うものもあるんですけど、それは深呼吸的な。

とは言え。やったことがない、やってはいけない文化(動いているコードに触ってはいけない)に染められてしまっている、そのような方に「無意識にやれ!」と言っても、何の意味もないので言いません。むしろ害悪ですらある。

f:id:irof:20200809211308p:plain

該当ツイート: 無意識にやるようになって、ようやく「リファクタリング」がカタログ化される前の「偉大な習慣」に入門したあたりになると思ったり。 習慣にするまでは意識してやると思うんですが、習慣になったら意識しなくなるかなって。そんな感じ。

ポイント

偉大な習慣が「リファクタリング(活動)」で、しっかり定義されていないふわっとしたものなので角丸で示してます。 その中から言葉をつけてカタログ化された「リファクタリング(テクニック)」が提供する焦点はいくつかあって。

  • 名前付けによる識別
  • コードの不吉な臭いに依存する、正当化による後押し
    • これがあるおかげで「何となくキモチワルイ」を変えて良くなります
  • 外的振る舞いを守る検証方法に依存する、手順
    • これがあるおかげで「変えても大丈夫」って言えるようになります

で、リファクタリングでたまに微妙な方に行くのが「検証方法」の焦点が合ってないところ。 「外部的振る舞い」ってなんやねんってやつですね。

書籍「リファクタリング」では堅実なテストは事前条件とされています。そして自動テスト前提で書かれています。

これはもちろん(定義者が言っているからって理由を抜いても)正しいのですが、かといって「自動テストがないものはリファクタリングと呼ばない」と強固に主張したところで、それはそれで重要な場面もあるんですが、多くの場面では意味のない話です。「じゃあリストラクチャリング(もしくは他の何かしらの造語)でいいです」とか言葉を変えることにあまり意味はないですし。

と言う事で、検証方法にいろんなパターンがあるとしています。「コンパイルエラーにならない」が保てている限り安全と断言できる変更はあるわけですから。 私が重視するのは「このリファクタリングではこの検証方法を使っている」が示せる事です。 その検証方法の精度は二の次。まずはそれを識別できていること。 識別できさえすれば、その検証方法の妥当性は考えられますし、精度をあげることもできます。 検証方法が思い至らないのであれば、それは流石にリファクタリングじゃないかなって。

まとめと参考書籍(2020-08-10T12:00 追記)

リファクタリングに取り組むと「外部的振る舞い」の扱いに悩むかと思います。 自動テストがあると言っても、それで十分に保つべき外部的振る舞いが検証できてるか確信が持てないこともあるでしょう。

「この外部的振る舞いを保たねばならない」と言う唯一絶対の正解はありません。 重要なのは 保つべきものを見極め、それを検証できる形にしてから取り組むこと です。 これを保てるならば変更していい。そう言う拠り所を作れば、コードをみたときに感じるモヤモヤ(図の気になること)に向き合えます。 リファクタリングは「なんか気になる」などの感情を押し殺さず、むしろこの感性を育み、良いコードを書けるようになる最短ルートだと思っています。

コードの変更は多くのところに波及します。影響を及ぼさないように設計していれば、簡単な検証で賄えるかもしれません。 安定依存の法則に従ったモジュール設計を行っていればより達成しやすくなります。この辺りの話はClean Architectureが参考になります。

(同心円な図がよく挙げられる本ですが、本書の主眼はあの図ではありません。他のCleanシリーズと同様、考え方の本です。)

様々な責務が複雑に絡み合っていれば、包括的で堅牢な自動テストがないと厳しいかもしれません。 そう言うときは、レガシーコード改善ガイドが参考になると思います。

リファクタリングは誰かの許可を貰ってやる物ではありません。できる裏付けを自身で構築してから取り組む物です。 自分で「変えても大丈夫」と言えず、なぜコードを変えられようか。

あと言っておきたいこと

f:id:irof:20200809222051p:plain

該当ツイート: 日常的にやっているからこそ、重要なときにもできるんです。緊急時の規律。

システムの根幹をリファクタリングしたければ、呼吸のようにリファクタリングするようになっておきましょう。 素振りの習慣もないのにいきなりフルスイングしても、色々壊すんですよ。打ちっぱなしでゴルフクラブすっぽ抜けて思いっきり投げた私が言うんだから間違いない。(ちなみに小学生の頃。いまだにトラウマ。)

あ、呼吸のようにやるようになると、コミットに紛れ込みやすくなります。細かくコミットする習慣とどちらが勝るかの勝負になってきます。これどっちがいいとかも文脈依存で、どこに価値を見出すかと言う話です。これはこれでいつか掘り下げたい。