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

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

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

## このメモについて

このメモは ミノ駆動本_読書py[0] のメモです
https://pythonista-books.connpass.com/event/248895/

読む範囲：**1, 2章**
>1, 2章は新卒プログラマさん向けの章（ミノ駆動さん談）

## 読書会の流れ

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

## 参考：Pythonでの実装例

https://github.com/ftnext/exile-of-the-wicked-py/tree/main/chapter2

2章のコードをPythonで写経してみました

- サラッと写経してる・・・？！:+1:

---

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

20時の本編では、「わたしこれ気になる！」という話題に `:+1:` と書いて投票します。
票数が多い話題から話していきます。
:+1: する上限はありません。気になる話題に全部 :+1: しちゃいましょう。ただし1つの話題には1個だけ:+1:でお願いします

### 感想、気付き

- 入門！って感じで改めて読みやすいなと感じた :+1: :+1:
-

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

### 1 悪しき構造の弊害を知覚する

#### 1.1 意味不明な命名

- 技術駆動命名って初めて聞いたけど、xx_list, yy_dictとかやっちゃってたなぁと思ってしまった
- 流石に連番命名はやってない...と思ったけど、最初の頃はやってたような記憶がある（VBAとかでbutton1みたいな）
- `for item in items`と書けるのでxx_listはあんまりやりませんでしたが、辞書の命名はちょっと悩んだ時期がありました（yy_dict/yy_map）。今は複数形にしています
- ハンガリアン記法（システムハンガリアン）流行ってましたよね。あれも技術駆動命名の流れですよね。
- 画面IDをファイル名やクラス名に振るプロジェクトに参加経験があるので、ドキッとした。
- 命名センスに自信がないから、画面ID振ってしまう方が楽なのだが……と考える自分がいる。
- 上流を経験する前のただのコーダーだったときはやちゃってた気がする。ビジネス上の意味がわからんまま設計書通り実装するので書こうにもかけない
- 「ビジネス上の意味がわからんまま」ってすごく大事なキーワードでは？
- 確かに・・・！　
- 技術駆動命名も連番命名初めて聞いた言葉...
-

#### 1.2 理解を困難にする条件分岐のネスト

- if文のネストは結構アンチパターンとして見かける気がしているので気をつけて入るけど、時にはやってしまうこともありますね・・・（既存の作りがそんな感じで急いで踏襲した場合なんか）
- 「既存部分を修正するのは悪！」という価値観で教育を受けているので、追加条件の場合は多重ネストにしてしまうなぁ。
-
-

#### 1.3 さまざまな悪魔を招きやすいデータクラス

- ミノ駆動本でいうデータクラスは、Pythonで`@dataclass`を付けたクラスのことなのだろうか？（3章で考えてもいいと思ってます）
- `@dataclass`はクラス定義のシンタックスシュガーだととらえている -> ミノ駆動本でいうデータクラスには当たらない のかな
- 参照したのは https://peps.python.org/pep-0557/ のAbstractのコード :+1: :+1:
- データクラス、という単語は「現場で役立つシステム設計の原則 〜変更を楽で安全にするオブジェクト指向の実践技法」」にも載ってたと思うんですが、「これダメなの！？」って思った記憶があります。クラスってこういうふうに使うんだ・・・って初めてみた時に感じたので。
- https://www.amazon.co.jp/dp/B073GSDBGT/ref=dp-kindle-redirect?_encoding=UTF8&btkr=1
- > 数十ヶ所で税込計算ロジックが実装
- こういう感じではないですが、Grepして改修箇所を調べることが当たり前に感じていたので悪魔を撃退する方法を学びてえなって思いました。
- 低凝集っていうワードを初めて聞いた。生焼けオブジェクトも（ちょっとまだ完全理解に至っていない）
- 低凝集はデータやロジックが分散し、バラバラになっているの
- 生焼けオブジェクトは初期化しないと使い物にならないクラス、未初期化状態が発生しうるクラス
- 生焼けオブジェクトは `__init__` でちゃんと初期化すれば大丈夫・・・だよね・・・？
- ValueObject（値オブジェクト）覚えてから、こういう事しなくなった。 :+1: :+1:
- 元々、publicでは公開してなかったけど……（そういう問題ではない）
- ValueObjectの定義がイミュータブルですもんね確か（可能な限り） :+1:
- クラス設計するときはどう使われるかを意識しないとこうなるよなあ・・・
- 今の職場、生焼けクラス大好き！な傾向ある
- 元々、Cの人が多いから、そのままの感覚で書いてるふいんき（変換できない）を感じる
- 生焼けクラスという言葉も初めて聞いた
-

