投稿

2018の投稿を表示しています

DDDと私

イメージ
Table of Contents 最初に DDDとの出会い DDDに近づく。オブジェクト指向に興味を持つ DDDと再び出会う 現在、DDDとともに 最初に こんにちは moai です。 この記事は、 ドメイン駆動設計 #1 Advent Calendar 2018  の7日目です。 昨日は、 @kawakawa さんによる ドメインオブジェクトとユースケースの関係について でした。 今回は私とDDDの話をしようかなと思います。 ここでは、手法の話はしません。 手法の話をご期待の場合は、ご期待には沿えませんので、どうぞこちらでおかえりください。 DDDとの出会い 私がDDDに出会ったのはおおよそ二年前のことでした。 Amazonの購入履歴を見るに、わたしは2016/02/21に エリック・エヴァンスのドメイン駆動設計 を買ったようです。 しかし、その時は第一部を読んで満足したような気がします。 ざっくり言うと良さがあんまりわからずに、途中で読むのをやめちゃったんですね。 だって、分厚いんだもの。 そのころ、私は新規開発をたくさんするようになったものの、 CRUDに非常に近い機能を作っており、 DBにうまく値を格納するかに熱心でした。 例えば、あるテーブルのデータをPDFに乗せるとか、 テーブルのデータを使って一覧画面をつくりソートするとかですね。 PDFにデータ載せて、こんなの作ったり、 一覧画面を作ったり。(これは弊社の今の画面なので、とても奇麗ですが昔はもっとおぼこい感じでした。) そのため、そのころ読んでいたのは Data Modeling Resouce Book という 世の業務アプリケーションで使われているモデリングはこうなっているんだよという本を熱心に読んでいました。 そのころ思っていたこととしては、 うまくテーブル設計できていれば、 モデルの設計はあとからちゃんとついてくると信じていました。 何なら、DDDなんか知らなくても、俺は俺の最強のアプリケーション作れると信じていました。 そして、なんなら英語の本まで参照しちゃう俺すごい、くらいに思っていました。 今思うと、それは正しい局面もあれば、少し複雑になると正しくない局面もあると

テンプレートを定期的にコピーするスクリプト

