academist-reading.connpass.com
「良いコード／悪いコードで学ぶ設計入門」読書会 第1回 を開催しました。
みんなで書いたホワイトボード
感想
はじめに
- 「悪魔」「クソコード」「負債」の表現、荒みそう→「伸び代」「後払い」みたいな言い換えが出てきてよかったです。
1.1 意味不明な命名
- 連番命名
- 書き捨てのコードでファイル名、メソッド名に使うことはあったかも。
- 大規模開発で設計ドキュメントの番号をそのまま使った連番命名のよさそうさと、改修でドキュメントの番号体系が狂ってきたときの崩壊の話が興味深かったです。
- 機能追加で番号の間に入れられそうにない場合に…という話を聞いて、BASICの10番ごとの行番号みたいに少し広めにしとけば…と言おうとしてやめました…。
- BASICってなに？みたいな雰囲気でした。
- 機能追加で番号の間に入れられそうにない場合に…という話を聞いて、BASICの10番ごとの行番号みたいに少し広めにしとけば…と言おうとしてやめました…。
1.2 理解を困難にする条件分岐のネスト
- 多重のif、間の行数がスゴイ、インデントが多様なのに会ったことが…辛かったです…。
1.3 さまざまな悪魔を招きやすいデータクラス
- 1章まで読んだだけのときに、データクラスが悪魔のように感じたひとも多かったみたいです。
- 話している中で、バリデーションについて、2種類くらいありそうに感じました。
- クラスが不正な状態にならないためのバリデーション
- サービスのデータとして受け入れられるかどうかのバリデーション
- 重複しているコードが「業務上の意味」を実現しているのかたまたまそういうふうに見えるのか、判断が難しいという話は…なっとく。
- やってること、ほぼおんなじだから…とフラグを付けて処理を分岐させるコードがあとから負債化している例をたくさん見てきました。
1.4 悪魔退治の基本
- ここまで読んできて、悪い設計の弊害を知らないと対処しないかも…と思いました。
- 痛い目にあっていても、なんかツライな…くらいに思うくらいで、チームの話題にできないと、改善までいかない…というか。
- 名前をつけたり、みんなで同じ本を読んだり…みたいにしてチームを底上げしないと手が出ない感じです。
- 実際にチームで勉強会しようとしたけどうまく続かなかった話をしてもらいました。
- 本は実際の現場のコードと距離があって、なかなかしっくりこなかった…。
- 現場のコードのレビュー時に、ちゃんと指摘したり、指摘の解説をチームにする場を設けたりして底上げ
- これ、超大変ですね……。ホント、スゴいと思います…。
運営としてのふりかえり
KPT方式で。
Keep
- 初心者から経験豊かな方まで、割と幅広く来てもらえました。
- たぶん、立場もいろいろ、職場もいろいろだったと思います。
- 結構しゃべってくださる方が多くて、助かりました。
- ホワイトボードにたくさん書いてもらえた…！
- スタンプっぽい画像を用意したら、なんかいっぱい使ってもらえました！
- 感想を書いてとお願いしたら、たくさん書いてもらえました。
Problem
- 時間が短かった気がしました。
- しゃべりたかったのにしゃべれなかった方がいなかったか心配です。
- 早口だったかもしれません…。
Try
- 誰が誰かわかりやすいかもしれないので、connpassの名前とmeetの名前を揃えてもらうようにお願いします。
- もう少し落ち着いて話します…。
おわりに
参加してくれたみなさん、ありがとうございました！ あとでざっと見直しても、一人で読むより圧倒的に気づくことが多いので、今後も継続してやっていきたいと思います！
