読者です 読者をやめる 読者になる 読者になる

プログラミングで考えていることについて考察してみる

まえがき

前回までDDDの読書記事書いてたのですが、7章くらいまで読んだあたりで先にやりたいことができてしまったので、一旦中断しています。(6, 7章は年末年始の間に記事書きます)

今回は年末ということで今年の振り返り的な記事を書きます。

続きを読む

Eric EvansのDDDを読んでます(3)

今回は第5章まで。

忙しかったのと、他の本を参照したりしていたので読むペースが少し遅くなってしまっていますが、またペースを戻しつつ進めたいと思います。

あと、ブログのデザインを変えてみました。 もともと大画面で見ている時に幅が狭いかなーと思っていたので、大画面では少し記事の幅が大きくなるように調整しました。

読みやすくなったかな…?

ソフトウェアで表現されたモデル

関連

ドメインを理解することで、関連の方向性と限定された関連を導く。
限定された関連は多重度を減らし、より多くの知識を伝えることができるようになる。

OOPでやっている時に、依存の方向性や関連が複雑にならないように限定するのと似たようなものでしょうか?

このあたり、仕様から実装へ移るときに明示的には意識できていないんじゃないかなと読んでいて思いました。

エンティティ

エンティティは同値性よりも、同一性(identity) によって定義されるオブジェクトである。

こういうときに、"identity"って便利な単語だなと思います。まさに"identity"。

例えば、勤怠管理システムにおけるユーザとかはそれかなと。 同姓同名だったとしても、別の人物であれば別のオブジェクトとして区別されるべきだったりするので。

またエンティティは同一性を保証するための機能が無いといけないため、その保証ができるための操作の設計が必要になる。例えば一意に生成されることが保証されるIDなど。 この同一性の保証に関しては、熟考したほうが良いことが本で示されていました。 例えば、病院をまたいだ医療記録などで、同一性をどう保証するかなど。

奥が深いですね。

値オブジェクト

概念的な同一性がなく、物事の特徴を記述するオブジェクトである。

色とかはそうですかね。

Yellow と 黄色 のどちらを選んでも本質的には変わらないので実際には 「Yellow = 黄色」の図式が成り立つ、みたいな感じですかね。何であるかが重要な問題であって、誰とか、どれとかは意識しなくてよい場合に現れるのが値オブジェクトである、と。

本を読むまでは不変であることが当たり前のようにイメージしていましたが、可変であっても問題ないようですね。 とはいえ、出来る限り不変に設計するほうがよいようですが。。。

サービス

概念的にどのオブジェクトにも属さないような操作を、ドメインに沿った自然な形で表現する。

サービスって、どれをサービスにするかって難しいところじゃないかなーと。 多分、各オブジェクト間でのやりとりで、それを各オブジェクトに持たせるとややこしくなるタイプの操作って感じだとは思うのですが、まだモヤモヤしたところが取り切れていない感じです。

モジュール

モデルにおいて意味のある一部として現れ、より大きな尺度でドメインを表現する。

モジュールを読む際にはマイヤーのOO入門を引っ張り出してきて、少しモジュール性のところを読んだりしていました。 モジュールは低結合・高凝縮であり、内部をよく表現したものである必要があるというのがやはり必要ってことかなという感じでした。ただ、ここにドメインをしっかりと反映するのは大変かなと。

あと、リファクタリングされないモジュールは上記のような低結合・高凝縮で内部をよく表現し、ドメインを反映したものにはできないため、必要ならば再構築などもしっかり行っていくべきだと書かれていました。

モデリングパラダイム

モデル駆動設計では、モデルに対応した実装技術がなければならないということが書かれています。とくにあるとしても成熟していなければ、それを行うことに対してリスクがあるということも書かれています。

最後にパラダイムを混ぜることについても書かれていますが、つかみにくい場所もあったので、次の章を読みつつ更に理解を深められればよいかなと思っています。

エリック・エヴァンスのドメイン駆動設計 (IT Architects’Archive ソフトウェア開発の実践)

エリック・エヴァンスのドメイン駆動設計 (IT Architects’Archive ソフトウェア開発の実践)

Eric EvansのDDDを読んでます(2)

今回は第4章まで。

第4章の要約

章のタイトルは「ドメインを隔離する」。

レイヤアーキテクチャによってドメインをその他のレイヤと分離する話が書かれています。 また、その対極にあるものとして『利口なUI「アンチパターン」』というものが書かれていました。

レイヤアーキテクチャによるドメインの隔離

DDDではドメイン(レイヤ)をレイヤアーキテクチャにおけるその他のレイヤと分離しておく必要があり、これを達成できていなければ、DDDを行うことができないと書いてあります。