イメージ
なにこれ? タイトルの通りの スクリプト を作ってみる記事。 困っていたこと ざっくりいうと G Suiteとか業務で使っているとテンプレートファイルを作って、それをコピーして使うようになるじゃないですか。 ただ、そうすると毎回、ファイルを右クリックして、コピーしてファイル名書き換えてとかするわけですよ。 めんどくさい。 具体的に言うと こうして(テンプレートファイルを右クリックしてコピーして)  こうして(右クリックして、ファイル名書き換えて)  こうする(はぁ、やっとほしいもんが得られた)  作業がめんどくさかったわけです。 その スクリプト スクリプト の設置方法 事前手順 Googe App Scriptのアプリは事前に追加しておいてください。 『アプリを追加』から追加する  Google  App Scriptを接続しておく 手順 そこの ディレクト リに行って、ファイル追加と同じ要領で追加してください。 (そこの ディレクト リにいく必要はホントは無いけど、運用的にはそこ ディレクト リにおいておくのが後々のわかりやすさから親切だと思います。) 新規ボタンから スクリプト を選択して、作成  スクリプト ファイルが作成される  スクリプト 本体 スクリプト 作り方 できた スクリプト ファイルの中に、以下をそのままコピペします。 templateのファイルIDと、フォルダのIDは置き換える必要があるので、注意してください。 function copyFileFromTemplate() { // template Docを取ってくる // (参考)DocのfileIdは一番最後のやつ。下の例では、 hogehogehogehogehogehogehoge がDocのfileId // https://docs.google.com/document/d/hogehogehogehogehogehogehoge/edit var templateDocFile = DriveApp.getFileById( 'hogehogehogehogehogehogehoge' ); // ファイ

「決断の本質」をおすすめする

この記事は、以下の本がとう良かったのかを書いた記事です。 サマリー この本はここ半年で読んだ中でベスト3に入るいい本。 物事が決まらんなーと困っている人にぜひ読んでほしい。 こんなことが書いてある よい意思決定とは何か? 意思決定に対するベストプラクティス 意思決定のベストプラクティスの運用 こんな人には役に立つと思う こんなシチュエーションを抱えている人にとっては役に立つと思います。 物事は決まらんことが多いと感じている人。 決まったと思ったら、後で議論は紛糾するなどを何度も経験した人。 決断はいつもやりずらく、どのような順番で、何をどうやって決めていったらいいのかわからない人 意思決定をスムーズに進める本とかないんか?とか思っている人 結構あるシチュエーションだと思います。私も明確な正解がない状況で、決断を下すというのは非常に難しいなと思います。特に決断を下すこと自体は決めの問題ではあります。しかし、それがチームに支持され、その決断に従ってチーム全体が行動する、そんな決断をスピーディーにしっかりと決めていくのってほんとに難しいと思います。 だからこそ、この意思決定の手法が存在すること自体に意義がありますし、事例が明示されてることによって、ある程度の確かさも与えてくれています。 どのような場面で役に立つのか? こんな場面で役に立つと思います。 何をどのように決めたらいいのかわからなくなって、決めることができなくなってしまっているとき。 いくつかの意見が出て、個々の意見にに誤りはない。ただ、すべてを実行することはできず、どれか一つもしくはいくつかを選べないといけないとき 問題すらよくわからず、不透明な状況で物事を決断していかなくてはならないとき 何かしらの決定案をブラッシュアップするためには案を出して、それを批判して、洗練させていくプロセスを踏めばよいのは、暗に感じている。しかし、それって本当にそうなのか明確に認識していないとき。 この本ではそれが有用に作用している例を提示しています。 案を出す、批判するっていうプロセスって、個人的な感情的な対立を産んだりするので、扱いが怖いと思っているとき それをどのように使っていくのか、いつが使い時なのかが提示されています。 また、建設的に解決

レビューの目的を設定して、レビューを建設的にしよう

イメージ
最近レビューについては、どのようにやっていけばいいのかなーと思うことがあって、 本を読んでいくことにしたところ、 ある本にとても良いアイデアがあったので、紹介したいと思います。 今回読んだ本はこちらです。 そのアイディアとは、レビューの目的を『修正工数を減らすこと』とすることです。 この本は設計に関するレビューの話ですが、一般的なレビューについても応用できると思います。 レビューの目的とは? まずこの本では明確にレビューの目的を定義しています。 これが大変すばらしいと思い感銘を受けました。 この本で記載されているレビューの目的とは 修正工数を減らすこと です。 なぜ目的を定義することがすごいと思ったのか? レビューの目的の言語化自体がすごい レビューの目的を明確に定義されている人は多くないのではないでしょうか? つまり、それを言語化しただけでもとても意味があることだと私は感じました。 例えば、レビューをするときにこれは本当にここで指摘することなのだろうか? とためらった経験はありませんか? ほかにも、指摘はしたのだけれど、レビューされる側の指摘に 何となく迎合してOKをだした経験もあるのではないでしょうか? 私はあります。 そのため、レビューの目的を明示したということ自体に意味があり、 それについて考えるきっかけとなったり、 レビューの目的をきちんと設けようという議論ができるようになるため、 このレビューの目的を提示したというはすごいことだと感じました。 建設的な議論ができそうな目的だから このレビューの目的を『修正工数を減らすこと』としたことで、 建設的な議論ができそうだと感じたため、 この目的の選択に非常に感銘を受けました。 このように、レビューの目的が『修正工数を減らすこと』だとすると、 いつ、誰が行う、なんの修正工数を減らすことになるのか?という点が議論の焦点になり 建設的な話ができるようになります。 少し、具体的ではないなと自分でも思うので、 この文言を読んだときに頭の中に浮かんだシミュレーションを言語します。 どのようにレビューの議論が建設的になるのか? レビューの状況 具体的なイメージがないと、どういう話なのかイメージしずらいため、 具体的

ロバストネス分析をやってみるとモードレスっていうのはAPIも単純になっていいなと思った

イメージ
そもそも 私、設計スキルを学ぼうと思っていて、本とか読んで、インプットだけはやっていたんですが、設計スキルを発揮するにふさわしい複雑な問題には出会ったことがなかったです。 もともと設計というプロセスを挟むことによって、時間はかかるようになるし、いつでもどこでも必要とは思っていないです。 いろいろ本を読んだ今でも、設計プロセスをむやみやたらに挟むのは良くない派です。 とはいえ、設計プロセスの一つである、 ロバストネス分析 をやってみると問題が単 純化 するよという例が得られたので、今回記事を書いてみることにしました。 今回考えた問題 こんなUIが与えられているとします。( Google  Keepに保存ボタンがついているものです。) このUIでは、何かしらリストを追加したり、リストの内容を変更したりすることができます。 保存ボタン付きのリスト。リストの一行に保存ボタンがついているのではなく、リストを含むセクション全体に対して、保存ボタンがついている。 何やら、複雑そうな気がします。 ロバストネス分析 をやってみるとどうなる? これを一度 ロバストネス分析 をやってみることにします。 以下の図において、赤い丸が、ユーザが行う操作で、緑の丸がブラウザ上におけるエンティティです。 また、グレーの丸がサーバ上のエンティティになります。 複雑度がお分かりいただけたでしょうか? 注目は赤枠で囲われている箇所です。 このUIだと、フロントでサーバ上のリストにある要素か、ない要素かを保存しておく必要があって、実装が複雑になりそうです。 また、 API としてもRESTだけで表すことはできず、どうしてもリストに削除フラグなどを仕込んで、削除フラグが立っているリストの要素に対してだけ、削除を実施するなどの工夫が必要です。 私はこの ロバストネス分析 をやってみた結果、この実装はやりたくないなと思いました。 で、どうしたらもっと単純な実装になるUIになるのかなと考えた結果、世の中のリストUIを見ているとリスト全体を含む塊には保存ボタンがついていないことに気づきました。 つまり、モードレスなUIです。 で、モードレスなUIにするとどうなる? リスト全体を含む塊には保存ボタンがついていない、モードレスなUIというのはつまり