読書ノート - ベタープログラマ

ベタープログラマの読書ノートです。

正誤表

• 『ベタープログラマ』正誤表

ノート

第1章

• P3 質問4の答えは難しい。
  • 優れた人でも一人でカッとなって作ったコードは優れてないかもしれない
  • そもそも優れたプログラマとは
  • クソコードだけど生産性高い人とかたまにいる
  • 2000行ある switch 文とか、region で頑張る C# コードとか

第2章

• P8 この章はリーダブルコード感
• P16 質問5は結論を出す質問じゃなくて戦争を勃発させたいだけの質問って感じ
  • Java だったらどうする？ → 全員スペースとの回答
  • Python の pep8 とか Go の gofmt や Rust の rustfmt とかは偉大
• P17 折句のコード、never do this (笑)

第3章

• P20 たるんだロジックは今の IDE ならだいたい見つけてくれる
  • モダンな IDE を使おう
  • JavaScript なら linter ちゃんといれよう
  • Pre-commit hook や CI も
• P23 共通化は依存関係を生むが、それに対して「責任を持ってコードに DRY を行ってください」だけはちょっと投げやり感
• P25 デッドコードも IDE でだいたいわかる
  • テストコードが参照している気づかなかったり・・・
  • 参照調べてテストコードだけだったら消す等の綿密な調査が必要
  • 動的型付けだとわからないことも多い
  • 静的型付け言語もリフレクション使われると気づけない
• P30 Q1、例えば null チェックを省いている理由とかはコードには現れない
  • assert やドキュメンテーションコメント等で示したい
• P30 Q2 3 項演算子は使っていこう
  • でもネストはやめよう
  • 必要によっては説明変数を置こう (リーダブルコードにあるように)
  • Go には 3 項演算子ないけどね・・・
• P30 Q3 共通な部分だけ関数にくくり出すとか
• P30 Q5 チームで開発したり API として公開するときは有益かと
  • ただメンテしづらいアスキーアートはやめよう

第4章

• P33 YAGNI 違反、最初にコードを書き始めるときには結構やっちゃうかも
• P37 機能追加したついでにおまけリファクタリングしちゃうことあるよね
  • diff が汚くなるし
  • test 落ちるとか conflict とかの可能性も増える
  • いつリファクタリングするのか結構悩ましい
  • 「年末」の大掃除は実践してみたいかも
  • 年末は比喩表現かも、実際は仕事が一区切りついたところとかかな

第5章

• P42 リーダブルコード でも同じ話した
• P45 C++ で #define はやめよう

第6章

• P58 Rails は見えないものが多すぎてチーム開発つらい
  • “「Ruby そのものが自由すぎる」だとか、「他人の書いた Rails コードを読みたくない」だとかいう批判をよく聞くけど、そういった声は基本的に5人以上 で Rails を触ってしまった場合に起きる問題である。” (参考: Ruby on Rails の魅力と思想 - ボクココ)

第7章

• P62 とんでもない汚物にはふたをしてしまうな
  • 無理に保守するよりスクラップしてしまいたい
  • 式年遷宮とか、いまやIT用語だね
  • EOL で強制的に発動するやつも
  • P64 に繋がる

第8章

• P72 質問  * malloc の戻り値、チェックしてますか？ (参考: MEM32-C. メモリ割り当てエラーを検出し、対処する)  * awesome go linters ええで 　

  第9章

• プログラマーは予期しないことを無視しがち.予期しないことを予期しましょう
• エラーについて
• 防衛的プログラミングでエラーをつぶす
• 車の場合　ビットが熱・ノイズで反転する可能性があるのでRAMを毎周期リフレッシュする
  • -> 発生確率考えてないと無駄なことになってそう
  • -> RAM変数が書き変わってる可能性を考慮しつつ
• web系だと、エラー処理のコードが少ない
  • -> バグってもそんなに問題にならない、厳密に動くことを要求されない
  • -> リリース速度優先　
  • -> アプリ関係も多いかも　
  • -> UIが悪いとすく使われなくなっちゃうから微妙
• スレッド
  • スレッドモデル自体がバグの温床
  • スレッドプーリングでスレッド枯渇して速度低下
  • スレッドを直接触らない(ライブラリに投げる)
• この話の教訓
  • 問題にならないと想定していた事が現実に起こってしまうことがままある
  • 正常系->異常系の流れで書いてしまうので、エラー処理がを想定する
• 質問
  • 4 人間　お金　締切　QCD
  • 2 質問という名の忠告ですよね。。
  • 3 厳格なエラー処理をしないと最終的に自分の首しまる。。。
  • 3 関わる人が少ないコード

第10章

