コード日進月歩

しんくうの技術的な小話、メモ、つれづれ、など

GitHubが管理する.gitignoreのテンプレート集リポジトリが存在する

小ネタ。

該当ページ

github/gitignore: A collection of useful .gitignore templates

何があるのか

メインはプログラミング言語やプログラミングフレームワークに向けたgitignoreのファイルとなるが、JetBrainやMonoDevelopなどIDE向けのgitignoreに関しても置いてある。

READMEに詳しく書いてあるが公式情報などをPRで提示してマージしていくような運用になっている様子

関連ページ

RubyのCSVクラスを使ってTSVを読み込む場合にダブルコーテーションの入っているものがあるときの対策

パースエラーになる、のでワークアラウンド的な対策

環境

$ ruby -v
ruby 3.0.1p64 (2021-04-05 revision 0fb782ee38) [x86_64-darwin19]

やりたいこと

正常に変換できるケース

例えば以下のような test1.tsv があるとする(タブはHTMLの表現上うまく出ないので雰囲気だけ)

id    name    text
1   taro    sample text
2   ziro    hello!
3   saburo  cry

この場合に以下のようにすれば読み取れる

require "csv"
result1 = CSV.read("test1.tsv", col_sep: "\t", headers: true)
result1[1]["text"]
# => "hello!"

異常がおきるケース

例えば以下のような test2.tsv の場合は、ダブルコーテーションが入っている要素があるのでパースできない。

id    name    text
1   taro    sample text
2   ziro    say "hello"
3   saburo  cry

この場合、パースエラーが出てデータが取れない

require "csv"
result2 = CSV.read("test2.tsv", col_sep: "\t", headers: true)
# /Users/hogehoge/.anyenv/envs/rbenv/versions/3.0.1/lib/ruby/3.0.0/csv/parser.rb:925:in `parse_quotable_robust': Illegal quoting in line 3. (CSV::MalformedCSVError)

回避策

エラーとしてはもともとのCSVとしての仕様として " で各要素を囲むことに対する仕様があるため、そちらとの兼ね合いで正確にパースができず失敗してしまう。

そのため、この厳密さを回避するオプションである liberal_parsing: true とパース自体はすることができる。

result2_ex = CSV.read("test2.tsv", col_sep: "\t", headers: true,liberal_parsing: true )
result2_ex[1]["text"]
# => "say \"hello\""

関連リンク

DOMそのものが備えるプロパティやメソッドの調べかた

いわゆる普通のプログラミングにおけるクラスメソッド、インスタンスメソッド、プロパティにあたるものを調べたいときにどうやって調べるのかさらっとまとめmした。

前提

DOMのメソッドとプロパティはInterfeceで決まる。

DOMが備えるメソッドやプロパティはInterface(Data type)によって決まる。

例えばよく使う documentHTMLDocument Interfaceを備えたDOM、bodyなどにぶら下がる <div> タグのDOMは HTMLDivElement Interfaceを備えたDOMとなる。

Interfaceは継承できる。

またこのInterfaceは単一継承ができる関係にあるため、親にあたるInterfaceのメソッドやプロパティを引き継ぐ。前例の HTMLDivElementElement を継承し、ElementNode を継承し…という形で継承し、HTMLDivElementはNodeのメソッドやプロパティを備える。

なおすべてのInterfaceは EventTarget Interfaceを継承するので、そこから分岐する形で継承する関係にある。

調べ方

調べ方はシンプルで以下の通り

  1. 対象のDOMのInterfeceを調べる
  2. Interfece名からプロパティとメソッドの定義を調べる

対象のDOMのInterfeceを調べる

これは Object.getPrototypeOf() のstaticメソッドを使うことで調べることができる。例えばdocumentは以下のように調べることができる。

// document の直下は <html> のDOMが取得できる
Object.getPrototypeOf(document.firstElementChild)

f:id:shinkufencer:20211002231741p:plain
consoleで実行した結果

上記の様にhtmlタグに設定される HTMLHtmlElement があたる

Interfece名からプロパティとメソッドの定義を調べる

Interfeceが何のプロパティとメソッドを備えているかは WHATWGのDOMのページなどにも定義があるが、日本語文献だとMDNのページが一番わかりやすくかかれているのでMDN内で検索して確認すると調べやすい。indexとしては以下のページがある。

