リーダブルコード輪読会 第13章 === # ディスカッションをより豊かにするためのグランドルール - 参加者は毎回任意 - 途中参加・聞くだけでもOK！ - ページ数と同時に、節のタイトルやキーワードを記入してもらえると探す手間を省けて嬉しいです - ファシリテーターや話している人は集中しがちなので、話していない人に議論内容をメモ:pencil:してもらえると嬉しいです - 気になる質問や同感するものには :+1: を末尾につけてください。 - 社外秘情報は書かないこと!!! - オープン設定で誰でも見れてしまうので # タイムテーブル | 時間 | 所要時間 | 内容 |備考 | | -------- | -------- | -------- | -------- | | 15:00 | 5-10分? | (書いてなければ)感想記入&書かれた感想・気づき・疑問をもっと掘り下げたいものを、 :+1: 付けていく | | | 15:10? | 40-45分 | 本の節ごとにディスカッション | | |15:55? | 5分 | 次回読む範囲決めてクローズ | | ## 下に感想などを書いていって下さい。どんな些細なことでもOKです。 --- # 序章、13.1 その機能の実装について悩まないで ——きっと必要ないから ## 感想・気づき - いつでも機能を削除できるようになっている = 保守性が高い状態ってのをどこかで見たけど忘れた - Googleとか突然機能消したりするけど、コードの影響とか把握できてないと無理だよね的な話 - 今必要ないよね、と思考停止の切り分けは難しい - [この問題に触れているスライド](https://www.slideshare.net/kawasima/yagni) - :memo:作り込んでも使わないことが多い - :memo:実際に変更するときになると、もっと良い手段が思いつくかも - :memo:その時のベストが一番では？ - 実装にかかる労力を過小評価する > 実感している ### 実践してる人 #### 書籍通りのやり方をしているか。または、何か違う点はあるか。 ### 実践してない人 #### 簡単に導入できそうか。難しいと感じた場合は、何が引っ掛かりそうか。 - 実装するかどうか自分たちで決められない時がままある - :memo:お客さんとの調整で納得感がないまま実装することがあるか？ - :memo:納得感がないまま実装すること自体は良くない - :memo:どうしても実装しないといけない場合はミニマム実装にする ## 疑問 # 13.2 質問と要求の分割 ## 感想・気づき - 制約の付け方は難しい - どこまでを制約とするか利害関係者で認識を一致できていれば簡単に割り切れるけど、現実は難しい… - この方法なら圧倒的に簡単にできる、ただしこういう制約ある、というの明示できれば早く合意をまとめられそう - 正しく要求を分析できているからこそ、この例みたいな制限を付けれるなと思った - こういうアプローチするには、要求分析など別のスキルが欲しくなる - :memo:人と話すのが一番スキル伸びるよね - 上のコメントの関係者うんぬんは要求レベルを統一できてないから起きてるのかなと思ったり - 機能の核となるのはどの部分か、それに付随する処理は顧客価値に繋がるものなのかとか考えて細分化すると見えてくるものはあるだろうけど、全部にやるのも難しいかな... - 「近くの州も追加したい」という追加要求があがってもいいように拡張性は持たせておきたい。が、どこまで拡張性を持たせるかの匙加減は難しい。 > テキサス州のユーザのために、テキサスで最も近くにある店舗を検索する。 - :memo:お客さんに将来の展望を聞いてみる - :memo:欲しそうかどうか感触を掴む程度 - :memo:似たような機能を調べるアプローチも ### 実践してる人 #### 書籍通りのやり方をしているか。または、何か違う点はあるか。 ### 実践してない人 #### 簡単に導入できそうか。難しいと感じた場合は、何が引っ掛かりそうか。 ## 疑問 # 13.3 コードを小さく保つ ## 感想・気づき - 「いつか使うかも」と考えていると使わないコードがどんどん増えていく… - いざ使おうと思った時にバグが潜んでいることも多い:+1: - 変更管理の厳しいプロジェクトだと、小さく保つためのモチベーションが薄くなりそう - :memo:影響範囲を狭めようというフォースが強くなりがち - > プロジェクトをサブプロジェクトに分割する。 - 1/29のクリーンアーキテクチャ著者ボブおじさんの講演でもマイクロサービスに触れてたが意見は真逆 - 分割する労力は大きいし変更が入ると痛みも大きい割に得られるものは少ない - 適切にレイヤー分割し責務を分離できていればモノリスなシステムでいいはずだ的な話だった ### 実践してる人 #### 書籍通りのやり方をしているか。または、何か違う点はあるか。 ### 実践してない人 #### 簡単に導入できそうか。難しいと感じた場合は、何が引っ掛かりそうか。 ## 疑問 - 使っていない機能やコードを削除しようと思うきっかけあれば教えてください - :memo:UTでカバレッジ取るとかしたいけど... - 「コードの重量」は単純に行数だろうか？ - :memo:やってることが多いかどうか - :memo:命名に悩む箇所は怪しい - :memo:リーダブルでないコード # 13.4 身近なライブラリに親しむ ## 感想・気づき - 言語の機能追加により簡潔に書き直せることはあるけど、つい昔の書き方をしてしまう場合がある - 変更入れるときに合わせて変更することもあるけど、それ以前の書き方と混在して気持ち悪くなることもままある:+1: - 知らないと気づけないので勉強するしかないかなあ...:+1: - なので日々の業務時間で学習時間作るの大事だよねって話にもなってくる - .NET FrameworkやJavaの標準ライブラリはMicrosoftやOracleの頭のいい人たちが作ったものなので、実装内容だけでなくクラス構成なども参考になる。 - 外部ライブラリ(OSSなど)はバージョンアップをいつ誰がどう判断して入れ込むかなどの行政が必要になるので、本当に使わないといけないのかは検討した方が良い。 ### 実践してる人 #### 書籍通りのやり方をしているか。または、何か違う点はあるか。 ### 実践してない人 #### 簡単に導入できそうか。難しいと感じた場合は、何が引っ掛かりそうか。 ## 疑問 # 13.5 例:コーディングするよりも Unix ツールボックスを使う ## 感想・気づき - コードの書き方、というよりありもののツールの組み合わせで問題解決できる場合あるよ、という例だと理解 - この例だと、似たような解析に使えるからコード化しても良いのかもと感じるが...背景情報ないのでなんとも言えない ### 実践してる人 #### 書籍通りのやり方をしているか。または、何か違う点はあるか。 ### 実践してない人 #### 簡単に導入できそうか。難しいと感じた場合は、何が引っ掛かりそうか。 ## 疑問 # 13.6 まとめ ## 感想・気づき * 書かずに済むなら書かずに済ませたい:+1: ## 疑問 - 似たようなライブラリがある時、どう選ぶ？ - 星の数、最後の更新、ユーザ数(情報量) - ライセンス確認大事 - 過去の脆弱性問題