• 質問
  • 1: ドハマリするデバックは時間かかえるよね・・・
  • 2: だいたい後者かな・・・
  • 3: 変わる、調査しないといけないスコープを狭められる
  • Red Green Refactor の枠組みでテスト強度をどうあげていくか (やや脱線)
  • 1回を濃くするか、何回も回すかなどいくつかのアプローチがありそう
  • 4: 許容できるバグの数、結局はビジネス的な天秤かなという気がする

第11章

• P97 皮下テスト (subcutaneous test) って初めて聞いた
  • Martin Fowler が解説している (参考: SubcutaneousTest)
  • 元は医療用語っぽい感じがする
• P96 インテグレーションテストの単位は？
  • 別コンポーネントだったり別チームだったりあるいはその両方
  • Web アプリだとフロントエンドーバックエンドとか
• P97 テスト駆動とテストファーストは違うというお話

情報処理試験にテスト駆動開発が出題されたらしいけど、問題文はこれだろうか。正解は「エ」なのだろうけど、なんというか、ソウジャナイ感があるな……（テストファーストの説明だったらこれでも良いのだけど） https://t.co/wCKKoSFUM5

— Takuto Wada (@t_wada) 2018年4月17日

• P100 カバレッジ 75.0% いかないとリリースできない Salesforce とか

• P101 無意味に環境に依存するテストはつらい
  • OS やランタイムの時計操作するとか・・・
  • ファイルシステム依存とか・・・

• P102 この Java コードは JUnit なのか TestNG なのか… (assertEquals の引数 (expected, actual) が両者で逆なので)

• P106 モックマニアいるよね〜

第12章

• P115 「分散した自己」 (distributed self) が初耳だった
  • Michel Feathers は「レガシーコード改善ガイド」の著者、ただしその本には出てこないような
  • Twitter だった・・・！

Distributed Self - the pattern where a god class passes itself to a bunch of instances it creates.

— Michael Feathers (@mfeathers) 2011年4月27日

• P116 Singleton は不変 (immutable) でも悪なのか？
  • 少なくとも複雑さについて言えば、実質的なグローバル変数みたいな使い方が悪なけでは
  • Scala, Kotlin の companion object は実質シングルトンになるが、普通状態を持つような使い方はしない
  • そもそも普通のクラスでも HogeHogeConsts みたいな定数を集めていろんな所から参照するのも複雑さを持ち込む

第13章

• P119 この章、アジャイルソフトウェア開発の奥義に似てる感じがする
  • 人間とか組織の話はストーリー仕立てのほうがわかりやすいとは思う
• P128 ペアプロだけでアーキテクチャ・設計の品質を保てるか、というのはある。それ以外はコードレビューや設計レビューといっても、適切なレビュアーがいないとやはり品質を保てるのかわからない。
• P131 設計のための時間、大事だなぁ。長すぎるとオーバーエンジニアリングしてしまう。セカンドシステム症候群とも絡む。
• P133 限られた時間で仕事をこなすのが役割な我らからすると、あれもやるべき、これもやるべきといった話だけだと綺麗事な感じがする。トレードオフなはず。
• P132 「設計上の決定を、決定するためのすべての情報をわかっている適切な時期に行う。まだ行えない設計に関する決定を遅らせましょう。」これは現実問題相当きびしいのでは・・・

第14章

P147 質問 1.

丹羽

• 退屈な仕事
  • コードを書くよりも
    • お客さんとの調整
    • 設計の裏取り
    • 裏取りの結果を実装するのは他の人に依頼する
  • コードを書くのはキーパンチのしごとで、誰でもできるという職場の雰囲気

木村

• 芸術・子供の遊び
  • プログラミングパラダイムとか、どういったライブラリ・フレームワークでコードを組み上げるかというところにこだわりを持つ人は多い
• 退屈な仕事

2.

木村

• 外科手術(人月の神話の影響)

丹羽

• 羊飼いは分かるかもしれない。恐怖政治的な
  • 羊飼い: オーナー
  • 犬: リーダー
  • 羊: パートナーとかメンバー
• フリーランサー: 大航海時代の船長

3. ?

やってみる

丹羽

• 学習: 領域が変わるので

木村

• 売れるようにしたいのが今一番の興味なので当てはまるところなさそう

第15章

質問の回答

清水　スピード感優先　不具合起きたら対応する　レビューのプロセス構築必要

丹羽　ルールに従わされる　レビューを複数回

3ルールのもとに結束するか 清水　

丹羽　前　結束する　今　二極化しそう

4

清水　testの書き方とかはこうしたほうがいいってやったりはしてますね。

丹羽　コードがチームを形成している　コーダーの地位が低い

第16章

P154 単純な設計

• レビューのときに説明する言葉が多くなるほど、単純でない設計であるという感覚がある。
• 複雑な部分はどうしても発生するので、それが設計や API にそのまま反映されないように全力で頑張るということ。
• うまくテストコードかけないところも複雑であることを示していることが多い。

