「普通のプログラマの普通の設計」(勉強会)に参加してみた感想

はじめに

「普通のプログラマの普通の設計」という勉強会に参加したので、

勉強会での内容を気になったポイントに絞ってまとめ、僕の解釈や感想も書いてみました。

>>普通のプログラマの普通の設計

 

2022/3/22追記

今まで僕が参加した回の

現場から学ぶモデル駆動設計の勉強会での学びや気付きなどについて

まとめ記事を作ってみました。

現場から学ぶモデル駆動設計勉強会のまとめ記事

 

「普通のプログラマの普通の設計」(勉強会)の内容

 

「普通の設計」をするということ(綿引 琢磨さん)

>>発表資料

 

テストコードは書かない派で、必要な時は渋々書く!!とのことでした。

 

脳内でオブジェクトたちを妄想して動かしてテストする

→コードを書く→クラス図に書く→配置や想定外の依存確認・修正→クラス図での発見をコードに反映

という流れで設計をしている。(2周3周とこれを回す)

 

まずは妄想からスタート。。。物凄い訓練が必要そうだと感じましたが、

 

綿引さんは、

OSSのソースを落として読み込みされるそうで、

普段からソースコードめちゃくちゃ読んで、読むときにには脳内でいろんなオブジェクトが登場して

やりとりしてるからそんな感じでやれるんだろうなという印象でした。(これが普通か。。。。)

 

 

美しいコードを追い求めることが普通の設計であり、

美しいコードとは簡潔で統一性がありテストしやすく形式美であること

 

簡潔というところで1クラス50行、読み込みパッケージ3つ、フィールド3つ、メソッド5つ

を目安にされているそうで、その方針だと1クラスであれもこれも詰め込んで無茶苦茶なクラスにはならないのだと思います。

1クラス50行に抑えているから脳内でオブジェクトの妄想ができるし、

テスト書かなくてもいいくらいシンプルになっているのかなと思いながらこの話を聞いていました。

 

同じ振る舞いをするところには同じ名前を、違うなら別の名前をつけましょうという話、

(テストしない方針でも)テストしやすいコードは美しいコードになると言う話、

手続き的に書かないようにとかネスト深くならないようにと言う話・・・・この辺りは普通の話だったので少し安心でしたが、、、

やはりこう言う当たり前のことを当たり前に一貫してやれることが美しいコードにつながり、基本的だけど一番重要なことなんだな。

と改めて感じました。

 

 

パッケージングはコードの表現と同じくらい重要で、構造、境界、カプセル化など意識してパッケージングを考えられるかどうかで、

プログラマーとして差が出る。

 

ここは自分の中では意識しているつもりですが、、、

改めて言われると、見直してみようと思います。。。。

 

おそらく、

このように考えられているのはOSSのコードを読み込んで、

パッケージングがカチッとされているのとそうでないのとを見比べた経験があるからなのだろうなと思いながら話を聞いていました。

 

 

ふつうの設計の基本要素(irofさん)

>>発表資料

 

設計の勉強としてはとにかくやろう!!本を読んで自分の設計やモデリングの引き出しを増やし、

勉強するものは取捨選択(異なるコンテキストで3回出たものは勉強するとか)

 

現場での設計経験だけでなく、設計やモデリングの引き出しを増やして、その引き出しを使って

設計の良し悪しを判断できるようになっていく必要があるのだと感じました。

ただ、勉強に使える時間は限られるので、取捨選択をどうしていくかというのも意識しましょうね。という話でした。

異なるコンテキストで3回でたら勉強必須!!!意識してみよう、、、

 

設計のコアは名前付け。同じ振る舞いのものには一貫して同じ名前を、モデリングで付けた名前を一貫してコードでも利用。

 

綿引さんも同じようなことを仰られていたので、

設計がものすごい出来る人たちがやっていて自分たちもすぐ実践できる話だと思うのでまずはこの辺りを徹底することから、

自分の設計を見つめ直していくか。。。

 

雑談

 

本を読んだり勉強会参加したり、ライブラリやフレームワークのコード読んだりを積み重ねて設計ができるように。(irofさん)

性能最優先で動いて性能が良ければいい。というところからカオスなコードのリファクタを通じて設計を意識するように。(増田 亨さん)

gradleのコードを読んで美しいコードに出会えて設計への意識が変わった。(綿引 琢磨さん)

 

この辺りのエピソードや、

 

自分の考えを人に正しく伝えられる文章力がある人はコーディングでも人に正しく伝えられる。

 

などなど、色々話が聞けました。

(増田さんOracleだったんだ。。。)

 

 

まとめ

自分は今まで、

現場で設計することが設計の力をつけるのは一番大事くらいに考えていましたが、

 

それだと、自分の設計の引き出しはなかなか増えない。

 

  • OSSなどのある程度規模の大きいソースコードをざっくりとでも読む。
  • 勉強会や設計やモデリングの本を読む。

 

などを実践して設計の良し悪しが比較できるくらい設計の引き出しを増やすことが重要

というように、考えを改めるべきだと今回の勉強会を通じて感じました。

 

 

僕は現場で性能重視でとにかく正しく性能良く動いて、納期守れれば良い。

という考え方で開発の旗振り役をやってしまっていましたが、、、

それだと今日あったふつうの設計にはまだまだ程遠いんだなと。。。反省です。。

コメントを残す

メールアドレスが公開されることはありません。

このサイトはスパムを低減するために Akismet を使っています。コメントデータの処理方法の詳細はこちらをご覧ください