「現場で役立つシステム設計の原則」を読んでみたよ
平日は仕事前の30分、仕事後は時々晩御飯待ちの間に読書するようにしています。
今日まで読んでいたのはこちら。
厚さは結構あるのにとっても軽く、最近の製紙や製本技術の向上には驚かされます。
そして本を開いてみるとびっくり。案外字が大きいw
なのに読んでみたら内容が濃い！
読み終わって晩御飯までちょっと時間があったのでインスタで呟いたりしてました。
現場で役立つシステム設計の原則、ようやく読み終わった。大事だと思う所に付箋。
インスタは大体ツイッター連携してるので、ツイッターにも流れまして・・・。
そしたら・・・
なんと！著者さまが反応してくださって、心臓飛び出るかとw
食べてたチキンのフライ吹きそうになった・・・
どこに付箋を貼ったのか興味を持ってくださってたみたいです。
今度こちらの読書会に行く予定でして。
その際は他の参加者さんの見解などを見聞きするのが大変楽しみなんですが、とりあえず現時点でちょっと感想をまとめておこうかと。
第１章
光の速さで付箋をつけたのはこちら。
１つの変数を使いまわして代入を繰り返す書き方を破壊的代入と呼びます。
破壊的。ほんとですね・・・。私、金融系のシステム開発が一番長いこともあって計算ロジックのとこでこれやっちゃうとヒドイ目に合うの、すごくわかります。
あと、やっぱり値クラス。
「数量」は単なるintではありません。「電話番号」は単なるStringではないのです。
正直言って後頭部殴られた感覚・・・。今までDB設計したあと、実装はホント慣習でテキトーにIntegerやStringで扱ってた・・・( ；∀；)
Telephone型の例はとてもわかりやすくて、現場のシステムだったらどんな感じで当てはめたらいいかなぁ〜ってぐるぐる考えてました。
最近ほぼ全部のソースを読む機会に恵まれてまして、何気に気づいた・・・
えっ？Telephoneクラスあるやん・・・_:(´ཀ`」 ∠):
3年近く開発してるのにこんなクラスあるの気づかなかった・・・（爆）
あ、でもクラスは存在しているんだけれど、ホント一部の機能でしか使われてなくて存在感がとっても薄かった・・・。
これはちゃんと整頓して実現させたいですね。もちろんチームの同意を得るためにサンプルコードとか書いて提案してみないとですが。
第２章
Enumを使用した状態遷移の表現、つい最近もステータスの表し方でチームメンバーが頭を悩ませていたこともあってすごく身近に感じましたw
そうかー、こういうやり方があったか！と。
第３章
業務データと業務ロジックを一緒にしたドメインオブジェクトを設計するときに、どのパッケージに置くべきか、そしてどのパッケージの内容を知っていてもよいか／知っていてはいけないかを整頓し、改善を続けることで、業務ロジックの全体的な関係が明確になってきます。
今のチームのソースはかなり綺麗な方だと自負しているのですがw、それでもこのロジックやサービスクラスってこのパッケージでいいのかなぁ・・・わかりにくくないかなぁ・・・と悩んだりすることもあります。
改修のチャンスがあれば、ちゃんと検討して改善するのはいいことなんだなぁとちょっと自身が湧いてきました。
第４章
ドメインモデルの考え方についてとても詳しく説明されていて、今後もいろんな本を読んで勉強する予定です。
一番激しく同意したのはこちら。
分析・・・人間のやりたいことを正しく理解する
設計・・・人間のやりたいことを動くソフトウェアとして実現する方法を考える
頭では理解できていても、人に説明するときにわかりやすく良い表現ってなかなか出来ないものですよね。それがとても簡潔に表現されていて感激しました。
あと、業務への理解というのはシステム開発者としては永遠の勉強のテーマだと、私は思っているのですが、こちらも激しく同意しました。
文書で体系化した情報、現場で実際に使われている場面や帳票や資料、そして業務の経験者との会話。これらを常に組み合わせながら対象業務の知識を広げて行きます。
第５章
サービスクラスについては、今のチームのソースはほとんど実現が出来ていてかなりほっとしましたw
きっと最初にルールを決めて書いて、展開してくださった方のおかげです。
あと、ちょっとデカいなぁと思った既存のサービスクラスはぶっ潰して解体、小さくリファクタリングしたりしてますwww
第６章
値クラス使ってない！の次にやっちまったーーー😅 と思ったのがこの章w
テーブル設計なんですけど・・・NULL値が入ったテーブルある・・・
そのせいでプログラムも超ダサいことに・・・API・・・
ちゃんとテーブル分けたらよかったんですね・・・そっか・・・
そして一番笑った部分はここ。
もっとひどい設計が「自由項目」や「予備項目」と呼ばれるカラムです。
出たーーーーーーー！！！予備項目！！！
その昔とあるシステムでカラムが１５０個ぐらいある汎用的なテーブルがあって、あるお店のデータならカラム１３には住所が入ってるけど、他のお店のデータならカラム１３には顧客の性別が入ってる、みたいなのに遭遇しましたね。
ソース側は何が何だかですよ。読んでもさっぱりテンション上がらない。
予備項目職人だったら「ああ、カラム１３か。あの店だったら住所だよね。」とか即答しそうですけどね（こら
第７章
うちのチームのシステムでは画面側（テンプレートエンジン）はThymeleafを使ってまして、画面側で色々出来てしまう（そして読みやすい）ということもあり、実装者によって法則がまちまちになりがちです。
ソースレビューで読んでてちょっと辛いなと思ったら「出来ればJava側で編集しておいてから画面側は表示だけにしない？」と提案することにしています。
そういう意味ではこちらはとってもぴったりで納得できるな、と。
画面まわりのロジックから業務のロジックを分離する
第８章
WEB APIの仕組みについてわかっているつもりでしたが・・・ちゃんと整頓立ててもう一度勉強させていただいた、という気分です。
いかに私はノリで開発してるかってことですね😜
最近チームでAPIを根本的に見直そうと話し合ったこともあって、この章はかなり参考になること間違いなしです。
第９章
うちのチームでは設計と開発、テストまでを原則同じ人間でペアプロすることにしています。「原則」と書いたのは途中で1人を残してペアの組み替えをすることがあるので。
それと、ドキュメントに関しては開発する前のイメトレや課題調査のアウトプットとしています。処理の大まかな流れだけ書いて、詳細はソースを読めば良いし。
しかし、最近特に考えていることがあります。古参メンバーがいなくなってしまい、既存処理がなぜそうなっているかの理由（歴史？）がわからなくなってどハマりするという苦い経験をしました。であれば、理由や歴史はドキュメントに書いておいた方がよいのではないかと。
・・・と、この章読んだら答えが書いてあったw
やっぱ分析時の資料は残しておいた方が良いのですね。
ホワイトボードなどでラフスケッチなど書いて写真を撮ってアップしておいたり・・・
第１０章
オブジェクト指向の学び方・・・結局、なんとなくずっとJavaを書いてきたけれど実際自信を持ってオブジェクト指向！身についてますよ！と断言できるのかどうか・・・。
ただ、私が恵まれているなぁと思うのは・・・
- 新規開発の現場も行ったけれど、保守開発の経験が長かった
- 今のチームで設計改善も含む開発の機会を得ている
ということでしょうか。
面白そうな本もたくさん紹介していただいているので、読んでみようっと。
これとか。