#### 1.4 悪魔退治の基本

- みなさんどんな悪魔に今まで遭遇したんでしょう？ :+1: :+1:
- 俺がっ、悪魔だっ……。
- 俺もっっっ……。
- 私も知らず知らずの間に悪魔になってました・・・。
- 正しく本の意図に沿うなら「悪魔を生み出してしまった」ですね :+1:
-

### 2 設計の初歩

#### 2.1 省略せずに意図が伝わる名前を設計する

- めちゃめちゃ詳細な名前！一方、1行を79文字や88文字にするにはやや長いとも思えたり…（改行が入って縦に長くなる）命名を短すぎず長すぎもしないようにバランスを取るには？ :+1:
- 昔は、1行に書ける文字数に制限があったから、省略することに意義があった。その習慣だけが脈々と受け継がれているのだ……。
- 既存の名前が結構省略されていたりするのを見ると、ううむ・・・ってなる
- マルチバイト文字の問題がなければ変数に漢字を使いたいレベル。漢字の意味込め力優秀笑。あ、でも日本独特との変なイディオムとか忖度でそう
- UTF-8以降の文字コードでファイルが保存されているなら、問題ないはず！
- 変換の切り替えがめんどくさいので、できれば半角で入力し続けたいです。コメントすらめんどうだっ！！←
- あ、たしかに！
- ループカウンタな、i とか j とかもダメかしら？idx って多様しちゃってるんだけど、index の方が良いかしら？ :+1:
- 明らかにその場の数ステップで終わるときはiで許してくれと思います
- リータブルコードのループイテレーターでところで↑な感じで許してくれたかと！
- 「省略せずに意図が伝わる名前を設計する」を「とにかく省略だあああ」とならないようにするのが大事だと思いました。たとえば、ポケモン対戦やっている人なら「Monster.すばやさ」でも「Monster.Speed」でもなく「Monster.S」で十分でしょう。ポケモン対戦に関する開発をする上で「S」を知らないっていうのは、省略が悪いのではなく、その人の知識不足だな、という感じですね。この「S」は、悪い省略ではなく、「正しい知識を持った人同士の高速なコミュニケーションのための専門用語」だと思うわけです。同じように、書籍に出てくるAttackPowerもATKで十分かもしれません。 :+1:
- 「正しい意味を知らないと読めない」は、リーダブルではないのでは？
- 「だれにとっての」リーダブルかを決めないと、常に「人による」になるので議論ができないと思います。言いたかったことは「とにかく省略するのではなく、誰がどんな背景を持って読むかを考慮するのが大事だ」です。極端な例で言えば、urlを UniformResourceLocator と書くのは多くの人にとって相当に冗長だと思います。
- 「文脈」を意識することは忘れてはならないと思います。たとえば、name という変数名が悪いか？ という問いを考えると良いと思っています。「絶対に省略してはならないぞおおおお！」にとらわれていると、「悪い命名」と判断されそうです。しかし、商品(Item)クラスの name 属性なら、「商品名」ってのはわかるはずです。逆に言えば、 Item.item_name という命名はしないでしょう。つまり、ある名前が使用されている文脈(関数、クラス、パッケージ、開発している対象など)を考慮しましょうね、という話です。 :+1:

