良いコード/悪いコードで学ぶ設計入門を読む会

# 1章: 悪しき構造の弊害を知覚する ## 事前共有 ### 感想/気づき * 3重ネストくらいなら見慣れてるからOK,くらいに考えてしまう、、[gorillakun] ### 疑問 * 技術駆動命名は基本NGとあるけど、例えば対象ドメインが低レイヤそれ自体だったら問題なさそう？[name=gori] * あ、注釈から飛んだ10章見るに、この場合はOKとありますね。（それでもなるべくわかりやすい命名に変えるよう注意喚起されてますが、、）[name=gori] ## 当日議論 --- # 2章: 設計の初歩 ## 事前共有 ### 感想/気づき * （本書と意味合い違うかもですけど）2.1:短縮名NGのくだりで、SQLの長いSELECT文でテーブル名にalias貼ってると認知負荷高め、、[name=gori] * `prefecture`を`pf`とかにしてたり。 ```sql select mst.name as 名前 from #masterをmstに。これを"短縮名"と呼んでます master mst ``` * 2.9の例は値オブジェクト？ [name=gori] * ↑であってた。3.4.2記載の値オブジェクトの例にHPが載ってた。 * と思ったが、批判記事を見ると値オブジェクトパターンと言ってよいかは微妙っぽい。。 * finalについて * 変数を宣言するときに final を付けることで、定数のように一度だけしか値を代入できない変数を宣言することができる [name=あざらし] ### 疑問 * 再代入を使った方が良いケースはあるのか？ [name=あざらし] * 最適な例が思いつかない[name=gori] * カウントとか、閉じているプログラムだと再代入してもよい [name=あざらし] * 意味を持たせた再代入はOK、理由が無いならNG [name=あざらし] ## 当日議論 * APサーバの性能が低い問題で、DBサーバもといSQLで処理するのとかあった（fatefoxさん談）[name=gori] * Rustは言語レベルでイミュータブル[name=gori] --- # 3章: クラス設計 ## 事前共有 ### 感想/気づき * インスタンス変数に`final`つけるのはやったことあるけど、引数にまで`final`つけるのはやったことなかったな、、[name=gori] * 3.4記載の表3.２（設計パターンの例）に記載のパターンは４章以降で取り上げられるっぽい。[name=gori] * Javaだとイミュータブルなクラスにしたいなら`record`使えばいいんですね(まだ使ったことないけどw)[name=gori] * https://ja.m.wikipedia.org/wiki/Value_object * 良いクラスの構成には、インスタンス変数と正常に操作するメソッドが必要（p.24）[name=あざらし] * プリミティブ型だけでなく、独自の型定義をすることでバグを発生しにくくする（p.32）　[name=あざらし] * 善意でシステムに不要なメソッドを定義しないこと（p.33）　[name=あざらし] * デザインパターンという言葉は知っていたが、どのように組み合わせて使っていくものなのかやその効果をこの章を読むことで理解ができた。 [name=fatefox] ### 疑問 * 値オブジェクトに関する本書の解釈は[こんな批判がされてた](https://zenn.dev/339/articles/e3c174fdcc083e#value-object%E3%81%AE%E5%AE%9A%E7%BE%A9%E3%81%AB%E3%81%A4%E3%81%84%E3%81%A6%E3%80%81%E3%81%8A%E3%82%88%E3%81%B3domain-primitive%E3%81%AB%E3%81%A4%E3%81%84%E3%81%A6%E3%81%AE%E8%A3%9C%E8%B6%B3)[name=gori] * > 同一性がそれを構成する値によってのみもたらされるようなもののことを意味します。いわゆるメモリの位置と説明されるオブジェクトとして等価かどうかとか、各オブジェクトに割り当てられたその他のidが等しいかどうかとか、そういう事によって同一性が与えられる訳ではないものの事です。 * サンプルコードそれ自体は（正確な定義の）値オブジェクトから逸れてはないけど、単に「値をクラス（型）として表現する設計パターン」というところが問題ある、てことなのだろうか？[name=gori] * こういうテクニックのこと？ https://qiita.com/yachinco/items/b1a3602d6aa261f5f7c4 * 値オブジェクトに関する解釈についての記事です。http://www.code-magagine.com/?p=14109　[name=fatefox][time=Mon, Jul 17, 2023 10:34 PM] * 「完全コンストラクタ」というパターンの出所は、「オブジェクト指向における再利用のためのデザインパターン(改訂版）」https://www.sbcr.jp/product/4797311126/　が元のようです。[name=fatefox][time=Mon, Jul 17, 2023 10:34 PM] ## 当日議論 * 引数で渡ってきた値はそもそもいじらないのが暗黙知としてあるよね * Clangとか、構造体の考え方だとフィールドのみのクラスも出てくる * Moneyの計算のとこ、Javaの`BigDecimal`ってまさにこれだよね * https://www.tairaengineer-note.com/java-bigdecimal-add/ * ふるまいだけのクラスって、いわゆる"Utilクラス"とかだとありうるのか。。 * 業務システムはDBが本体なので、そこの設計が崩れていると終わる * レガシーなシステムをきれいに作り変えるのは難しい。。 * そのシステムがやりたい業務は何なのかを明らかにしないといけない --- # 4章: 不変の活用 ## 事前共有 ### 感想/気づき * 再代入は避けるべき　[name=あざらし] * ローカル変数にfinal修飾子をつける * 引数も同様に、再代入を防ぐためにfinal修飾子をつける * フールプルーフ…「人がミスをしようとしてもできないようにする工夫」のこと　[name=あざらし] * コード外とのやり取りを局所化(もう少し調べる)　[name=あざらし] * リポジトリパターン * リポジトリパターンは[この記事](https://zenn.dev/kohii/articles/e4f325ed011db8)が個人的にわかりやすかった[name=gori] * 不変にすることでデータを扱う意味を明確にして実装することができるため、人がコードを読む際の考慮事項が少なく済むと思いました。[name=fatefox] ### 疑問 * インスタンスの概念が分からない…　[name=あざらし] * クラスがあって、クラスからインスタンスを生成している * 極端な話、全ての変数、引数にfinal（※Javaの場合）をつけておけばOK??　[name=あざらし] * パフォーマンスに問題が生じる場合は可変にする * ex)大量データの高速処理 * ループカウンタなど、局所的にしか使われない場合も可変でOK * ミューテーター(Mutator)って、つまるところsetterと同義ってこと？[name=gori] * 基本的に意味合いは同じ * Mutator…setterをより高度化させたもの * setter…Mutatorを内包している ## 当日議論 * リポジトリとDAOの違い[name=gori] * https://blog.fukuchiharuki.me/entry/use-repository-and-dao-according-to-the-purpose * 関心が違うだけでほぼ同じ？ * 「完全コンストラクタ」と「値オブジェクト」について、あれこれ探して見ましたがやはりDDD(ドメイン駆動設計)の話に集約しそうです。(デザインパターンという意味合いで探ると、実際はもっと複雑そうでした。 [name=fatefox] * https://ja.wikipedia.org/wiki/%E3%83%87%E3%82%B6%E3%82%A4%E3%83%B3%E3%83%91%E3%82%BF%E3%83%BC%E3%83%B3_(%E3%82%BD%E3%83%95%E3%83%88%E3%82%A6%E3%82%A7%E3%82%A2) * 重たいクラスは作るな、という話が今後本を読み進めていると出てくるのでは？[name=あざらし] * ↑インスタンスを生成しまくるのよくないんじゃない？という文脈から。無数のクラスを集約してるルートクラスを考えてみる。これをインスタンス化しまくると確かにリソース逼迫しそうだが、そもそもクラスを設計が微妙なんじゃ？というお話。[name=gori] * `tmp`で再代入しまくる話のやつ、ふさわしい名前付けができてないことにも起因するのでは？[name=gori] * とはいえ命名ってセンスいるし、設計段階で決まることってほぼないよね。（だからムズい？）（fate_foxさん談)[name=gori] * ただメソッド分割した結果、スコープが小さくなるならtmpもありな気がする(fate_foxさん談)[name=gori] * あえてミューテーターと名付けるのは、DDD設計ではイミュータブルが基本(??)で、そこであえて可変なしくみを取り入れるからそう名付けているのかも？（fate_foxさん談)[name=gori] * 4.24のコードのだめなところ（fate_foxさん談)[name=gori] ```java class HitPoint { // 略 } class Member { void damage(int damageAmount) { // (1) HPの計算それ自体をMemberクラスが担っている // (2) いきなり負数となる可能性がある（死亡状態判定は0になったら、だから) hitPoint.amount -= damageAmount; // 本文では省略されているけど、たぶんこんな処理が書かれているはず // 前述のとおり、負数の可能性があるのでここは通らないケースがある // かといって hitPoint.amount <= 0　とかにすると別のバグを生みそう if (hitPoint.amount == 0) { states.add(StateType.dead) } } } ``` --- # 5章: 低凝集（ていぎょうしゅう） ## 事前共有 ### 感想/気づき * 凝集度…モジュール内における、データとロジックの関係性の強さを表す指標[name=あざらし] * 高凝集…変更に強い（望ましい構造） * 低凝集…壊れやすく変更が困難 * 5.3.3 横断的関心事については、共通処理としてまとめる[name=あざらし] * 例）ログ出力、エラー検出とか * 5.6.1 詳細なロジックは呼ぶ側ではなく呼ばれる側に実装する[name=あざらし] * 5.3(共通処理クラス),5.4(結果を返すために引数を使わないこと)やその他の事例をよく間近に見ています。[name=fatefox] * 5.5(多すぎる引数)にある、以下の内容が割と刺さりました。[name=fatefox] * メソッドに引数を渡すのは、その引数を使ってなにかを処理させたいから。引数の量が多いということはすなわちそれだけ処理させたい内容が膨らむこととなり、処理内容が増えるとロジックが複雑化などを引き起こす。 * 5章は、実装が担う各要素はクラスで宣言して意味と役割を明確にし、staticなどの要素はその役割を支えるシステム的なものとして使用するのが良いと解説しているように思えました。[name=fatefox] ### 疑問 * staticメソッドとは？[name=あざらし] * 直訳すると静的メソッド * インスタンスを生成せずに呼び出せる * インスタンスごとに動作が変わらないことを保証できる * 状態に依存しないことを保証できる * https://qiita.com/uhooi/items/f32e20750d2fb0f2da46 * 必ず使うというわけではない。むしろそんなに見ない。[name=fatefox] * commonクラス、utilクラスの方が多い[name=gori] * アクセス修飾子（ https://www.tohoho-web.com/java/modifier.htm ）[name=fatefox] * ![](https://hackmd.io/_uploads/rJdB9QSs3.png) * p.169 表8.2にも同一の記載あり ## 当日議論 * 高凝集×疎結合が良いとされているらしい * 横断的な処理にstaticを使うのは良い * ログクラスというものを作っておいて、それを呼び出してログを吐かせる処理とか実際に作ってる * ログ設計は大変！ * 開発者だけでなく、運用担当者が見ても原因が特定しやすいログを出力させることが大事 * stack trace…実行中のコンピュータプログラムにエラーが発生した際に、直前に実行していた関数やメソッドなどの履歴を表示すること * https://codechacha.com/ja/java-print-stack-trace/ [name=gori] * エクセプション…例外 ```java try { // 略 } catch(Exception e) { e.printStackTrace(); // これ } ``` * 開発者と運用担当者が直観的に使いやすいものを作るようにする * プリミティブ型使うな思想強めw * RustはResult型なんてのがある(fate_foxさん）[name=gori] * https://maku77.github.io/p/us2ahpw/ * 言語として用意してるのか、、[name=gori] --- # 6章: 条件分岐 ## 事前共有 ### 感想/気づき * ネスト、いっぱい見たことあるなぁ…（遠い目）[name=あざらし] * ネストがダメな理由 * 読みづらいので、バグを埋め込みやすくなる[name=あざらし] * 解決策として、早期returnを使う * 条件を満たしていない場合、すぐにreturnで抜ける * switch文は悪魔を呼び寄せやすい[name=あざらし] * でも、可読性は高い気がする…（あくまで個人的な意見です）[name=あざらし] * 使いたいなら条件分岐を1か所にする * **interface**を使うと、分岐ロジックを書かずに分岐が実現できる[name=あざらし] ```java // リスト6.28 魔法型を表現するinterface interface Magic { String name(); int costMagicPoint(); int attackPower(); int costTechnicalPoint(); } ``` * やっぱり、値オブジェクト化させる（プリミティブ型はNG）[name=あざらし] * クソコード動画「switch文」[name=あざらし] * https://twitter.com/MinoDriven/status/1228896043435094016?s=20 * **『分岐を書きそうになったら、まずinterface設計！』**（格言） * interfaceの使い方をようやく理解できた気がする(気がする) [name=ふぉっくす(fatefox)] * リスコフの置換原則[name=ふぉっくす(fatefox)] * 親クラスの振る舞いを子クラスが勝手に壊してはいけないという原則 * 親にできないことを子にやらせない * リフレクション(https://itsakura.com/java-reflect) [name=ふぉっくす] * クラス名やメソッド名を指定して「クラスを動的に実行する」こと * ストラテジパターン、Javaだとリフレクション使ったりするケースありますよね　[name=gori] ### 疑問 * 実際interfaceって業務で使われているのか？[name=あざらし] * そんなに使われていない。フレームワークをよく使っているので、そのフレームワークに則って使うこともある[name=ふぉっくす] ## 当日議論 * and/orが混在した条件分岐とかまじしねる(fatefoxさん)[name=gori] * DI(https://qiita.com/hshimo/items/1136087e1c6e5c5b0d9f)[name=gori] * Java getter/setterのメモ（https://qiita.com/takahirocook/items/27828bc8477735612021 ）[name=あざらし] * ポリシーパターンってこれもDDD文脈？軽くググるとストラテジーパターンと同じだと言ってる人多い気がする[name=gori] * 『Strategyパターンは、別名Policyパターンとも呼ばれます』（https://tgg.jugani-japan.com/tsujike/2022/06/mino6-5/ ）[name=あざらし] * ドメイン駆動設計各パターンの要約 (https://qiita.com/magicant/items/2846840f749059f00cf3)　[name=ふぉっくす(fatefox)] * この本の第6章、第14章のコードを紹介している？Github（https://github.com/tsujike/minodriven-goodcodebadcode ）[name=あざらし] * ↑ではなかったですね😅[name=gori] * 著者ではなかったので直しておきましたｗ[name=あざらし] --- # 7章:コレクション ## 事前共有 ### 感想/気づき * anyMatchメソッドを使うと、for文やif文を書かずに書くことができる[name=あざらし] * 引数に記述したラムダ式が少なくとも一つの要素でtrueを返却した場合、anyMatch()メソッドはtrueを返却する * ループ内でごちゃごちゃした処理書くくらいならラムダ式使いなさいよ、て主張？[name=gori] * この章はいまいちまだピンと来てません [name=ふぉっくす] ### 疑問 * 特になし ## 当日議論 * この章はあまりコメントが無かった…[name=あざらし] --- # 8章:密結合 ## 事前共有 ### 感想/気づき * xxManagerクラスは危険な匂いということか、、[name=gori] * 7章でもメンバー追加処理をFieldManagerにやらせてましたね * DRY原則の誤用、自分も昔は「コード重複してたらダメ」だと勘違いしてた[name=gori] * 同じく…[name=あざらし] * 継承、自分は「実装継承は良くないが、意味継承ならOK」ということを聞いた * 実装継承：コードを引き継ぐ * 意味継承：型（:扱い方）の情報を引き継ぐ * DRY原則の扱うべき範囲は、概念単位であり同じ様なロジックでも概念が異なればDRYにすべきでない -> 勉強になった [name=ふぉっくす] * 継承はよっぽど注意して扱わないと危険、継承は推奨しません。 -> このことはよくわかるし、実際継承するようなクラスを作ることは稀だと思う。[name=ふぉっくす] * 継承よりもコンポジション、なんか聞いたことあるなと思ったら、Effective Javaでも同じこと言ってた。[name=gori] * https://note.com/asekaki_dev/n/na01a5d387532 * 継承も概念単位で扱うには問題ないのでは？ [name=ふぉっくす] -> サブクラスのことを気にせずにスーパークラスを変更するのはちょっと恐ろしくない？ * 余談: 夏季限定割引のように、割引する金額をハードコードする事例は稀な気はする。[name=ふぉっくす] 　 -> 業務の要件が変わる都度コードを修正するを避けたい人たちもいたりするゆえ * p.166の影響スケッチは気軽に活かせそう [name=ふぉっくす] * クソコード動画「共通化の罠」[name=あざらし] * https://twitter.com/MinoDriven/status/1127539251761909760 ### 疑問 * 特になし ## 当日議論 * ところどころに皮肉が…[name=あざらし] --- # 9章: 設計の安全性をそこなうさまざまは悪魔たち ## 事前共有 ### 感想/気づき * YAGNI原則の判断むずい、、いま考えなくていいかどうかってどうやって判断すれば、、[name=gori] * ↑で拡張性意識した設計にしておく（将来の仕様変更に備える）のとは別ってことですよね[name=gori] * 開放閉鎖（オープンクローズド）とはまた別ですよね * 9.4文字列型執着の例、邪悪すぎるw 列挙型とか使えばいいのに、、[name=gori] * null回避のところ、これNULLオブジェクトパターンといっていいですかね？[name=gori] * https://tech-blog.rakus.co.jp/entry/20230419/java * コンストラクタ初期化時に事前条件満たしてなかったら例外投げる（とくに`IllegalArgumentException`）の、この本通じて一貫してる * メタプログラミングもといリフレクション、ストラテジーパターンで使われてるのは見たことある[name=gori] * というか、9.17の使い方これほんとにあるの？w * 技術駆動パッケージのくだり、フォルダ分けでもカプセル化・情報隠蔽意識しなさいよ、てことですね[name=gori] * デッドコード、無さそうでありそう。。というか見たことある。。[name=あざらし] * エラー出ないのが一番邪悪（9.7）[name=あざらし] * 例外の握り潰し自体、本当はNG * 銀の弾丸なんて無い ;-p [name=ふぉっくす] ### 疑問 * 特になし ## 当日議論 * 原則、要件に無いものは作らない。なので、後から使うかもみたいな理由では作らない方が良い[name=ふぉっくす] * 思いつきではやるな、ということだと思う[name=ふぉっくす] * 汎用的になるかも、はやはり罠[name=gori] * 基本システムは変わっていくものなので、システムに変更があるタイミングで必要な機能を入れるべき[name=あざらし] * （↑の内容に続き）個人で完結するシステムならやってもいいけど、基本的にシステムは第三者が使用するので、やらない方がベター[name=ふぉっくす] * SIの場合、要件に無いものを勝手に作ることは基本やらない（出来ない）[name=あざらし] --- # 10章: 名前設計 ## 事前共有 ### 感想/気づき * 神クラス(目的不明オブジェクト)はダメ [name=あざらし] * 例．商品クラス。予約、注文、出品、発送などに分けるべき * 巨大化したら手に負えなくなる * 名前をつける時は、どんな目的で作るのかをよく考えてから命名する [name=あざらし] * リスト10.7最悪すぎ… [name=あざらし] ```java // リスト10.7 tmpだらけで意味不明 int tmp3 = tmp1 - tmp2; ``` * 技術駆動命令、意識しないとやってしまいそう [name=あざらし] * 数年前に、目的を入力すると変数名を考えてくれるサイトがあったような… [name=あざらし] * クソコード動画『Managerクラス』 [name=あざらし] * https://twitter.com/MinoDriven/status/1157554468201746432?t=GBSDAm-DZdhRADGzBp3J-g&s=1 * リスト10.14のDTO、自動生成してくれるものが多いのでそこまで名前意識しないかも * 例えば：https://qiita.com/ketman55/items/abcc1e23dcac0cc268b5 * DBとのやり取りが多い * 表10.1 その目的が説明されないことが多かったり [name=ふぉっくす] * 関心の分離　[name=ふぉっくす] * ユースケース、目的や役割ごとに分離する * この分離は、システムの運用が長く、改修が重なるほど難しくなるのでは？ * この考え方が共有できてない人達が増えると瓦解しそう * 10.3.3　10.3.4 会話に登場するのにコード上に登場しない名前 [name=ふぉっくす] * あるあるすぎて辛い、そして情シスも無関心 * 形容詞で分けてもまだわからんし事例もよくある * 10.4　関心の分離に貢献してないと責務の混乱と密結合を生む [name=ふぉっくす] * リスト10.8　メソッド名がすでに呪文 [name=ふぉっくす] * 驚き最小の原則（p.226）　重要 [name=ふぉっくす] * 仕様変更時にこうも手直しできる？(工数、納期など考えると) (全体的なお話) [name=ふぉっくす] * 10.5.3 コンテキスト事に要素を分けることで同じ単語でも意味の切り替えができるの確かにわかりやすい。また現実の開発においてここまで切り分けれてるケースも稀 [name=ふぉっくす] * 10.5.4 連番命名は悪:-p 　　[name=ふぉっくす] * 昨日のIDを振る名目で連番をつけるケースもある * 10.7 読むのにコツが居るケースはよく見ます。　[name=ふぉっくす] ### 疑問 * 特になし ## 当日議論 * 単語の頭文字以外を無くす命名は悪 * 連番も悪 * 極端に長い変数名も悪 --- # 11章: コメント ## 事前共有 ### 感想/気づき * コードだけでなく、コメントもちゃんとメンテナンスする（自戒も込めて） [name=あざらし] * ロジックをなぞるだけのコメント、書きがち [name=あざらし] * 自分以外の人（主に保守担当の人？）が読む前提で書く [name=あざらし] * 他人が見ても理解できるレベルまで落とす、ということ * ドキュメントコメント、ちゃんと書いたことないかも。。 [name=あざらし] * 退化コメントが10章(10.4のリスト10.7)のコードについてるケースはよく見る[name=ふぉっくす] * 退化コメント…情報が古くなり実装を正しく説明しなくなったコメントのこと ### 疑問 * 特になし ## 当日議論 * コメントの粒度は揃えないといけない [name=ふぉっくす] --- # 12章: メソッド（関数） ## 事前共有 ### 感想/気づき * ここでもxxxManagerクラスは危険ということが語られている？[name=gori] * 12.1の「リスト5.14のように〜」のくだり * CQRSとCQS: https://zenn.dev/praha/articles/4da7c1f91fb91f[name=gori] * CQS: オブジェクトレベルで更新と取得をわけよう * CQS違反の代表例: 配列のpop(確かに値取り出したいだけなのに配列の中身変えちゃってる) * CQRS: アーキテクチャレベルで更新と取得をわけよう　←あってるかな？ * 12.6.3 全部例外投げてたらtrycatchがすごいことになりそうなのでワンクッションはさんで例外投げるのもありかもしれません[name=uaaaaaaaa] * 12.5にあるように引数の使い方はここに列挙されている事例を間近に見てるので、悪い例であることを再認しました。[name=ふぉっくす] ### 疑問 * 12.3 getter/setter のクラスをコントローラごとに作成ではダメ？[name=uaaaaaaaa] * 12.6 リソースや処理時間に問題はないか[name=uaaaaaaaa] * オブジェクト指向に則って作り続けると、重たくなりすぎないのか？ * コンパイラが耐えられるのか？ ## 当日議論 * https://twitter.com/t_wada/status/904916106153828352 * コメントのくだり * コードには How、テストコードには What、コミットログには Why、コードコメントには Why not * どうしてやっていないのか、というのを残すのは地味に大切かも。。[name=あざらし] * コメントで意図を表現するな！コード内の型で表現しろ！てことですかね？[name=gori] * 設計書の通りに開発をして、完璧なものができるかというと、できない。[name=あざらし] * 脳内コンパイラが無いと無理[name=ふぉっくす] * https://twitter.com/s5ml/status/1699180610797842879 * 美味しんぼで学ぶログ要件w * こんなのもありました　→　https://twitter.com/s5ml/status/1700706678000537683 --- # 13章: モデリング ## 事前共有 ### 感想/気づき * 13.1 例では仕様変更でしたが、外部連携データなどは不備がある前提で、本書の通りモデルを作ったらチェック処理もしっかりしないといけないなと思いました。[name=uaaaaaaaa] * 13.4 裏に隠れた真の目的を見破る -> これが割と難しい -> 見つけられる人は情報のインプットが上手？ [name=ふぉっくす] ## 疑問 * 13.2.3 目的があれば図13.4のように巨大なモデルになること自体は問題ないということなのか？（画面とか帳票にまとめて出力しますのような）[name=uaaaaaaaa] * 「商品」と言っても配送だったり注文だったり、目的が色々あるからわけた方が良いよね、と言う話 [name=ふぉっくす] ## 当日議論 * 設計は一回で終わらない。日々改善、改良していくもの [name=あざらし] * 区分、フラグが入れ替わることがたまにある [name=uaaaaaaaa]　[name=ふぉっくす] --- # 14章: リファクタリング ## 事前共有 ### 感想/気づき * 機能追加とリファクタリングは同時にやらないこと。ついついやってしまいそう…。[name=あざらし] * 14.3.1 本題とずれますが、先にあたりをつけるのが割と下手なのでコード読む前にとりあえず実行してみる作戦はありかもしれないなと思った[name=uaaaaaaaa] * 14.2.2のリファクタの進め方、これTDD（Test-Driven Development）の進め方っぽいですね！[name=gori] * https://atmarkit.itmedia.co.jp/ait/articles/1403/05/news035.html * 仕様化テストこれいいな！[name=gori] * テストコードを書くテストがうまく行ったケースに巡り合ったことがない...[name=ふぉっくす] ### 疑問 * そもそもリファクタリング自体やることあるのか…？自分は一度も見たことがない💧[name=あざらし] * 現場による。リファクタリングをやらないチームもあれば、リファクタリングチームを作っているところもある * よほど理解ある会社じゃないと、リファクタリングチームを作ることが無いかも。。 * テストはどうする？どこまでやる？[name=あざらし] * テストコードを書くらしいが、これってどこまでちゃんとやられてるんだろうか…。 * 14.1.3 論理否定をなくすよう改善のところで、関数はisEnabledとisDisabled両方作った場合、中の処理はほぼ同じなので違うところだけパラメータか何かにして共通処理にして呼び出す名前だけ変える感じ？[name=uaaaaaaaa] ## 当日議論 * 新規開発の段階でも、工程としてリファクタリングという工程を用意しているケースもある[name=uaaaaaaaa] * 仕様化テスト[name=gori] * このリファクタ本から出典？　https://qiita.com/e99h2121/items/506d20d02953d227a790 * 「第24章　もうウンザリです。何も改善できません」　←気になる。。 * TDDはイケてるチームが取り入れている？？？ * TDDは第16章、第17章に出てくる * テストの範囲どうなのか。。（カバレッジ何パーまでやるべき問題？）[name=gori] --- # 15章: 設計の意義と設計への向き合い方 ## 事前共有 ### 感想/気づき * 15.3.2 引きずられやすいどころか、そもそも似たような処理はコピーして使ってくれとお願いしてしまっていて反省している[name=uaaaaaaaa] * 15.5.1 結構前はJavaで200行くらいといわれていた気がするが順調に減っている[name=uaaaaaaaa] * 15.5.1コラム分けすぎると入門者が最後まで追いかけてくれない問題が生じる[name=uaaaaaaaa] * 15.5.5 マジカルナンバー4という考え方中々良さそうです。確かに今のシステム理解するの数年かかりましたのでもうダメです[name=uaaaaaaaa] * 15.3.3 レガシーコードは極めてアンバランスでトリッキーな実装が多く、納期等の都合で設計改善を諦めるは割とあるまた15.3.4の難読性による開発工数の減少もよくある。（それでいて工数を見積もれと言われることがほとんど）[name=ふぉっくす] * 15.4.3 理想形を知ることが大事なのはわかるけど、理想形がわからない。[name=ふぉっくす] * 本書の例では空手で表現しているが、ソフトウェアにおける理想形て何・・・？ * 理由が説明できるか否か？ * 循環的複雑度という概念を初めて知った [name=ふぉっくす] * 15.8 『今の設計品質が未来の時間に直結している』→その通りだと思う。リリース前でも後でも、同じことが言えると思う。[name=あざらし] ### 疑問 * 15.5.3, 15.6 コード分析のツール皆さん実際何か使ってますか？[name=uaaaaaaaa] * 使ってないです。。[name=あざらし] * 使うほどキレイなコードじゃないので使えない[name=ふぉっくす] * 結論：誰も使っていなかった（悲） ## 当日議論 * 現場では現行のコードに合わせて書いて、というのはよくある。。 * だからこそ、最初の設計が大事だよね、という話 * 最近流行りのラムダ式。 * マジカルナンバー4±1は設計に限らず、全ての事象に言えること。 * 15.7 費用対効果の話。。えらくなればなるほど、お金の話ばっかり。。 * eclipseで慣れていると、VSCodeは少し使いにくい。 * 15.4.2 知覚容易な課題と知覚困難な課題について、見えない課題の方が多そう。 * コード読解スキルと技術的負債の知覚スキルは別。 * 霞が関構文 * https://shikiho.toyokeizai.net/news/0/89007 --- # 16章: 設計を妨げる開発プロセスとの戦い ## 事前共有 ### 感想/気づき * コンウェイの法則のあたりで「チームトポロジー」という本があったのを思い出した[name=gori] * https://pr.forkwell.com/event/team-topologies-study-01-01/ * 16.2.4、サイクルを細かくまわすっての大事ですよね(できてないけど)[name=gori] * 16.1.3、前いたチーム、心理的安全性低かったなぁ…（遠い目）。むしろ、低いチームばかりな気がするんですが、皆さんの会社はどうですか？[name=あざらし] * 16.3.2、「正体を見破る」スキルが欲しい[name=あざらし] * ジョシュアツリーの法則は、プログラムに限らず業務の理解の中でも発生しやすい。[name=ふぉっくす] * 詳しい人にインタビューしたり文献を漁ることで理解を深めるのは大事だが、それができるのは整理された環境だけだったりするような。即ちそれらを整理するスキルも必要？[name=ふぉっくす] * 16.4.3 レビューする上での礼儀と敬意といったものはとても大事。特に難しい仕事を請け負ってっくれた人とか... [name=ふぉっくす] * 16.4.4 定期的に改善タスクを棚卸しすること。ができておらず有耶無耶になる経験は多々ある。[name=ふぉっくす] * 16.5 で取り上げられている内容を実現するのは、読者のこの本に対する理解度と忍耐が試されそう。[name=ふぉっくす] * 16.2.1 クラス図すらなくて反省してます[name=uaaaaaaaa] * 16.3.2 これは本当にすべて疑ってかかってほしいです。ただあんまり疑いすぎてると時間がいくらあっても足りないので塩梅が難しいです[name=uaaaaaaaa] * 16.4 「終わりを見つける」というのは大賛成です。レビューする側は参加しているんだから必ず一つは指摘しなきゃいけないという心持ちはやめて欲しいです。かと言って、何か問題に気づいてるのに自分の処理に影響するかもしれないとか思って見逃すのもやめてほしいです。あと本質的でないところでねちねち言うのも、指摘されたのに直さないのもやめてほしいです。ついでに、使わないのに代替手法とか延々と説明するのも時間の無駄なのでレビュー後にまとめて連携するなり個別でやってほしいです[name=uaaaaaaaa] 　　* ↑色んな思いが詰まってますね[name=ふぉっくす] ### 疑問 * 皆さんのチームでの設計工程・成果物が気になる[name=gori] * xx書(仕様書、設計書、etc..)ってどの粒度まであります？ *　案件によって、粒度はまちまち。自社のだと、基本・詳細 DB関連だとCRUD図とかあるかな？ [name=ふぉっくす] *　同じく、案件によります。顧客によってはかなり細かく（基本・詳細・DB関連・運用など…）作らされる場合もあります…[name=あざらし] * ↑の続きで、コーディング規約や、設計ルールなどもあれば[name=gori] * 自分の場合はPHPだとPSRに近いもの(が、文書化されてるわけでなく、レビュー時に上司から指摘されて直すのが多かった)[name=gori] * https://rabbitfoot141.hatenablog.com/entry/2018/10/14/002210 * ほかクラス名の制約などはどちらかというとWebフレームワーク側の制約に縛られることが多かったかも[name=gori] * これも案件による。お客さん次第。[name=ふぉっくす] * コーディング規約が無いケースもあるけど、コーディング規約があってもソースが読みづらいというのもあった。[name=ふぉっくす] * 設計ルールに限らず、色々なルールを多数決で決めがちだけど良くないらしい…。でもシニアエンジニアなどがいない場合、多数決以外でどうやって決める？[name=あざらし] * もめたらリーダーに投げる[name=uaaaaaaaa] * 弊社ではできない…(´;ω;｀)[name=あざらし] * 16.2.4 「厳密に設計せず、サイクルを回すのが大事」を実現するには、16.5にあるような設計コストを考慮したスケジューリングが必須と思われる。ところで、設計の厳密性って割と求められますか？[name=ふぉっくす] ## 当日議論 * レビューの時、あえて指摘される部分を作っておく、というテクニックがあるらしい…[name=gori] * 難易度は高い[name=ふぉっくす] * 自分達のためというより、誰かに提出するためにドキュメントを作ることが多い気が[name=あざらし] --- # 17章: 設計技術の理解の深め方 ## 事前共有 ### 感想/気づき * 技術書がいくつか紹介されてましたが、これらを読んで知識をつけたところで、自分一人だけ知識がついてもあんまり意味無い気がする…。新人研修などで全員に読ませてほしい。あと、上位者もちゃんと知識をアップデートするために読んでほしい[name=あざらし] * バグ退治RPG面白そう。やったことある人いますか？[name=あざらし] * https://www.freem.ne.jp/win/game/30836 * インプット：アウトプット＝2：8　が良いらしい。意識していきたい。[name=あざらし] * 17.1 「現場で役立つシステム設計の原則」「レガシーコードからの脱却」が気になってましたが他にもいっぱい提示されてるけど、設計の本ってあんまり読めてないなと感じました。[name=uaaaaaaaa] * 17.1.1(現場で役立つ~）は自分持ってます！（読んでるとは言ってない。積んでます。。誰か一緒に読んでくれる人、、w）[name=gori] * 17.2.3 Column IDEが進化して悪いコードを良いコードに変換してくれる未来が早く来てほしい[name=uaaaaaaaa] * そもそもまるっとコード書いてくれる未来がまもなくですね。。[name=gori] * コードがどこまで信用できるか、どうやって信用するか、、という問題が出てくる👼 * 17.2.3の注釈、養殖モノクソコードではだめなのかw[name=gori] * 17.2.4の進め方いいですね。とりあえず動くもの作ってから設計してみる（んで、書き直す、と理解しました[name=gori] * 設計とはちょいそれますが、リファクタを考えるとなるとテストしっかり書かなきゃ、て思いますよね[name=gori] * 17.2.4「動くコードを書いたら、設計を見直してコミット」をやる工数が認められないことが多いのかなと思う。完璧に設計してから最小限の時間でコーディングしろみたいな。[name=ふぉっくす] ### 疑問 * 特になし ## 当日議論 * 翻訳した本（〇reillyとか）読みにくい。 * 実際、現場では工数足りなくてやらせてもらえる機会が無さそう。

Syntax	Example	Reference
# Header	Header	基本排版
- Unordered List	Unordered List
1. Ordered List	Ordered List
- [ ] Todo List	Todo List
> Blockquote	Blockquote
Bold font	Bold font
Italics font	Italics font
~~Strikethrough~~	~~Strikethrough~~
19^th^	19^th
H~2~O	H₂O
++Inserted text++	Inserted text
==Marked text==	Marked text
[link text](https:// "title")	Link
![image alt](https:// "title")	Image
`Code`	`Code`	在筆記中貼入程式碼
```javascript var i = 0; ```	`var i = 0;`
:smile:		Emoji list
{%youtube youtube_id %}	Externals
$L^aT_eX$	L^aT_eX
:::info This is a alert area. :::	This is a alert area.