P155 大きさ重要

• 共通化を推し進めてコンポーネントだらけになると大きさがでかくなってしまう。でもコンポーネントの数が最初になるようとここではいっている。もやもや。
• 単純化することと単純化しすぎないことの境界やトレードオフを示してほしい気持ち。

P155 短いコードパス

• 抽象化するとコードパスは長くなるし、こここそまさに DRY とのトレードオフが微妙。
• 拡張性のために一段挟むこととかはあるな・・・。
• 関数型界隈の人は (数学みたいに) 高階関数をまとめて1つの関数に抽象化していくことがある。こうするとコードパスは増える。

P156 一貫性は明瞭性を生み出す

• 悪いルールで一貫してたら不明瞭だけどね・・・

P156 単純に保ち、愚かにならない

• 根本原因直したいけど影響範囲広いから対処療法になることが多々・・・
• そして暫定対策だった対策がそのまま恒久対策に・・・

第17章

P162 愚かにならないためには

• 明らかなミスはテストで防げるし
• 継続的なリファクタリング
• 変数名・関数名とか、良い名前をしっかり考える

第18章

P167 「十分なテストとインスペクションによって担保されるようにしてください」とあるが、ここで言うインスペクションとはレビューぐらいのことで、インスペクションレビュー (ガチムチなやつ) とは違うよね？

• おそらく・・・ P168 コードを所有するなと言っているが、 P166 コードの主人はあなたとも言っている。なんとなく違うのはわかる。
• コントロールはしつつ、共有財産としてチームで発展させないといけない P168 村人の助言・・・
• 正しい出発地点に戻ることが大事
• 機能追加の場所を探すより、アーキテクチャ見直すとか 質問1 変更を容易にする属性・・・
• インテグレーションテストとか
• 疎結合に保つ
• オブジェクト指向？ 質問2 バランス、仕事の割当
• ペアプログラミングをちゃんと導入するとか
• モブプロもいいよね 質問3 健全に設計されて安定しているコード、ひどくて触らないコード、どっちが多いかって話？
• 圧倒的に後者 💀 質問4 プロジェクトのツール？
• Redmine とか？
  • ZenHub, Waffle.io
• テスト・CI
• IDE のリファクタリング機能

第19章

P174 自分のコードをコピペして他人に見せるときにミスしたことはあるな

P175 社内フレームワーク作るの大好きマンがこれだ・・・

質問1 重複多い？

• 大量
• 初期状態では重複を許して、プロジェクトの終盤にかけて減らしていったりする
• 皆で DRY 原則の価値を共有している現場ではそうそう起きない
• IntelliJ 有償版の重複発見機能は便利だけどできればこれを CI で回したい

質問2 重複感どこまで減らす？

• 関数を抽象化しすぎて実際何やってるのかわからないコードになったり
• 金融の計算で微妙な差異を共通化するかどうか悩んだりはする

質問3 参考コードの扱い

• 参考にしたコードのリンクをコードに貼ったりはする

質問4 ↑

• トリッキーなコードとか、セキュリティ対策した跡とか
• 低レベルなアルゴリズム使うときとか (シフト演算とか)
• Java の Integer#bitCount みたいな (➝ HD, Figure 5-2)

第20章

P179 バックアップにもなるといっているが、開発マシンの HDD 故障に対する保証にはならない

P180 Git なら (中央) サーバーなくてもバージョン管理できる、これはすごいこと

P182 保存戦略どっち派？

• 全員2 (不必要なものを保存しない)
• IDE の設定のうちフォーマッター設定とかはすることも
• スキャッホールドするツール、コードジェネレーター系はコミットすることが多い

P184 リリース保存

• S3, リビジョン番号ふったり、バージョン管理機能有効化したり
• Java だと Maven リポジトリ立てたり (Sonatype Nexus とか)

P184 アトミックなコミット

• 機能追加とリファクタリングを1コミットにするなとか (コミットどころか PR 単位で)
• revert してもよい・したい単位でコミットするのが良いと言っている本もあったな

P187 機能切り替えの仕組みは GitHub がやってるって聞いたことがある

P187 ブランチの削除ってどうしてる？

• そもそも消さない派
• マージされたら消す
• 実験ブランチは？
• 各々が消すかな

第21章

P21 そもそもQAいる？

• intptr-t: いない
• LagunaPresa: いるけどかかわらない
• mikan: 昔の会社はいた、今の会社はいない

P201 質問2

• 予算？納期？苦笑

P202 質問7

• 単体テストの他に、といっているので、結合テスト、システムテスト自動化とかかな
• コードレビューも品質の向上に寄与するけれど品質の保証にはならない
• そもそも品質を保証する、とは・・・？って感じ