リーダブルコード輪読会 第11章 === # ディスカッションをより豊かにするためのグランドルール - 参加者は毎回任意 - 途中参加・聞くだけでもOK！ - ページ数と同時に、節のタイトルやキーワードを記入してもらえると探す手間を省けて嬉しいです - ファシリテーターや話している人は集中しがちなので、話していない人に議論内容をメモ:pencil:してもらえると嬉しいです - 気になる質問や同感するものには :+1: を末尾につけてください。 - 社外秘情報は書かないこと!!! - オープン設定で誰でも見れてしまうので # タイムテーブル | 時間 | 所要時間 | 内容 |備考 | | -------- | -------- | -------- | -------- | | 15:00 | 5-10分? | (書いてなければ)感想記入&書かれた感想・気づき・疑問をもっと掘り下げたいものを、 :+1: 付けていく | | | 15:10? | 40-45分 | 本の節ごとにディスカッション | | |15:55? | 5分 | 次回読む範囲決めてクローズ | | ## 下に感想などを書いていって下さい。どんな些細なことでもOKです。 --- # 序章、11.1 タスクは小さくできる ## 感想・気づき - サンプルを読めば読むほど、手動で動作確認が大変そうに感じる - ここでいうタスクは、最小限の関心ごとと個人的に解釈 - changedの関心ごとを整理してメソッド抽出していて、その結果changedはユースケース実現だけに注力できるようになってる - クラス設計的にも、ユースケースクラスとVoteクラスに分離など工夫の余地が生まれてる - 気が付くとタスクがごちゃごちゃに実装しているかも… - ### 実践してる人 #### 書籍通りのやり方をしているか。または、何か違う点はあるか。 - コード整理は何をしてるか見失いがちなので、大まかなコメントで道しるべを作ることが多い:+1: - 何かしら意味のわかる単位でブロック分けするが、この本の「タスク」と同じようなことをしていそう - メソッド内も関心ごとの分離は意識してる、そしてそれがリファクタのきっかけにもなる:+1: ### 実践してない人 #### 簡単に導入できそうか。難しいと感じた場合は、何が引っ掛かりそうか。 ## 疑問 - 最小限の関心事、の抽出の仕方でコツはありますか - :memo:データの変換 - :memo:コードブロック、メソッド内で引数、プロパティで使わないやつがいる - :memo:２３のデザインパターンを学ぶ - :memo:ロバストネス図のController,Entity,Boundary - :memo:一度動くものを作る、そして作り直す # 11.2 オブジェクトから値を抽出する ## 感想・気づき - ディクショナリは便利だけどその分扱い面倒になること多い - 何かしらクラスに置き換え、設計レベルで改善できないか検討しても良さそう - このコード例でもあるように、データのI/Fとビジネスロジックの処理は分離したいので、そこを意識した設計ができればどうとでもなりそう ### 実践してる人 #### 書籍通りのやり方をしているか。または、何か違う点はあるか。 - 「一度に1つのタスク」を適用する書き方も、デバッグしやすいなどのメリットはあるので、「その他の手法」までやらずそこで止めることもある - 条件に意図を含めるときは、省略して書けてもそのままにしておくことが多い ### 実践してない人 #### 簡単に導入できそうか。難しいと感じた場合は、何が引っ掛かりそうか。 ## 疑問 # 11.3 もっと大きな例 ## 感想・気づき ### 実践してる人 #### 書籍通りのやり方をしているか。または、何か違う点はあるか。 - コードを整理していると、当初考えていたことからかけ離れることがあるが下の行で安心できた - > ここでやったように、そこからいくつかに分割できれば、それでいいのだ - 良いコードになれば、そこから閃きが出ることもあるので、結果的に当初と形が変わってることがあるのはよくある話:+1: - なので、リファクタリングもインクリメンタルにやっていくと、どんどん設計改良できていいよねって話にも繋がる ### 実践してない人 #### 簡単に導入できそうか。難しいと感じた場合は、何が引っ掛かりそうか。 ## 疑問 # まとめ ## 感想・気づき - 「一度に1つのタスクを行う」は基本だけど肝なので、改めて意識したいなと感じた - :memo:設計アーキテクトがいなくなったら、設計の妥当性判断できなくて辛くなった話とか - :memo:経験少ない人がデザインパターンとか良い設計手法を学んで(WFフェーズの)詳細設計に挑んだらどうなる？ - :memo:変更が少ないならデザインパターンは不要だし、そんな大きな設計ミスは起きないと思う - :memo:今後変更がありそうみたいな勘所は経験がないと分からないので、設計の良し悪しの判断難しいのでは - :memo:設計の良し悪しを判断できるようになるためには、悪い設計例とかアンチパターンの蓄積がないと難しい気がする=経験を積み重ねるしかないのでは ## 疑問