現場で役立つシステム設計の原則を読み終えたのでまとめていく - ぽんぽんぺいんでつらたんなので、おしごとおやすみしまーす

最近は無職期間を活用しながら普通二輪の教習に通っていたろんです。

開発に関してはサボりつつも、重要そうなエッセンスを取り入れる為には良いタイミングだと思い、ゆっくり掲題の本を読んでいました。

こちらは次の職場の先輩に勧められた本で、オブジェクト指向+ドメイン設計でのアプローチになるので読むといいと勧められました。

前職で同僚が読んでいたこともあり、前置きは少し読んでいたのですが

リーダブルコードを貸した後に、こちらの方が良いと思って読んでいると聞き、「ちょっとそういう主旨で読まないで欲しいんだけど…」と複雑な思いを抱えながらの出会いだった記憶があります。ちなみにその同僚にはやんわりとこれはリーダブルコードの代用ではないと伝えておきました。

結論から言うと、設計思想についての取っ掛かりとして良本だと思えました。

自分がいいと思ったポイントは下記で、

・ドメイン設計の具体的な思考法

・画面とドメインロジックの分離について

・Web-APIの設計方法

などです。

業務についての理解が浅いことで、アプリケーションの整合性に支障をきたすという部分が実務において心当たりがあり、反省しました。

自分の話になりますが、前述した同僚の彼は仕様把握に意欲を燃やしていて、カスタマーチームとの連携も積極的に話を聞きにいくなどしていた面が特に素晴らしいと思い、様子を見ていました。

彼はスクラムマスターを兼任していて、働きの結果として開発チームのタスクの量がかなり膨れてきた事が目につきましたが、これは潜在的に元からあった問題を表明する事が出来たので良い傾向だと感じました。

問題なのは優先順位で、つい「開発として実装が楽なのでこちらを先に実装してしまおう…」という意識で楽なタスクに手を出しがちなのですが、それで達成感はお手軽に味わえても、後々を考えたら「これってまとめて実装した方がよかったのよね…」とごちゃごちゃしたUIを目の当たりにして後悔する事になります。

これは、本の中でも述べられている設計の失敗だと思っていて、最初から情報量が多くなる事が想定されていれば、DBについては詳細情報として分離し、アプリケーション側としてはオブジェクト単位での実装を実現する事で仕様を把握する側、アプリケーションを実際に使用する側としてもわかりやすいものになったと思います。

ただ個人的にはこの思い切りの良さをどうやって推進するかが懸念点で、よく必要のないものは実装しない(YAGNI)と言われているように、オペレーション / ユーザーが何をしていて、将来どういうことをしていくのかもわからないままにアプリケーションの設計の話をしていくのは難しいと考えます。そこで文頭に戻り、やっぱりこのアプリケーションはどのように人の役に立つかを考える必要が出てきます。

これは今後の自分の課題で、

タスクの要件を満たす実装ではなく、本質的・根本的に考えて、ユーザーが欲しいものは何か

を知る / 思考する必要があります。ユーザーがアプリを使う背景についての解釈が曖昧だった為に、実装の条件を考える上で時間を使ってしまった事に気づいて、すぐに対処できなかったのが悔やまれます。

ちなみに、この本の対象者は、オブジェクト指向についてなんとなく理解はできたが、そのアウトプットの仕方に迷っている人で、正直Rails（もしくはSTIなORマッパーを採用しているフレームワーク）から入ってきた人・開発してる人（初心者）にはそんなに意味を為さないと思っています…。（この書籍の内容を実現するとSTIで表現するには難しい部分があるんでは…と感じます。）そんな方々は技術書展とかで見かけるRailsの設計パターン系の話を読む方が臨場感あって（いろんな意味で）面白いと思うよ。。

また、引用元の本も記載されているのでこれから知見を広めていきたいという人にもおすすめです。

久々にブログを書いたので色々と辛い… 来週から社会性を取り戻しに新職場で頑張りたいと思います。