ドメインを中心にして設計を回すのがDDDのはずなので、UIとドメインロジックが一体化していたらドメインロジックの変更が困難だったりするのは大体明らかなところなので、そうかなという感じでした。

後半の章でいかにしてドメインを隔離しておくかということが書かれているらしい。(14、15章)

利口なUI『アンチパターン

一方で、『利口なUI「アンチパターン」』に関しては、「あー、あるあるw」って感じで読みました。いわゆるMVCのModelもViewもControllerも密結合していて、UIの変更も、ドメインロジックの変更もすべてUI・ロジック双方に影響が出るような状況になっているタイプですね。

とりあえず作って終わりなプロトタイププロジェクトのようなものだと全然アリなのですが、何度も何度も繰り返し変更や追加がやってくるようなときには避けたほうがいいパターンだと認識してます(というのは本にも書いてありますね)。

この辺はMVCとかMVVMみたいな考えが役に立ちそうです。

結局のところ、チーム内の知識を高めていかないと、この辺りを避けて通って行くのが辛いというのは本にも書かれていました。チームとして、まずこの『利口なUI「アンチパターン」』が問題なのだという共通認識を作るのは重要なのかなと思いました。

DDDって実際にうまく回すには苦労しそうな点がたくさんありそうですね。「チームでDDDを行うための前提条件になる共通して理解しておくべき事」みたいなものもまとめておいたほうがいいのかもしれないと感じてます。 始めてからでは遅いこと、とか、始めてからでもいいので理解しておいたほうがいいこととか。。。

エリック・エヴァンスのドメイン駆動設計 (IT Architects’Archive ソフトウェア開発の実践)

エリック・エヴァンスのドメイン駆動設計 (IT Architects’Archive ソフトウェア開発の実践)

Buffetってライブラリを作ってみた

何ヶ月かこそこそと裏で作ってたライブラリを公開しました。

naokirin/Buffet · GitHub

よくあるExcel式データ駆動開発で、ファイルやシートを横断的に検索するのがキツいというのを感じていたので、気軽にデータ定義をするだけでExcelに入っているデータをリレーショナルデータベースで再構築できるといろいろ嬉しいんじゃないかなと思って作りました。

Excelからの読み込みとSQLiteへの流し込み以外の機能が無いので、結構小さめです。

どうってこと無いライブラリなので、すごいものを期待しないでください(GUI部分とかなーんにもないので)。

勉強になったこと。

C# の属性とリフレクション

勉強になったことがいくつかあって、まずはC#の属性とリフレクション。

属性については制限が結構キツイなっていうのをより正確に知ることが出来ました。 使える型が結構限られてて、いくつか妥協して作ってあったりします。

リフレクションに関しては、遅い処理になるためにどうするかみたいなのを色々知ることが出来ました。

Mono

それからMono。

Macで開発していたので、基本はMac上でMonoで動かしてWindowsではあとでちょこっとテストしてみる感じでした。 Monoは.NETで使える機能が使えなかったり、足りなかったり、動かなかったり、etc.
やはりやり始めると色々あるなと実感しました。

ユニットテストは書いてはいますが、バグは結構あると思うので、使ってみようって際にはお気をつけてw

心残りはCode Contracts がMonoでの対応が微妙すぎて、結局使わなかったことですね。。。 使いたかった。。。

SQLite

スマホ向けのアプリ開発でクライアントにデータをもたせるのに使えるんじゃないかってことでSQLiteに目をつけていたのですが、それの前準備としてこのライブラリを作ってみたというのが本音です。

SQLite自体、あまり大きくないデータに対してで言えば、SQLRDBとしては申し分ないのではないかというのが今回触った感想でした。(SQLiteで手にあまるようなExcelデータはもとから間違っているようなものなので…)

ちなみにスマホアプリでC#な理由は、Xamarinだからです、はい。

全体的な感想

とりあえず作ってみようということで作ったところが大きくて、すぐに使える何か、と言うものにはなっていないですが、クラス書けばあとは10行未満でExcelからSQLiteに流し込めるっていうのは悪くないんじゃないかと思っています。

必要があれば、もう少し手を加えていこうかなと思っていますが、一段落はしたかなと思っています。

GUIツールにまで出来るようにしておくのがベストですが、一旦はここまでにしておきます。

Eric EvansのDDDを読んでます(1)

最近、アウトプットが疎かになりつつある感じがしていたので、読書記録でもつけていこうと思います。

最近読み始めた本がEric Evansのドメイン駆動設計(DDD)ですので、こちらの読んでいて感じたこととかを書いていきます。