ドキュメントオブジェクトモデル (DOM) - Web API | MDN

参考リンク

og:imageやog:titleで設定した画像を差し替えたときにTwitterとFacebookで再度取得しなおしてもらう方法

ogp画像を公開後に差し替えた場合に、画像を能動的にリフレッシュをして貰う方法。

今回考えるシチュエーション

og:image を差し替えたときに、FacebookTwitterで差し替わった画像に切り替わらない」というシチュエーション。

SNSサイトはページ表示時に逐次og:imageの画像を取得しているわけではなく、キャッシュをしているようなのでそのキャッシュが活きてしまい、TwitterFacebook側が変わったことを検知できないからだと思われる。

能動的に再取得してもらう方法

いずれのサイトも公式では案内していないので、切り口としては「再取得を能動的にしてもらう方法」と考えると良い

Twitter

Twitterでは指定したURLがどのような表記になるかを確かめられる機能があるが、そこで再取得がされる(模様)

Card Validator | Twitter Developers

こちらを使うにはTwitterにログインしている必要がある。

Facebook

Facebookの場合は下記のシェアデバッカーを使うことで再取得をさせることができる

シェアデバッカー

上記ページにURLを入力できる欄があるので、リフレッシュをさせたいURLを入れるとデバッグという形で再取得ができる(と思われる)

ただしこのシェアデバッカーもFacebookにログインしていないと使えないのでアカウントを持っていない人は注意。

関連ページ

クライアントサイドとサーバーサイドの言語統一に関して考える

フロントエンドとバックエンドで言語を統一する、ということのメリットに関して頭で現在思い描いていたことを改めて書き出してみる。

言語統一をすると良くなるケース

開発メンバーの認知負荷を軽減したい

主にWebアプリケーション開発で見られることだが、いわゆるクライアントサイドのWebブラウザ向けの開発をし、サーバーサイドを他の言語で開発することがある。この際にクライアントサイドもサーバーサイドも同じ人もしくは同じメンバーで担当する場合がある。そうなると機能を作り上げる過程である日はクライアントサイド、あくる日はサーバーサイドの実装をすることになることになり実装する場所に応じてコーディングする言語が異なることになる。

このクライアント/サーバーで言語が異なる場合に、言語の切り替えの度に言語の記述方法に関しても頭の中で切り替えなければいけない。この際に切り替えることによる余分な時間(いわゆるコンテキストスイッチ)が発生し、結果認知負荷が増大する。

これがクライアント/サーバーで取り扱う言語が同一になると言語ごとに切り替える負担が減り、増大してしまった認知負荷を減らすことができ、本懐の実装に関してパワーをつかうことができる

ロジックを共有・流用をしたい

クライアントサイド向けに作ったロジックが、実はサーバーサイドに必要になる場面がある。例えばバリデーションのロジックなどはサーバーを介さずにクライアントサイドだけでチェックをかけて、サーバーに送られた際に改めて送られてきた値に不正がないか同じ意図のバリデーションチェックをかけることがある。このような場合にクライント/サーバーで言語が異なる場合それぞれで同じ意味を持つバリデーションを実装する必要が出てくる。

ただしこれが同一の言語の場合はモジュールとして扱ってしまえばクライアントでもサーバーでも同一のソースコードで実装ができるため、純粋に手間の削減につながる。また、部分的に流用したい場合もモジュールがきれいに分割されていればお互いの移動や共有が勘弁になる。

言語統一しても切り離せないもの

実装の考え方

サーバーサイドの実装とクライアントサイドの実装では、考える勘所が変わってくる。

  • サーバーサイドはデータベースとの接続や多重リクエストをどうさばいて行くかなども関心として出てくる場面が多い。
  • クライアントサイドはイベントをどう取り扱うかなど、UIに連動したイベント処理に関してどうやって制御するかなどに関心を寄せる場面が多い。

このようにサーバーサイドとクライアントサイドでは考え方の切り口が変わる場面が多いので、クライアントサイドでは良しとされるような処理がサーバーサイドではしっくりこないというようなものが出てくる場面もあり得る。そのためサーバー/クライントの実装を行き来する場合、それらのコンテキストスイッチは必要になると考えられる。

