リーダブルコード輪読会 第15章 === # ディスカッションをより豊かにするためのグランドルール - 参加者は毎回任意 - 途中参加・聞くだけでもOK! - ページ数と同時に、節のタイトルやキーワードを記入してもらえると探す手間を省けて嬉しいです - ファシリテーターや話している人は集中しがちなので、話していない人に議論内容をメモ:pencil:してもらえると嬉しいです - 気になる質問や同感するものには :+1: を末尾につけてください。 - 社外秘情報は書かないこと!!! - オープン設定で誰でも見れてしまうので # タイムテーブル | 時間 | 所要時間 | 内容 |備考 | | -------- | -------- | -------- | -------- | | 15:00 | 5-10分? | (書いてなければ)感想記入&書かれた感想・気づき・疑問をもっと掘り下げたいものを、 :+1: 付けていく | | | 15:10? | 40-45分 | 本の節ごとにディスカッション | | |15:55? | 5分 | 次回読む範囲決めてクローズ | | ## 下に感想などを書いていって下さい。どんな些細なことでもOKです。 --- # 序章、15.1 問題点 ## 感想・気づき ### 実践してる人 #### 書籍通りのやり方をしているか。または、何か違う点はあるか。 ### 実践してない人 #### 簡単に導入できそうか。難しいと感じた場合は、何が引っ掛かりそうか。 ## 疑問 # 15.2 クラスのインタフェースを定義する ## 感想・気づき - > 仮引数の num_bytes という名前は具体的すぎる。ここではバイト数を扱っているけど、MinuteHourCounter クラスがそのことを知る必要はない。 - これは本当にそうなのか? - このクラスの責務は転送バイト数の把握なので、そのままでいいと思う - この例の直し方だと、間違った共通化を促しているように見えてしまう - ジェネリクスでなんでも受け入れるような設計なら話は変わるが... - > count という名前 がいいだろう。単純だし汎用的だし「マイナスではない」ことがわかる。 - ネイティブじゃないとこの感覚は分からないのでツラいところ - p200-201 このコメントは"やりすぎ"に感じてしまう - MinuteCount(), HourCount()というメソッド名に違和感を覚えるのは自分だけ?:+1: - 「動詞+名詞」のメソッド名にしたくなる。 - 「直近1分以内のデータ数を計測する」の方がわかりやすい - `MinuteHourCounter`というクラス名にも違和感を感じる ### 実践してる人 #### 書籍通りのやり方をしているか。または、何か違う点はあるか。 ### 実践してない人 #### 簡単に導入できそうか。難しいと感じた場合は、何が引っ掛かりそうか。 ## 疑問 # 15.3 試案 1:素朴な解決策 ## 感想・気づき - > MinuteCount() と HourCount() のコードは数値が違うだけだ(60 と 3600) - 目的が一緒という説明を省くと誤解が(ry - パフォーマンスの問題はドメイン知識もかなり必要になるので、設計やる人コード実装する人の間で情報分断あるとしんどいだろうなと感じた - :memo: まずはsetterでループなど重いことしてないか意識する ### 実践してる人 #### 書籍通りのやり方をしているか。または、何か違う点はあるか。 ### 実践してない人 #### 簡単に導入できそうか。難しいと感じた場合は、何が引っ掛かりそうか。 ## 疑問 # 15.4 試案 2:ベルトコンベヤー設計 ## 感想・気づき - 二段回方式はパフォーマンス優先で複雑さを許容しているが、複雑さはバグを誘発するのでコーティングスキルを求められると感じた(時間周りはテストはしづらいので特に - Listの追加/削除はバグ混入しやすいので注意して見ることが多い ### 実践してる人 #### 書籍通りのやり方をしているか。または、何か違う点はあるか。 ### 実践してない人 #### 簡単に導入できそうか。難しいと感じた場合は、何が引っ掛かりそうか。 ## 疑問 # 15.5 試案 3:時間バケツの設計 ## 感想・気づき - 時間や数値の丸め誤差はよく引っかかる注意すべきやつ - この辺の問題はドメインがどのレベルの粒度を求めているのか分析するところから必要なので、コーディングよりも仕様検討に時間かかるイメージ - メモリの使用量はプロファイラなどを使わないと気付きづらい… - `MinuteHourCounter`のコンストラクタ ラベル付き引数のようなコメントは読みづらい ### 実践してる人 #### 書籍通りのやり方をしているか。または、何か違う点はあるか。 ### 実践してない人 #### 簡単に導入できそうか。難しいと感じた場合は、何が引っ掛かりそうか。 ## 疑問 # 15.6 3つの解決策を比較する ## 感想・気づき - 比較の表を見ると、計算量やメモリ使用量を最適化するリファクタ結果が一目でわかっていい - > 問題を複数のクラスに分割すると、複数のクラスになったことが原因で複雑になる こともある(クラスが 1 つなら発生しない複雑さだ)。 - 設計で何を考えてこうしたか説明があった上でコード読んでいるので理解できるが、いきなりコードだけ出されたらツラいところもあったと思う - WFみたいに設計と実装でフェーズが分かれると情報が分断されて(もしくは担当者すら変わっていて)この辺の問題が顕在化しやすいのでは?と感じた ### 実践してる人 #### 書籍通りのやり方をしているか。または、何か違う点はあるか。 ### 実践してない人 #### 簡単に導入できそうか。難しいと感じた場合は、何が引っ掛かりそうか。 ## 疑問 # 15.7 まとめ ## 感想・気づき - パフォーマンスの話などドメインらしい話題が絡むので読み応えあった章 - 業務でも意識すべき点が出ているので、できているかふりかえりのきっかけになった ## 疑問
×
Sign in
Email
Password
Forgot password
or
By clicking below, you agree to our
terms of service
.
Sign in via Facebook
Sign in via Twitter
Sign in via GitHub
Sign in via Dropbox
Sign in with Wallet
Wallet (
)
Connect another wallet
New to HackMD?
Sign up