ちなみに、ちょうどアジャイルソフトウェア開発の奥義を読み終わって、Rebecca Wirfs-Brockのオブジェクトデザインを読み進めたいなと思っていたのですが、最初の方を読んでいてDDDとの密接な関係がある気がしてきて、結局DDDを先に読むことにした感じです。

DDDに関しては、「どう実践するんだ!?」っていうので、イメージが湧いてないところが多い状況のなか読み始めました。

第1章から第3章まで読んだ感想

おぼろげながら具体的な流れが見えてきた感じがします。 第1章から第3章辺りは、結構具体的に例示しながら、DDDをどのように進めるかの概略が示されている感じです。

DDDでは「ドメイン・モデル・設計・実際のコード」という4つをいかにして繋ぐかというのが主題にあるように感じました。 これらのどこか1つでも乖離すると、ドメインと実際のコードがかけ離れていき、結果としては正しくユーザやドメインエキスパートの関心事をシステムに反映できなくなってしまうので、DDDによりこれらを適切につなぎましょうということかなと。

ざっくりこんな感じのことなんだろうと受け取りました。

細かい部分としてはユビキタス言語などもありましたが、なんとなくDDDの目指しているものが見えてきたので、さらに読み進めていこうと思います。

実際の業務でも、この辺りって大事かなと思うところもちらほらあったりするので、この本を読んで何らか生かせればいいなと思ってます。

エリック・エヴァンスのドメイン駆動設計 (IT Architects’Archive ソフトウェア開発の実践)

エリック・エヴァンスのドメイン駆動設計 (IT Architects’Archive ソフトウェア開発の実践)

アジャイルソフトウェア開発の奥義を読み終えた

苦節2年、ついに読み終えました。

買ってから半年寝かせ、そこから1年半書けてようやく読み終えました。

とは言っても、結局まだまだ実際のコーディングやらに結び付けられているというのは結構少ない感じがしています。 それとだらだらと読んだせいで、細かいところを忘れてたり、時間があったら軽く読み返す必要はあるんじゃないかなと。

内容的には、設計の悪臭とオブジェクト指向設計の原則は、自分の中ではオブジェクト指向に対して一歩前進できたきっかけにはなってるんじゃないかなと思っています。GoFデザインパターンが意識せずともコードの中に出てくる瞬間をよくよく思い返してみると、OCPやらDIPに則った設計をしようとした結果だったりして、デザインパターンをつぶさに覚えていくよりもずっとデザインパターンを深く理解できた気がします。

もちろん、オブジェクト指向の難しさみたいな部分もすごく感じた1冊でした。これだけ深く考え、ようやくこのレベルの設計に到れるんだなと。オブジェクト指向は人類には早かったんや!(笑)

デザインパターンは知っているけど、アジャイルソフトウェア開発の奥義は読んだこと無いみたいな人には特におすすめしたい1冊です。(原則とデザインパターンの関係についてで言うと、石井さんによる記事- Open-Closed Principle とデザインパターンがすごく簡潔で私の理解を進めてくれました。)

なんとか読み終えたという感じですが、読んでいって感じたこととして、設計についての知識を一層深める必要がありそうということでした。次に読み進める本として、たとえば、Eric EvansのDDDやRebecca Wirfs-Brockのオブジェクトデザイン、あとDCIについてLean Architectureなんかを読み進めていきたいかなと思います。(全部積んであったんですけどねw)

アジャイルソフトウェア開発の奥義 第2版 オブジェクト指向開発の神髄と匠の技

アジャイルソフトウェア開発の奥義 第2版 オブジェクト指向開発の神髄と匠の技

Developers Summit 2014 Kansai に参加しました

タイトル通り、デブサミ関西に参加してきました!

今回はその記録です。

会場入りまで

