# ミノ駆動本_読書py[3] みんなのメモ

###### tags: `ミノ駆動本`

- このメモはWebに公開されています（HackMDチーム）
- リンクを知っている人は見られます
- HackMDにログインして編集できます

## お願い事項

https://twitter.com/MinoDriven/status/1541334416622256130

> 【お願い】
拙著『良いコード／悪いコードで学ぶ設計入門』に関する情報発信について。
ブログ等で発信の際は、引用の範囲を超え、著作権侵害となる場合は勿論のこと、拙著の詳細内容が分かるような表現での公開はお控え頂けると助かります。
ご感想や拙著に基づく試行錯誤は歓迎です。 #ミノ駆動本

> 拙著引用の際は、Qiitaさんの『著作物を引用する際の注意点』が参考になります。適切な引用のもと、情報発信していただけると嬉しいです。https://help.qiita.com/ja/articles/about-copylight #ミノ駆動本

とのことなので勉強会そのもので詳細内容がわかるような記述はしないように気をつけていきましょう。

## このメモについて

このメモは ミノ駆動本_読書py[3] のメモです
https://connpass.com/event/253382/

読む範囲：9章

ミノ駆動本のサポートページより、Javaのサンプルコードが見られます。
https://gihyo.jp/book/2022/978-4-297-12783-1/support

## 読書会の流れ

* 19:30〜20:00 **自由参加**のもくもく会（個人作業）
- 事前に読む時間がとれなかった方はここで読んじゃいましょう（ざっとで大丈夫です）
- 合わせて、この**HackMD**に話したいことを各自書いてください
- ログインすれば書ける設定にしています
- ここがわからん、ここはわかった　お気軽に書き込んでみてください
- HackMDの書き込みに投票し、みんなが気になるところをわいわい読み解いていきます
* 20:00〜21:30 読書会本編（みんなでわいわい）
* Discordでスライド共有して別途案内します
* 20時開始の本編では、「わたしこれ気になる！」という話題に `:+1:` と書いて投票します。
* :+1: する上限はありません。気になる話題に全部 :+1: しちゃいましょう。ただし1つの話題には1個だけ:+1:でお願いします
* 票数が多い話題から話していきます。

## 以下、もくもく会ワークゾーン

### 感想、気付き

- みんなの現場のつらみが垣間見れてとても楽しい
-
-

以下は各節で「これってどういうことなんだろう」「ここからこういう気付きがあった」などを書き出すゾーンです。

### 9章 設計の健全性をそこなうさまざまな悪魔たち

#### 9.1 デッドコード

- デッドコードの調査で時間を取られたことがありました・・・　ちょっとぴえんだったのは、デッドコードなのに改修時にロジックが追加されていたことがあって、「どうやったらこのロジックに辿り着けるんだ・・・？」ってなりました :+1:
- デッドコードを防ぐ（？）場合って何か良い方法あるんですかね？（って思ったら下に同じことが書かれている・・・！）　PyCharmとかなら使ってないメソッドは判断できたような・・・？ 変数だっけ・・・？
- デッドコードを検出するために良いツールとかあるんでしょうか？VSCodeでも到達不可能なところは灰色のハイライト？がついてわかりやすくなってたと思います。ただ、これって知らせるだけでデッドコードを強制的に排除するような仕組みじゃないので、デッドコードが入りこむこともありそう。。。:+1:
- 不要なデットコードと、まだ十分に実装されていないコードの見分けがつかないので、難しそうですね。
- pylintで検知できたような。gitのpre-commitでpylint実行するスクリプト仕込んでコミット前に検知できるような仕組みは職場のチーム内で導入してます。:+1: :+1::+1::+1:
- フック？

#### 9.2 YAGNI原則

- 「必要になったらやりましょう」はコードの可読性もですが、仕事の進め方にも通じそう。よくあるのが、あったら良いかもという要件にないOPTIONを実装して時間をかけてしまい、要件にある機能開発がスケジュールどおり進まないがあった、、、
- 判定ロジックとして定数値に値を入れようとして、strにしていたらlistにしてね、って言われてやったことがあるけどこれはYAGNI原則に違反しているのだろうか・・・？ foo = 1がfoo = [1,] ってなった感じ :+1:
- とてもYAGNI原則に反しているとは考えられますが、現場の風習とかその後のデータの扱いとかもあるので、必ずしも「反してる」とは言えないですね（慎重論）:+1:
-

#### 9.3 マジックナンバー

- 現行のソースがそうなっているので書いちゃったらそれ、マジックナンバーなのでやめてくださいねって言われて存在を初めて知りました。Pythonだと FOO_BAR = 'BUZ' みたいに大文字で書いてけば良いんでしたっけ。:+1: :+1:
- ValueObjectと組み合わせると効果絶大かな？

#### 9.4 文字列型執着

- 何かやっちゃいそうだなと思いました。。 hoge[0], hoge[1] みたいな・・・
- 引数をたくさん書くのが嫌で、不必要な引数もまとめた1つのdictを関数に渡すのを見たことがある。しかもそのdictがいろんな関数の引数になっていた。:+1: :+1:
-
#### 9.5 グローバル変数