適用可能な場面/言語と事例

事例があるものを紹介する。

Webアプリケーション with TypeScript(JavaScript)

一番身近で考えやすいのがこのアプローチ。ただしTS/JSに関してはフロントもサーバーサイドもフレームワークの移り変わりが激しいので、その選定が難しく賞味期限が早いと考えられる。そのためサーバーサイドを他の言語にしたほうが安定して運用ができる可能性もあり、採用する際はそれらも加味してプロジェクトを進める必要が出てくると思われる。

事例

ゲームアプリ with C#

スマートフォンゲームなどでUnityを使う場合はC#を使うが、C#はサーバーサイドにおいても利用することができる。この点を応用して、クライアントもサーバーもC#で記述するという戦略をすることができる。ただしサーバーサイドC#Windowsサーバーとの親和性のほうが高いのが現状なので、サーバライセンスなどの観点でUnix/Linux系OSでのやり方と違いが出てくるのが難点。

事例

ネイティブアプリ with Dart

Flutter+DartWebサーバーも前述のC#と似たようなやり方で実装をすることができる。ただこちらは事例を見る限り、DartのWebサーバ用のライブラリの充実がまだまだという形なので、その点を作っていく必要があるのではないかと思われる。

事例

関連サイト

余談

  • Xamarin + C#サーバーもあるんじゃないかと思いきやなかったのと、すべてJavaJavaをなんかしらしてHTML+JS生成)もありそうでなかった
  • BFFとしてのKotlinという事例もあるが、あれはちょっと色合いが違いそうなので今回は割愛しました。
  • 基本的にはクライアントサイドの言語に引っ張られるので、クライアントサイドの実装言語でサーバーサイドを実現するというアプローチになる

「関心の分離」をするメリットを料理レシピを通して考える

原典の「関心の分離」の内容を基軸にして、行為そのもののメリットを見出す。

関心の分離とは

まずは関心の分離とはどういうことかを原典とされる文章を参考に見ていく。

「科学的思考の役割について(On the role of scientific thought) 」での関心の分離

関心の分離は Edsger Wybe DijkstraOn the role of scientific thought が初めて使用されたとされているため、その文章で表現している「関心の分離」はどういうことかをまず読み解く。

文章の中では関心の分離を説明するためにプログラムの話をあげている。ざっと意訳すると以下のようなことが書かれている。

一つのプログラムを作るにあたって、取り掛かるべき問題を解決するために製作を進めなければならないが、同時に効率良く動作するようにも製作しなければならない。このような取り組みの際に、ある日は問題の解決の製作を行い、また別の日で効率化の製作を行う、しかし2つの製作を同時に取り組むのは効果が得られにくいのでやることはない。このように自分の行う行動の思考を一つの側面に注意を向けて行うことを「関心の分離(the separation of concerns)」と呼ぶ。

このように関心の分離というのは、一つの取り組みでも、取り組みで行われるアクションで着目するものは変わっていく。そのような着目するものを、分けていくことを「関心の分離」として定義されている。

関心の分離をすることによるメリット

では原典における「関心の分離」がわかったところで、それを行うことのメリットに関して考えていく。

私が考える関心の分離のメリットは大きく2つあると考えている。

  • 関心のある物事(関心事)ごとに内容が整理されるのでスッキリする
  • 関心事ごとにまとめることで全体として見てたときに気づけなかった過不足に気付ける

このメリットは料理のレシピの考え方を使って説明する。

関心の分離のメリットを料理のレシピで考える

「カレーを調理する」ということを例にとって関心の分離を考える。