休暇をとって参加したんですが、休みの日にあんまり早く起きたくないなぁみたいな考えのもとに午後から参加にしてました(ぉ

あとから発表資料見たりして、行ってもよかったかも、と思ったり。。。 まあ、すっきりした頭で午後から参加できたってことで、OKってことにしておきましょう。

行きは午後から参加ということでのんびりと小旅行くらいの気分で会場まで。 (神戸駅阪神電車の改札からポートライナーの改札に行くまでにあるJRの改札に惑わされましたw)

会場入りしたタイミングがちょうど午前の部が終わったタイミングで、参加者の皆さんが昼食タイムの状況でした。

アジャイルのススメ

午後1つ目に参加したセッションは西村直人さんによる「アジャイルのススメ」。

豊富な開発経験によるお話は、詳細な手法にこだわらず、本質を突いているように感じました。

以下、自分が印象に残ったところを書き出していきます。

「お金を出す立場で考えると、大切なことが見えてくる」

意外と盲点になりやすいんじゃないかなと。 本当はすごく重要なはずなのに、忘れられやすいというか。

開発者が目の前のプログラムや開発のプロセスにとらわれすぎて、見失いがちなところをよくあらわしている言葉だなと感じました。

アジャイル開発を行うとなった時に、うまくいかない例

アジャイル開発をやりたくないチーム」だそうです。

まず、どんなメリットがあるのかを説明したりとか、やる気を出させるところからスタートしないといけないために、ある種導入コストみたいな部分が多くかかってしまうみたいですね。

チーム内で自分以外がやる気がないときって、結構こういうパターンであきらめちゃう人も多いんじゃないですかね。。。

お客さんをアジャイルに巻き込む方法

最初はお客さんには黙っておく」そうですよ。

ちょっと笑っちゃいましたw

でも、これには続きがあって、「自分たちをスーパーエンジニアに見せれば、自ずとお客さんから興味を持ってもらえる」そうです。

アジャイル開発のメリットを最大限に生かしてお客さんに価値を提供できれば、お客さんから逆に興味を持ってもらえるっていうことだそうです。その時に初めてお客さんに話せばいいと。そういう巻き込み方も確かに1つのパターンだなと思って聞かせてもらいました。

Web技術で開発するエンタープライズモバイルアプリ

こちらはスマホ向けにWebViewを用いた業務アプリを開発する際の注意点のようなお話がメインでした。

実際に仕事でこういった開発をしている人には結構有用なところは多かったんじゃないかなと思います。 (仕事でもプライベートでもやってないと、ちょっとピンとこない部分が多かったです…)

ただ、今後そういったことをする際にはちょっとしたヒントにはなるんじゃないかなと感じました。

Xamarinによるマルチデバイス・クロスプラットフォーム開発の実際

最近、プライベートではXamarinをいじってることも多くなったので、どうせならと聞きに行ってみました。

実際に仕事の開発で導入するのにはやはりXamarin自体への初期投資がかなりネックになったとのこと。 「やっぱりそうかー」と思いました。正直、高いですもんねw

登壇者の伊藤さんは頑張って導入するためにいろいろとやったそうです。 たとえば、ランチタイムの勉強会でいろいろ紹介したり、見積もりをする際にXamarinでやった際の見積もりも一緒につけてみたり。 導入したいって思ったら、やっぱりこのくらいガシガシやっていかないと難しいんだなと感じました。

その後、とあるプロジェクトで導入して、当時はXamarinの情報が少なくて苦労したそうですが、Xamarinで開発することでiOS/Androidで多くの共通化を行うことができたそうです。

やはりXamarinといえばMVVMでの開発、って感じですが、開発する際に重要になるのが、ModelViewとViewの部分の認識を合わせておくことが重要になるそうです。 なぜかというと、XamarinではiOSAndroidでViewに関しては別に作る(MVVM Crossで開発していたそうです)ので、各プラットフォームでのViewがバインドする予定のものが異なっていたりするとModelViewの共通化が難しくなったりするからだそうです。

「継続的デリバリー」と「サービス仮想化」で変わる、エンタープライズアジャイル開発

次にこちらに参加させていただきました。

タイトル的に結構レベル高そうって感じだったんですが、予想通りw

いわゆるエンタープライズといわれる開発で既存システムや各システムの開発が並行して行われている状況での開発について、「サービス仮想化」という技術を用いて開発するというお話でした。

「サービス仮想化」という単語がなじみがない単語だったので、そのあたりについてはすごく勉強になりました。

デブサミ名物コミュニティLT

こちらはイベント感あふれる感じですごく面白かったです。

結構知らないコミュニティもあったので、要チェックって感じでした。

ちなみにLTは漫才形式のLTが多かったようなw

司会のまっちゃだいふくさんがおっしゃっていましたが、新しいLTの形なんですかねw

終わりに

今回、デブサミ関西に参加して、半年ほど前に書きかけてた(とある理由で放置してた)発表資料を引っ張り出して、書き直して会社の社内勉強会で発表してみることにしました。

参加してみて技術や知識を、しっかりと仕事に生かしてこそエンジニアだし、それをより多くの人に共有できてこそ仕事をよくできるのかなと感じたからです。(といっても、デブサミで聞いた内容とは全然関係ない内容ですw)

勉強会とかに参加するといろんな情熱みたいなものを分けてもらえる感じがしますね!

セッションの内容もさることながら、そのあたりでも参加してよかったなと感じました。