#### 2.2 変数を使い回さない，目的ごとの変数を用意する

- 変数を使い回さないはPythonだと徹底できないかも（当日までに例を用意しておきます）:+1:
- 例はどこだぁ～っ！！
- 例 https://github.com/oreilly-japan/deep-learning-from-scratch-3/blob/06419d7fb2e7ea19aa3719efc27795edbdc41a1f/steps/step12.py#L41-L42 （票数が多かったら話そうと思ってました。終了後に追加）
- tuple型でない場合にtuple型に変換
- 再代入のくだり、JavaScriptだとconstで出来るだけ定義しようね、っていうのを見ると全て定数値にしないのって何だろう？って思ったりしています、、（うまく言えない）
- hoge じゃなくて HOGE みたいに
- 定数は、どんなときでも不変な値（例：定形メッセージ）、変数は、入力を受けたりして状況に応じて変化する値（例：単価、合計金額）なので、そもそも考え方（目的）が違う
- ↑完全に理解しました！
- 「定数化する」ではなくて「再代入不可にする」というニュアンスですね。 :+1:
- 「定数」って、コンパイル言語では、コンパイル時に値に変換されるから意味が変わるんだけど、JavaScriptやPythonみたいなインタプリター言語では、再代入不可ぐらいの意味合いになるのかな？
- いろんな意味合いをもつ変数がたくさんあってしかも長い名前が多いとき、人は疲れて変数を使い回すんだろうなあ。短くシンプルでそれでいて意味がわかる命名規則大事
- if文やメソッドが長い場合にずっと変数を追いかけるのって結構キツイんですよね・・・
- 再代入のはなし、Pythonだとタプルだったり、dataclassをfrozen=Trueにしたりしてイミュータブルに~~しますよね~~（いや、したい、、、ですよね）
-

#### 2.3 ベタ書きせず，意味のあるまとまりでメソッド化

- これ意外と意識せずやっちゃってるんじゃないかな・・・って思いました。既存のメソッドに追加するときとか、、、
- 理想はバッチのメイン処理の中をメソッド呼び出しだけにしたいけど、複数メソッド間でいろんな判定フラグを引き回すとあれよあれよ言う間にメインロジックが汚くなる
- 「意味のあるまとまり」ってどうやって見抜くんでしょうね？ もし、「意味のあるまとまり」が正しく見抜けないなら「きれいなベタ書き」の方が良いと思うんですが、どう思いますか？(おかしな抽象化するくらいなら、抽象化しないほうがマシだという主張)
- なお、「意味のまとまり」を表現した「ベタ書き」 は実現可能だと思っています。あるいは、抽象化の前段階としての「きれいなベタ書き」があるとおもっています。
- 一番最初は、「一連の処理をベタ書き」でいい。まず、書くことが大事。そこから、意味のあるまとまりを抜き出して、メソッド化していけばいいんだよ
- とはいえ、設計段階で考慮されていれば、無駄なベタ書きも発生しないわけですが。
- ほほー！

#### 2.4 関係し合うデータとロジックをクラスにまとめる

- この節を読んで、クラスというものがなぜあるかが分かり、使っていくイメージが持てました :+1::+1: :+1:
- そうそう、これは「なるほど！」って思ったんですよね。
- ロープレに例えてるのがわかりやすい
- ヒットポイントという要素に対して、それに変化を与えるようなメソッドは一つのクラスにまとめると。こんな感じになってくんですかね？
- 人間（継承して各キャラになる的な）
- HP
- 増減のメソッド
- MP
- 増減のメソッド
- final, staticあたりってPythonだとどうやって表現するんですかね？
- staticはちゃんと何者か理解できていないけど...
- staticって、「宣言時にメモリが確保されている」というヤツです。どこから参照しても、同じメモリを参照するのです。（定数もその一種）
-