例えば以下のようなカレーのレシピがあったとする。(なおレシピの引用元はこちら

フライパンにサラダ油を熱し、玉ねぎはみじん切りにしてよく炒める。玉ねぎがすき通ってきたら牛豚ひき肉(250g)を加えて炒める。なす、ズッキーニ(半分)、パプリカ(半分)を準備して切り、フライパンに加えてさっと炒めたらカットトマト(缶の半分)、水を加え、中火で約5分煮込む。いったん火を止め、カレールウ(箱の半分)を割り入れてよく溶かし、再び中火で時々かき混ぜながら約5分煮込む。

料理の工程の説明としては成立しているが、この工程だけ読むと文章の途中で用意するものが出てくるので何を用意して良いのかがわからない。 そこで関心の分離をすることでもうすこしわかりやすくなる。

この文章における関心事は「材料を準備する」「調理を行う」という2つに分けて捉えることができる。そうすると以下のように分離される。

まずは材料を準備する。カレールウ(箱の半分)、牛豚ひき肉(250g)、玉ねぎ、なす、ズッキーニ半分、パプリカ半分、カットトマト缶(半分の量)、サラダ油、水を用意する。

材料を準備したら実際に作る工程にはいる。フライパンにサラダ油を熱し、玉ねぎはみじん切りにしてよく炒める。玉ねぎがすき通ってきたらひき肉を加えて炒めて、なす、ズッキーニ、パプリカを準備して切り、フライパンに加えてさっと炒めたらカットトマト、水を加え、中火で約5分煮込む。いったん火を止め、カレールウを割り入れてよく溶かし、再び中火で時々かき混ぜながら約5分煮込む。

関心事を分離したので調理工程に分量のカッコ書きがなくなりわかりやすくなった。

ここで関心事別に整理したことにより、個別の材料において分量の付記があるものとないものがあることがわかる。これはレシピの書き漏れなので書き足す必要があるので加えると以下のような文章になる。

まずは材料を準備する。カレールウ(箱の半分)、牛豚ひき肉(250g)、玉ねぎ(1.5個)、なす1本、ズッキーニ半分、パプリカ半分、カットトマト缶(半分の量)、サラダ油(大さじ1)、水(250ml)を用意する。

材料を準備したら実際に作る工程にはいる。フライパンにサラダ油を熱し、玉ねぎはみじん切りにしてよく炒める。玉ねぎがすき通ってきたらひき肉を加えて炒めて、なす、ズッキーニ、パプリカを準備して切り、フライパンに加えてさっと炒めたらカットトマト、水を加え、中火で約5分煮込む。いったん火を止め、カレールウを割り入れてよく溶かし、再び中火で時々かき混ぜながら約5分煮込む。

これで材料はすべてわかり、調理工程もわかりやすく分離された。ただ調理工程が炒め始めてからまた材料を切るような工程となっているので、とても複雑な状態になっている。そのため調理工程自体もさらに関心の分離を行う。

調理工程も「材料を切る」「具材を使って調理をする」という関心の分離ができるのでその2点で分離をする。

まずは材料を準備する。カレールウ(箱の半分)、牛豚ひき肉(250g)、玉ねぎ(1.5個)、なす1本、ズッキーニ半分、パプリカ半分、カットトマト缶(半分の量)、サラダ油(大さじ1)、水(250ml)を用意する。


材料を準備したら実際に作る工程にはいる。

最初は材料を切る。
玉ねぎはみじん切りにし、なす、ズッキーニ、パプリカも切る。

続いて調理をする。
フライパンにサラダ油を熱し、玉ねぎをよく炒める。玉ねぎがすき通ってきたらひき肉を加えて炒める。その後、なす、ズッキーニ、パプリカをフライパンに加えてさっと炒めたらカットトマト、水を加え、中火で約5分煮込む。いったん火を止め、カレールウを割り入れてよく溶かし、再び中火で時々かき混ぜながら約5分煮込む。

ここで関心事を切り分けた事によって、玉ねぎ以外の具材の切り方が不鮮明であることがわかったので、それを付記する。

まずは材料を準備する。カレールウ(箱の半分)、牛豚ひき肉(250g)、玉ねぎ(1.5個)、なす1本、ズッキーニ半分、パプリカ半分、カットトマト缶(半分の量)、サラダ油(大さじ1)、水(250ml)を用意する。


材料を準備したら実際に作る工程にはいる。

最初は材料を切る。
玉ねぎはみじん切りにし、なす、ズッキーニ、パプリカは1.5~2cm角に切る。

続いて調理をする。
フライパンにサラダ油を熱し、玉ねぎをよく炒める。玉ねぎがすき通ってきたらひき肉を加えて炒める。その後、なす、ズッキーニ、パプリカをフライパンに加えてさっと炒めたらカットトマト、水を加え、中火で約5分煮込む。いったん火を止め、カレールウを割り入れてよく溶かし、再び中火で時々かき混ぜながら約5分煮込む。

これで最初の文章よりは実際に作るときにわかりやすく、調理するときに作りやすい文章となった。(ちなみに元のレシピは更に見栄えとして関心の分離を行なってさらにわかりやすくしているがそれは割愛する)

まとめ

  • 原典における「関心の分離」とは一連のものごとを着目する側面(≒関心事)ごとに分けていくこと
  • 関心の分離を行うと以下のようなメリットがある
    • 関心のある物事(関心事)ごとに内容が整理されるので、内容がわかりやすくなる
    • 分離する前に不足していた事柄に気づくことができる

参考サイト

『モデリングの学び方:座談会』を見たよメモ

モデリングの学び方:座談会 - connpassを見たよメモです。ディスカッション形式だったので、話の流れになぞらえてまとめていきます。

本日の話し手

この会でメインで喋られていたのは以下の方々

本日の趣旨説明と増田さんの考えるモデリングに関して

まずは下記の資料を使いながら今日の催しの趣旨説明と増田さんの考えるモデリングに関しての話があった。

speakerdeck.com

上記の資料にもあるが以下の話が冒頭で行われた

  • 今回の話し手の属性に関しての話(共通的な部分もありつつも自社サービスを持つ人たち3人と、受託開発を主に行う人たち3人という構成)
  • まずは前提の話としての増田さんのモデリングの考え方のダイジェスト説明
    • 効果的なモデリングの考え方(要点をうまく表現する名前を見つける、認知不可の軽減)
    • モデリングで目的とするところ(要点の発見、個人の思考整理、チームへの伝達、オプションとしてのドキュメント、など)

冒頭の話のあと大きく2つのトークテーマが出された

トークテーマ1「普段はどんなモデリングをしていますか?」

このパートでは各話し手ごとに話が展開されていったので各々の話者ベースでざっくり話したことを書いていきます

増田さん

スライドの資料にあったものと同じで、要点をまとめるときや語彙をシェアするのにモデリングを行う。またモデリングに関して3つのアプローチをしている旨の話がありました。

上記の3つのアプローチから、中核となるものと周辺的なものを切り分けて中核のユースケース、中核のデータ、ドメインモデルを使ってドメインモデル中心な形でつくっていくということを話されていました。

かとじゅんさん

Chatworkではレガシーからの脱却というのがあり、ソフトウェア考古学(いわゆる稼働中のソースコードからの発掘作業)が必要なため増田さんのあげた「要点」の発掘が必要となる。この発掘の工程も我流でやると抜け漏れが多いのでRDRA v2などを使って洗い出しているとのことでした。また、現状のシステムを理解してモデルを再構築するなどしているため、モデルなどを図でかいて同意してもコードを書いたら(良くも悪くも)ズレがでてくるのでその行ったり来たりで苦労している側面があるという話もあった。

すでに稼働中のため外部仕様をいきなり変えるのは難しい。またビジネスの表層のモデルと、より深い部分の深層のモデルがあるが、表層のモデルですら変えるのに苦労する場面がある。またドメインモデルを改善変更する際は既存のモデルのデータの改善あるため、必然的にマイグレーションが必要になり、セットで考える必要があるという話もされていました。

なお、絵などを起こすものはクラスモデルのような図も書くことがあるがアクターモデルの図をかくケースがあるということでした。

原田さん

普段はアジャイルコーチをされている原田さんはモデリングの中心としては個人の理解ではなくチームの理解という話をされたいた。

受託開発のため、まずはビジネスとして何に困っているかをヒアリングして、そこから語彙のモデリングなどを行い、受託開発を発注したお客さんとの意思疎通を図りに行ってちゃんと問題がないかを意識する形にし納得してもらいながら進めていくという。ただ納得していても正解かわからないので、モデルに書く・コードに起こす・テストする・試しに見てもらうというのがアジャイルの形だとできるのでそこで問題が解決したかをお客さんに問いやすく、いわゆるうずまきモデルのシナリオが解決できているかというところを含め、シナリオとコードの行ったり来たりをしていると話してました。

また、お客さんの言葉にも抽象度の高い言葉も具体的な言葉もある。その抽象度を合わせるために概念モデルを作って相互理解を図るということもしているという話だった

ミノ駆動さん

現職の会社に入られてからまだ4〜5ヶ月のミノ駆動さん、その中で新しいものを開発することになったが複雑化することが想定されるためしっかり分析から始めようとしている。そのためには既存のビジネス理解も含めて俯瞰して理解しないといけないため、DDDのコンテキストマップをカスタマイズしながら利用し、会社でやっているドメインやコンテキストを洗い出し、図示化したという。

また、先日のDevelopersSummitで以下の講演を発表した話から「目的」という部分の話も展開された。

speakerdeck.com

会社の中でドメインエキスパートや有識者ヒアリングを行った際に、各々達成したい目的が違うということがある。そういう場合も図に起こして、目的の中にドメインができる構図になる。そのため、そこにモデルをおいて目的とあっているかが評価しやすく、目的に沿っているかが評価しやすくモデルだけ起こすときに起きがちな目的を見失うことがすく愛というお話だった。

hirodragonさん

受託開発を行なっているhirodragonさんことヒロさんだが、受託開発という性質上、長くビジネスに寄り添うというよりかは毎年やる案件が変わるという話が多く、すべての案件に関していろはに沿って丁寧にモデリングしているかというとそういうわけでもないと話していた。

ただ、そんな中でも必ず「概念モデル」を作るという。

受託開発のため、システム化する対象は案件紹介のときに初めて聞いて何も知らないところからスタートする、そのときに時間かけたり複雑なことにはしたくないので、用語や関連、時々多重度を書くぐらいの概念モデルを作るという話だった。ここに更に必要な場合はユースケース図ロバストネス図を書くとのことだった。

また、ヒロさん自身がクラス図はモデリングという切り口ではなく、思考を整理してコーディングを行うためのものとして書いているという話だった。

藤岡さん

現職に入社したのが2年前の高崎さん、会社がつくられたのが6年前なのでアプリケーションが作られた当時を知るエンジニアや関係者がいないところのスタートだったので、前述のかとじゅんさんと同じような「ソフトウェア考古学」という状態で、動いているソースコード以外要件がわからないという状態だったという。そのため、ソースコードを追いかけながらやっていることを類推して拾い上げていく作業を既存部分の読み取りではやっているとのこと。

対して新しいことをやりたい要望もあるので、そちらはユースケースを作ってドメインモデルのようなものを作りながらプロダクトオーナーと「やりたいことはこんな感じですかね?」を聞いていくという。またモデリングは図をつくるわけではなく、クラスを作ってそれをツール(Jig)を使って可視化している、そうすることで相互参照などを発見しやすく、修正も行えるとのことだった。

昔は図をきっちり書くということもされていたということだが、いまではコードで書くことをしており、必要であれば手書きでかくなどをしているとのことだった。

高崎さん

広く一般的なSIerとやっていることは変わらない、という高崎さん。モデルを中心に開発するためDSLやモデルから自動生成するツールなどを活用しながら開発をしている。モデルは書くものの、要件定義をして仕様をつくるような従来からあるSIerのつくりかたと変わらないがクラス図を書いたりしてみんなで認識を固めるなどしているという話だった。

ただ、案件の内容や忙しさによってはモデリングをうまく作ろうという余裕がなくなってくるのでモデリングよりもコードを書こうとチームメンバーがなりがちになる、ただそんな中でも意識しているのは「語彙のモデリング」ということはやっている。どんなに忙しくても「どんな言葉がいいんだろう」ということをしているというお話でした。

モデリングをやるときはRDRAを使ったり、匠Methodを使ったりしている。集まったメンバーのよってどんなことをどこまでやるかというのはかえているとのこと。

トークテーマ2「どうやってモデリングを学んできた感じですか?モデリングの学び方のすすめはありますか?」

一通り、話し手の話を聞いたあとに、流れる形でどのように学んできたかという話になっていった。ここでは複数の人が掛け合いながら話が進んだので、やりとりをサマリでまとめていきます。

どうやって学んできたか

交流での学び(高崎さんの場合)

まずは高崎さんが学んできた経緯の話となり、キャリアを歩み始めたときにデータモデリング入門の本に出会い、データモデリングを学び、その後オブジェクト指向のブームの当事者だった人たち(今回の主催の増田さんなど)と交流していくことで色々な経験を積んでいった。そんなご自身のキャリアを振り返ったときに、静的なものであるデータモデリングと動的なものであるプロセスモデリングという区分けをしたときにデータモデリングから学んだほうがいいんじゃないか、という仮設があった。

仕事での学び(藤岡さんの場合)

その話の流れで藤岡さんはどうだったか、という流れになり特異なケースと話しながらキャリアの話となった。藤岡さんのキャリアとしてはSIerとして増田さんの案件にアサインされ、そのプロジェクトに入ったことにより、仕事ととして取り組んだことがスタートだった。そのため自身で学んで行ったと言うよりかは仕事としてやらざるを得なかったという側面が強かったとのこと。

また、高崎さんのデータモデリングをやったかという話題に関しては当時のプロジェクトのリーディングであった増田さんと一緒にやったが、当時は増田さんがテーブル設計などをしていたので、あまりやったとは言える形ではなかった。

アジャイルモデリング(原田さんの場合)

原田さんの経験の話になり、一番最初は画面や帳票の分析(今で言うInfomationArchitecture)をどういう情報の塊かという分析をしていた。そこからT字型ER図に出会いモデリングの内容に興味を持つことになった。そこからお客さんの話を聞いてモデルを起こすということをやってきて、そしてDDDの着目し、お客さんからの要望をモデルに起こしていくというようなことをやってきた。その中でスクラムをうまく回すにはユーザーストーリーからいきなり実装に起こすのは難しく、モデルを作ってやると良さそうという考えができ、アジャイルモデリングを両方できるところは…というところで現職にたどり着いたという話だった。

コマンドとクエリ(かとじゅんさんの場合)

かとじゅんさんの経験としては、もともとはSeaserで開発をしておりトランザクションスクリプトドメイン駆動も両方やってきた。当時の楽々ERDレッスングラスを片手にデータベース設計などの書籍を見ながら学び、データベース設計は業務で腐るほどやってきた、とのことだった。そんな中エリック・エヴァンスのドメイン駆動設計に出会った。その中でDDDはHTTPでステートレスなウェブの開発とは相性が悪いのではという葛藤があったがコマンドとクエリに分離して考える考え方にたどり着き、手応えを感じた。

コマンドとクエリの考え方は一旦クエリはおいておき、コマンドに着目してモデルを考え、コマンドの振る舞いにフォーカスして、そこにデータを持つようにすることでスッキリとしたモデリングになった。

知識を追いかけて身につく(hirodoragonさんの場合)

ヒロさんの場合は「どうやって学んできたか」と聞かれるとモデリングを学ぼうと思って学んできた形ではなかったという。

もともとのキャリアスタートも職業訓練校からエンジニアになり、先輩もいない中で手探りでやってきたのでプログラムを書くということだけで必死だった。そのため最初は継承などもノリで使うなど、オブジェクト指向型言語のうまい使い方がわからない状態で使いづらさを感じていた。

そんな中外部のすごい人と仕事をする機会があり、その案件で「DDDをやります」ということになり、DDDとはなんだ?という軸で調べて行きドメイン駆動設計の思想に触れて、クラスがどういう単位であるべきかなど腑に落ちた。そしてDDDの知識を深めるにはオブジェクト指向の知識が必要となり、そこからオブジェクト指向をやるならクラス図を読めないと駄目というところからクラス図のUMLの勉強をはじめたというような流れでモデリングにたどり着いた。

そのためDDDを知りたかったというところが起点で色々知らなければいけないことを学んでいったらモデリングにつながっていった。

自分の力として身につける方法

問題と対峙し、モデリングをする

この話の流れでミノ駆動さんから「モデリングしたらどういう旨味があるのか、モデリングはひどいコードにぶちあたったときに効果が出るのではないか」という話になり、ミノ駆動さん自身が巨大クラスと対峙するためにモデリングをしてきたという経験という話があった。また、問題があるモデルと対峙するという経験から様々なオプションを考えることができ、そこから役に立つモデルなどを考えることができる。ただモデルは一人で作るものではなく、公開して色々な人から意見をもらって討論したりフィードバックを求めることが大事。

形から入って覚える

ひどいコードだけではなく、良いコードから得るものもあるという話もあり、きれいなコードの構造としてどういう構造があるかというところから学びもあるという。その中で形から入るという意味ではオブジェクト指向エクササイズは有用なこともある。まずは形から入ることでカプセル化したコードを作るようになり、クラス設計の書き筋がよくなったという例や、エッセンスだけでも意図のズレや作りたい方向がズレが起きずに実装される例などもあった。

Tell,Don't Ask

モデリングをするときに気をつけている考え方として Tell, Don't Ask を徹底しているという話になった。メッセージパッシングのようなタスクを依頼してデータをとる形でないとオブジェクトを加味したモデリングではなく、ただのデータモデリングになりトランザクションスクリプトになってしまう。またオブジェクト同士のデータのやりとりという観点では、CRCカードというワークショップという一人ひとりがオブジェクトとして経ってやりとりをすると理解が深まるケースもある。

どうやって伝えるか、身につけるか

話し手の人たちは、時代の流れなどで一通りやってきているひとなのでやはり学ぶのは難しいのではないかという話になった。(ひろさんが追っかけて覚えた人だったのでしんどいという話もセットであった)そんな中オブジェクト指向プログラミングを半年間で学べた例として、レガシーコード改修をペアオペで行うという事例の紹介があり、その場合は新人さんが半年程度でオブジェクト指向の考え方が身についたという話だった。そういう話からも伝える側と伝えられる側の相性がよければ「ペアオペなどを通じて暗黙知的な知識の共有」のような話のほうが伝承しやすいのではないかということだった。また、体系化はしづらい側面があるという話もあった。

やはりペアオペの例でも養殖されたサンプルコードよりも、身近なプロダクトコードをベースに手を動かして学ぶのが、得るものが大きいのではないかという話もあった。

機会のない人たちへのアプローチ

実際の開発でモデリングができる状態が望ましいが、多くの人がそうとは限らないのでそういう人を救うためのワークショップなどがあれば…という話になり、やはり学びは一緒に学習してぶつけ合う人がいると学びの一歩が早く切れるという話もあった。 また、そもそも近年のエンジニアはクラス図をつくるという経験をしたことがない人も多くいる場合があり、「初めてのクラス図」などの入門的なものも意義のあるものではないかという話があった。

この会話の流れで色々なコミュニティなどの紹介があった

振り切って、戻る

Javaを使えば、クラス図はコードからリバースできるのでJavaソースコードマークアップ言語として捉える振り切った考えもできる。経験者であればそういうコードから入ってモデルを追うのはできるが、初級者に求めるのは酷な側面もある。

ただ、振り切った経験というのは必要な場面もあり、振り切った経験をすることでその経験が糧となり、駄目であれば戻るという選択肢をとることができるようになる。ただエクストリームな選択肢ではあるので、もっとふんわりしたものも提供したい側面はある。

会全体の感想

  • 自分自身概念理解はなんとなくしているが、ツールやHowとしてのモデリング知識はからっきしなく、実際やったことがないので、UMLをはじめとしたクラス図の書き方とかを叩き込んだほうがいいなというのが今回の率直な感想でした(hirodragonさんと同じ轍を踏みそう)
  • いざ実際の現場でどういうことをしてきたかという面の話は学びが多く、以下に他の人に意識を伝搬していくかという点に関しては後々活かせる話も多かったように思えます。
  • どうしても複雑な業務ロジックなどがない開発だと、概念整理してモデルをつくろうというよりかは既存の考えの模造でつくる方に倒れがちな気がしているので、立ち上げた瞬間は問題ないがあとからしんどくなってくるケースがあるからチームで開発する場合はしっかりと向き合う、意識をしてもらうという ことが大事だなと思いました。
  • 歴史をなぞったりすると、日本語文献では情報がなかったり、日本の当時の歴史背景が追いづらい(ピアソンショックとかもあったりした)ので歴史を体感してきた人たちに日本のソフトウェア開発の歴史みたいのをまとめてもらえると、追っかける側としてはそこを道標に色々な情報に手を伸ばしやすいのかな…とも思いました。

関連リンク

話に出てきた書籍