- グローバル変数が必要な局面にまだ差し掛かったことないんですが、singletonとか作る時には必要ですよね？ :+1: :+1: :+1:
- singletonを実装するのに、必ずしもグローバル変数が必要なわけではないです（言語による）
-
#### 9.6 null問題

- Noneでやってましたー（懺悔）:+1: :+1: :+1:
- 結構Noneを返すことが多いんじゃないかと思うんですが、みなさんこう言うのってちゃんと（？）できてるんですかね。
- 返り値が何かしらの値 or Noneというのがよくありましたね、、、
- 今週まさにこの問題にぶち当たりました
- 戻り値がNoneだと破壊的操作かDBなどのオンメモリ外のI/Oと読み解くことが多いです
- 戻り値があるのに破壊的操作をされていたりすると混乱することがある
- 呼び元の扱い方ですが, Noneでない戻り値を使わない時は明示的に破棄してもらえると嬉しい:+1::+1::+1::+1:
- _ = function() # 戻り値があるとわかる
- var = function() # 使わないのに戻り値を束縛している
- function() # 戻り値があるとわからない
- _ を破棄だと思っていたけど _ という変数だった
- 推測ですが、他の言語では破棄の扱いになるものがあるので、その習慣だけを持ち込んだのでしょう
- やっぱり、「None（Null）を極力使わない」という僕の設計方針は正しかったんだ、とちょっと自信が持てた（最近、現場でNull値が当たり前に使われているので）:+1:
- DBのNull値はまた別なのだろうか？ :+1: :+1:

#### 9.7 例外の握り潰し

- `except BaseException:`はすべての例外（Ctrl+CやCtrl+Dにより送出される例外も含む）が該当するそうです。なのでこれを握りつぶすのが一番罪が重いのではないかと思います:+1: :+1:
- 例外の階層構造 https://docs.python.org/ja/3/library/exceptions.html#exception-hierarchy
- `except Exception:`だとCtrl+CやCtrl+Dにより送出される例外は含まないと理解しています。これを握りつぶすのは標準的な悪さでしょうか
- どうも、例外に故郷の村を焼かれた男です
- 色々考えすぎた結果、ちょっとしたメモを別で作成してしまいました :+1:
- https://scrapbox.io/Yumihiki/%E4%BE%8B%E5%A4%96%E3%81%AB%E9%96%A2%E3%81%99%E3%82%8B%E3%82%A2%E3%83%AC%E3%82%B3%E3%83%AC%EF%BC%9F
- 聞きたいなと思っていること :+1:
- elseって使ってる？
- [EAFP|LBYL] Styleはみんなどうしてる？
- 自分は両方併せ持ったコードを書いていた気がする・・・（？）
- 過去に体験したもの :+1: :+1: :+1: :+1:
- めちゃくちゃ長いtry
- exceptでpass
- exceptで例外発生
- exceptで意図していない例外を拾う
- ValueErrorとしているけど、UnicodeErrorがヒットするみたいな
- exceptでNone
- ファイルI/O系のエラーでやりがち
- 本書では範囲外でしたが、適切なエラー処理を学ぶのにおすすめの書籍、情報をだれかご存知でしょうか？
- 書籍じゃないしPHPで書かれたスライドですが
- https://speakerdeck.com/namizatork/phpfalseerawoli-jie-siteshi-qie-naerahantorinkuwoxue-hou-2
- 何となく、「どんな例外が起こるのか」「意図していない例外が発生する可能性があるのかどうか」を意識するのが大事なのかなぁと
- 「まずは例外が発生したら何処かへ残せ」を合言葉にして開発しています。（ログ等）:+1:

#### 9.8 設計秩序を破壊するメタプログラミング

- メタプログラミングって何やねん！って感じだったけど、何か使ってますか？ :+1:
- 下を見て、必要性に迫られていないから不要かなぁと思いつつ、自作フレームワークなどするなら必要なのかな？とか思ったり
- https://tell-k.github.io/pyconjp2016/#79
-
-
#### 9.9 技術駆動パッケージング

- Pythonパッケージングの名前付け、どこかに明文化されているんですかね？ :+1: :+1:　:+1:
- compat, contrib 何から来ているんでしょう？
- core.py 私よく作ります
- これらは技術駆動なのかな？
- あんまり↑の話がわかってないので解説してほしい！
- レイヤーごとにディレクトリを分けていることはよくありますよね。そこと本書で書かれている「ビジネスクラスで分ける」という話をどう取捨選択すればよいでしょう？
- （他の言語の話だけど）めっちゃやってた……。

#### 9.10 サンプルコードのコピペ

- これはダメゼッタイですね・・・
- でも既存コードをコピペしてしまってレビューでNG食らうことはあったかもw
- 他人の書いたコードは、著作権的にもNGなことがあるので、気をつけたいですね。:+1::+1::+1:

#### 9.11 銀の弾丸

- 買ってもらったおもちゃですぐ遊びたくなるもので、学んだことをすぐ使ってみようとしちゃう・・・　あるある　:+1:
- わかります。クリーンアーキテクチャを意識して書いて、すごく混乱させるなんてこともありそう、、、:+1: