『Clean Coder プロフェッショナルプログラマへの道』を読んだ
Clean Architectureに続き，Coderを読んだ．
Clean なんとかシリーズ．
前に読んだのは Clean Architecture ↓ ttps://noy72.com/articles/ |embed
本書の内容
プログラマとしての考え方や振る舞いについてと技術的な内容も少し． 本書の半分ぐらいを大雑把にまとめると，周りの人たちとどのようなコミュニケーションをとるか，という内容． 第2章 『「ノー」と言う』，第3章 『「イエス」と言う』が特に印象的だった． 「スケジュールに合わせてやってください」「できません」「でもやってください」「できません」「ではよろしく」みたいな会話がどこかでされているかと思うと辛い気持ちになる．
「プロ」とは何か
- マイクロマネジメントされない
- 敬意をもって接される・蔑ろにされない
意見を全く聞き入れてもらえないとき，プロ扱いされていない．
プロの行動とは何か
コードが動作することを把握する
コードが動いていることを把握するためにはテストをすればよい．カバレッジを 100% にしたほうがいいではなく，そうしろ（可能な限りカバレッジを高めろ）と主張する．テストとリファクタリングの組み合わせが重要であるというのはいろんな書籍に出てくるけど，「カバレッジ 100%！ それ以外にあるか！？」みたいなのは見たことがなかった．
また，TDDを強く推奨している．TDDの利点の一つとして，テスト可能な設計を強制されるという点が挙げられている．「テストを先に書く」というと単に順序を入れ替えただけに聞こえるけど，実際はそんな単純ではない上，TDDによって作成されたテストは十分ではない．本書では以下のように書かれている．
以上のように優れた点はあるが，TDDは宗教や魔法の手法ではない．
「イエス」というべきか「ノー」というべきか
答えは，二人（あるいはそれ以上）が目標を合わせるためには，
- 何がいつまでにできて，
- 何がいつまでにはできなくて，
- 何がいつ必要になるのか
をはっきりさせなければならない．
「〇〇までに△△が必要」という状況において，
〇〇がその日までにできるのであれば「イエス」と答えられる．できないのに「やってみます」はかなりまずい．
「〇〇までに△△が必要って言ったじゃないか！」
「ええ，ですから申し上げた通りやってみましたよ．その結果できませんでしたが」
できないものは「ノー」とはっきり言う必要がある．
「〇〇までに△△ですか？ 無理です．以上（もう話しかけないでね）」
ただ，「ノー」を言うだけではいけない．
何ができて，何ができないのか，そして何が必要になっているかを明らかにしなければならない．場合によっては優先順位や予定，（どうしても無理なら）必要とされているものを変更したり，計画的に残業をするなど，別の方法を取る必要がある．プロは「イエス」と言えるような創造的な方法を探さなければならない．
（多分，テストを後回しにしたり，長期間残業するのは創造的じゃない）
緊急対応
メネージャが期限に間に合わせるように言ってきたらどうするだろうか？ マネージャが「コレお願い！」と言ってきたらどうするだろうか？ 自分の見積もりを死守するのだ！ (p.86)
死守できるほど信じれる見積もりを持たなければ……
コーディング
音楽を聴きながら作業しない
これに関連する研究がいくつかあると聞いたことがある．調べていないので真実かはわからないが，
- 基本的には無音，あるいは自然音が良い．
- 新しいアイデアを考えたりするような想像的な作業をするときは，ざわつきが聞こえた方が良い（カフェとか）．
- 歌詞のある曲（理解できる言語）を聴きながら作業すると生産性が落ちる．
- 生産性は上がるような音楽はあるが（ゆったりした曲だったかな？），内向的な人には効果が薄い．
- 作業をする前に音楽を聴いて気分を上げると，のちの作業が捗る．ただし，作業中は音楽を聞いてはいけない．
みたいな噂がある．（TODO:ソースの追加）
ステレオをかけながらコードを書いたものだ．（中略）コードのコメントには，曲の歌詞と爆撃機や泣き叫ぶ赤ん坊のことが書かれていた．(p.80)
まぁ，聴いている曲の歌詞をコメントに残しちゃう人なら間違いなく聞かないほうが良いとは思う．
フロー（ゾーン）について
1人の時間が不要というわけではない．もちろんそれは必要だ．（中略）例えば，10時から12時までは話しかけないでほしいと周知しておき，13時から15時まではドアを開けたままにしておくといった具合だ．(p.88)
あらかじめ時間を決めておくことで割り込みを制御する，という手法を認めつつも，
問題は，ゾーンに入ると大局観を失ってしまうことだ．（p.79）
ペアプログラミングの大きな利点は，ペアでゾーンに入るのは事実上不可能なことにある．(p,79)
ワークステーションでコードを書いているときの自分を思い浮かべてみよう．（中略）感じの悪い反応はゾーンと関係していることが多い．（中略）ただし，悪いのはゾーンではなく，集中力が必要なことを1人で理解しようとすることだ．(p.80~81)
ここでいう「ゾーン」は「フロー」と同じような意味で，深い集中状態に入っていることを示す．
上記のように，「ゾーン」を意図的に避けることを提案しており，ペアで作業をすることをそこそこ推奨している．（ペアプログラミングをしよう！ という直接的な推奨は本書ではされていない）．
『フロー体験 喜びの現象学』では「フロー」を良いものとして扱っており，噂ではちょっとした割り込みで集中状態が解かれ，もとの集中している状態に戻るのには10分以上もかかるという（TODO：ソースの追加）．だから，「フロー」に入る・維持することは重要だと思っていたけど，それ以外の考えもあるらしい．
割り込みへの対処法として，あらかじめ「何で割り込まれそうか」「割り込まれた際の行動をどうするか」を考えておくというものがある（TODO：ソースの追加）．
まとめ
- コードが動くことに責任を持つ
- どうしても無理なら「ノー」というが，「イエス」をいえるような手法を探す
- テスト大事
- 割り込みを対処できるようにしておく