リーダブルコード輪読会 第10章 === # ディスカッションをより豊かにするためのグランドルール - 参加者は毎回任意 - 途中参加・聞くだけでもOK！ - ページ数と同時に、節のタイトルやキーワードを記入してもらえると探す手間を省けて嬉しいです - ファシリテーターや話している人は集中しがちなので、話していない人に議論内容をメモ:pencil:してもらえると嬉しいです - 気になる質問や同感するものには :+1: を末尾につけてください。 - 社外秘情報は書かないこと!!! - オープン設定で誰でも見れてしまうので # タイムテーブル | 時間 | 所要時間 | 内容 |備考 | | -------- | -------- | -------- | -------- | | 15:00 | 5-10分? | (書いてなければ)感想記入&書かれた感想・気づき・疑問をもっと掘り下げたいものを、 :+1: 付けていく | | | 15:10? | 40-45分 | 本の節ごとにディスカッション | | |15:55? | 5分 | 次回読む範囲決めてクローズ | | ## 下に感想などを書いていって下さい。どんな些細なことでもOKです。 --- # 序章、10.1 入門的な例:findClosestLocation() ## 感想・気づき - エディタやIDEの機能が充実したから、この手の抽出は簡単にできるようになったなあ - おー！ こんな機能があること始めて知りました。IDEの機能を把握するのも大事ですね。:+1::+1: - 下位問題の抽出と言われると？だけど、関心の分離と言われると納得 - >完全に自己完結しているので、自分がアプリケーションにどのように使われるかを知らないのだ。 - これ大事。使われ方を意識しないといけないコードは繊細で簡単にデグレるイメージ - リファクタの筆頭候補になる ### 実践してる人 #### 書籍通りのやり方をしているか。または、何か違う点はあるか。 - 以前の章で話したが、コードブロック単位で別メソッドに抽出できないか検討するのが最初の1歩 - 後はクラスの責務に合ってるか、など他のコードとの兼ね合いで抽出したり移動させたりすることが多い ### 実践してない人 #### 簡単に導入できそうか。難しいと感じた場合は、何が引っ掛かりそうか。 - 10.8との兼ね合いの判断が難しい ## 疑問 - # 10.2 純粋なユーティリティコード ## 感想・気づき - ユーティリティコードは名前でだいたい悩む:+1: - そして似た名前のメソッドがずらりと並ぶ事案 ### 実践してる人 #### 書籍通りのやり方をしているか。または、何か違う点はあるか。 - ### 実践してない人 #### 簡単に導入できそうか。難しいと感じた場合は、何が引っ掛かりそうか。 - ## 疑問 - 歴史の長いプロジェクトだと、同じようなユーティリティコードをまた実装してしまう場合がある。どう回避しようとしてるか、作戦などあれば教えて欲しい - ↑たしかに。他の人から引き継いだ時に、ゴリゴリ書いていたらすでにUtilあるじゃん！みたいなことはあった。 - ↑Utilがあるけどバグが多くて、よくよく確認するとテストしていない（作ったけど使わないからテストしない）ようなケースもあった。Utilの行政については他の人達がどうしているのか知りたい。 - 似てるけどちょっと違うメソッドを付け足したくなる時があります。影響が怖いので追加しますがどうしたらいいのか。 - JavaやC#などならオーバーロードで解決できるケースがありそう # 10.3 その他の汎用コード ## 感想・気づき - 一度しか出てこないコードの場合、動作するのを優先させてしまい、関数・メソッドへの抽出をサボりがちになってしまう傾向がある - 汎用コードの命名は要注意。汎用的な名前は誤用を招く恐れがあるので - そして誤ったDRY原則で使いまわされ、if分岐が生えていく... ### 実践してる人 #### 書籍通りのやり方をしているか。または、何か違う点はあるか。 - 1回しか使われないコードを抽出するかはチーム方針によるので、厳密に守ってるわけではない - 命名に悩んだときは放置してしまうことも正直ある ### 実践してない人 #### 簡単に導入できそうか。難しいと感じた場合は、何が引っ掛かりそうか。 - ## 疑問 # 10.4 汎用コードをたくさん作る ## 感想・気づき - 同じ言語を使い続けられる環境なら蓄積しやすいが、アサインされたプロジェクトによって言語が違う場合は蓄積しづらそう ### 実践してる人 #### 書籍通りのやり方をしているか。または、何か違う点はあるか。 - ### 実践してない人 #### 簡単に導入できそうか。難しいと感じた場合は、何が引っ掛かりそうか。 - ## 疑問 - メソッドを書くときにどう使われるか意識してますか？ - 汎用コード≒ライブラリを作るようなイメージなので、そうなると使われることを意識しなければならないと思うが... - UTを書ける場合はテストコードを書く必要があるので、使いやすいかどうか早めにわかりやすい # 10.5 プロジェクトに特化した機能 ## 感想・気づき - 汎用的なメソッドを切り出したらいろんなところから使えるようにしがちだけど、たしかにあとできめるでもいいか - アメリカのビジネス名というのをもう少し命名で表現できれば、いろんなところに見えてても良さそうな気もする - メソッド名が汎用的だと、プロジェクトに特化したことがわからないまま使いまわしてしまうかも(しまった）。この場合、どう回避したらいいのか。コメント？命名？ ### 実践してる人 #### 書籍通りのやり方をしているか。または、何か違う点はあるか。 - 本当に汎用コードになるものは少ないと思うので、基本は公開範囲を限定するかなあ - プロジェクトが大きいと、似たものが量産されるリスクはあるので境界が難しいが... ### 実践してない人 #### 簡単に導入できそうか。難しいと感じた場合は、何が引っ掛かりそうか。 - ## 疑問 # 10.6 既存のインタフェースを簡潔にする ## 感想・気づき - ラッパークラスは腐敗防止層の役割になるので、そこの改修がツラくなる問題はある - より疎結合になり、使う側が楽できるなら検討すべき ### 実践してる人 #### 書籍通りのやり方をしているか。または、何か違う点はあるか。 - ### 実践してない人 #### 簡単に導入できそうか。難しいと感じた場合は、何が引っ掛かりそうか。 - ## 疑問 # 10.7 必要に応じてインタフェースを整える ## 感想・気づき - これは、「プロジェクトに特化する」の言い換えなのかなと思った ### 実践してる人 #### 書籍通りのやり方をしているか。または、何か違う点はあるか。 - ### 実践してない人 #### 簡単に導入できそうか。難しいと感じた場合は、何が引っ掛かりそうか。 - ## 疑問 # 10.8 やりすぎ ## 感想・気づき - どれくらいの粒度が良いかは肌感覚で、まだ言語化できていない - 1回しか使われないやつはその筆頭ですね... - 個人的には、使う側の変更が多く、使われる側の変更が少ない場合はやっても良いと判断することが多い - :memo:抽出してネスト改善されるか ### 実践してる人 #### 書籍通りのやり方をしているか。または、何か違う点はあるか。 - ### 実践してない人 #### 簡単に導入できそうか。難しいと感じた場合は、何が引っ掛かりそうか。 - ## 疑問 - やりすぎかの判定はやっぱりレビューするがいいのでしょうか。個人で考えると変な風にはまりそう。 - :memo: 抽出したロジックの名付けができるかどうか - :memo: チームで合意取るのが無難そう、開発メンバーであればわかりやすいかの感覚は似てるはず # 10.9 まとめ ## 感想・気づき - [Composed Methodの紹介](https://qiita.com/tbpgr/items/06266a4161019b445756) - > メソッド内の抽象度を揃え、低いレイヤーの処理を隠蔽することで、メソッド内を英文のように、人間が読みやすい形にします。 - 細かいテクニックはファウラーの「リファクタリング」を読みなさい。以上！ - この章を読んでて[流れるようなインターフェース](https://bliki-ja.github.io/FluentInterface/)を思い出した ## 疑問