釣りキチプログラマー翔平の備忘録 
はじめに
「普通のプログラマの普通の設計」という勉強会に参加したので、
勉強会での内容を気になったポイントに絞ってまとめ、僕の解釈や感想も書いてみました。
2022/3/22追記
今まで僕が参加した回の
現場から学ぶモデル駆動設計の勉強会での学びや気付きなどについて
まとめ記事を作ってみました。
「普通のプログラマの普通の設計」(勉強会)の内容
「普通の設計」をするということ(綿引 琢磨さん)
テストコードは書かない派で、必要な時は渋々書く！！とのことでした。
脳内でオブジェクトたちを妄想して動かしてテストする
→コードを書く→クラス図に書く→配置や想定外の依存確認・修正→クラス図での発見をコードに反映
という流れで設計をしている。(2周3周とこれを回す)
まずは妄想からスタート。。。物凄い訓練が必要そうだと感じましたが、
綿引さんは、
OSSのソースを落として読み込みされるそうで、
普段からソースコードめちゃくちゃ読んで、読むときにには脳内でいろんなオブジェクトが登場して
やりとりしてるからそんな感じでやれるんだろうなという印象でした。(これが普通か。。。。)
美しいコードを追い求めることが普通の設計であり、
美しいコードとは簡潔で統一性がありテストしやすく形式美であること
簡潔というところで１クラス５０行、読み込みパッケージ３つ、フィールド３つ、メソッド５つ
を目安にされているそうで、その方針だと１クラスであれもこれも詰め込んで無茶苦茶なクラスにはならないのだと思います。
１クラス５０行に抑えているから脳内でオブジェクトの妄想ができるし、
テスト書かなくてもいいくらいシンプルになっているのかなと思いながらこの話を聞いていました。
同じ振る舞いをするところには同じ名前を、違うなら別の名前をつけましょうという話、
(テストしない方針でも)テストしやすいコードは美しいコードになると言う話、
手続き的に書かないようにとかネスト深くならないようにと言う話・・・・この辺りは普通の話だったので少し安心でしたが、、、
やはりこう言う当たり前のことを当たり前に一貫してやれることが美しいコードにつながり、基本的だけど一番重要なことなんだな。
と改めて感じました。
パッケージングはコードの表現と同じくらい重要で、構造、境界、カプセル化など意識してパッケージングを考えられるかどうかで、
プログラマーとして差が出る。
ここは自分の中では意識しているつもりですが、、、
改めて言われると、見直してみようと思います。。。。
おそらく、
このように考えられているのはOSSのコードを読み込んで、
パッケージングがカチッとされているのとそうでないのとを見比べた経験があるからなのだろうなと思いながら話を聞いていました。
ふつうの設計の基本要素(irofさん)
設計の勉強としてはとにかくやろう！！本を読んで自分の設計やモデリングの引き出しを増やし、
勉強するものは取捨選択(異なるコンテキストで３回出たものは勉強するとか)
現場での設計経験だけでなく、設計やモデリングの引き出しを増やして、その引き出しを使って
設計の良し悪しを判断できるようになっていく必要があるのだと感じました。
ただ、勉強に使える時間は限られるので、取捨選択をどうしていくかというのも意識しましょうね。という話でした。
異なるコンテキストで３回でたら勉強必須！！！意識してみよう、、、
設計のコアは名前付け。同じ振る舞いのものには一貫して同じ名前を、モデリングで付けた名前を一貫してコードでも利用。
綿引さんも同じようなことを仰られていたので、
設計がものすごい出来る人たちがやっていて自分たちもすぐ実践できる話だと思うのでまずはこの辺りを徹底することから、
自分の設計を見つめ直していくか。。。
雑談
本を読んだり勉強会参加したり、ライブラリやフレームワークのコード読んだりを積み重ねて設計ができるように。(irofさん)
性能最優先で動いて性能が良ければいい。というところからカオスなコードのリファクタを通じて設計を意識するように。(増田 亨さん)
gradleのコードを読んで美しいコードに出会えて設計への意識が変わった。(綿引 琢磨さん)
この辺りのエピソードや、
自分の考えを人に正しく伝えられる文章力がある人はコーディングでも人に正しく伝えられる。
などなど、色々話が聞けました。
(増田さんOracleだったんだ。。。)
まとめ
自分は今まで、
現場で設計することが設計の力をつけるのは一番大事くらいに考えていましたが、
それだと、自分の設計の引き出しはなかなか増えない。
- OSSなどのある程度規模の大きいソースコードをざっくりとでも読む。
- 勉強会や設計やモデリングの本を読む。
などを実践して設計の良し悪しが比較できるくらい設計の引き出しを増やすことが重要。
というように、考えを改めるべきだと今回の勉強会を通じて感じました。
僕は現場で性能重視でとにかく正しく性能良く動いて、納期守れれば良い。
という考え方で開発の旗振り役をやってしまっていましたが、、、
それだと今日あったふつうの設計にはまだまだ程遠いんだなと。。。反省です。。
