はじめに

「プログラマが知るべき97のこと」の感想文（前編）の続きです。

以下、感想文

54.見えないものを見えるように

不確実なものをより確実に
やっぱテストは書け
具体的な形がある画面から考えるのが誰にとってもわかりやすいよなぁ

55.並行処理に有効なメッセージパッシング

グローバル変数はやめよう

56.未来へのメッセージ

誰かのためでも構わないし、未来の自分のためでも構わないから可読性は重視しろ
動くコードこそ神であることに違いはないが、だからといって独りよがりなコーディングをすることは望ましくない。特にチームで開発し、保守することが前提にあるならば。
賢人は難しいことを誰にでもわかるように説明できる。難しい問題をよりシンプルに解決できるようになりたい

57.ポリモーフィズムの利用機会を見逃さない

ポリモーフィズムはOOPの基本
手続き的に書くよりもクラス作ってモジュール分割したほうがいい場合が多いということ
コンテキストを理解してクラスを作るためには、ビジネスドメインを知ることが不可欠

58.テスト担当者はプログラマの友人

プログラムでバグが見つかることは恥ではない。恥ずかしいことはリリース後にぬるぽみたいなダサいバグが発生すること
テスト担当者を敵だと考える思考はプログラマの驕りでしかない。謙虚になれ
テスト担当者になったら、もし仕様の誤りがあったときにテストで気づき拾えるような仕事ができるようになりたい

59.バイナリは常に1つ

ビルド中にコードの一部分を書き換え、カスタムバイナリを生成する -> ちょっとよくわからない。ビルド中にコードを書き換えるなんて意味不明なことする必要あるのか
バイナリってバージョン管理と相性悪いのでは？
できる限り環境に対する変数はイミュータブルになっていたほうがいいってことか？

60.真実を語るはコードのみ

ドキュメント規約を用意しても、テンプレートやサンプルを用意しても、常に安定して、均質で、同じ表現が使われていて、知りたいすべての情報が書かれた100%のドキュメントを作れるわけがない
コードも同じことである。ただし、コードはプログラムとして動く。ドキュメントは動かない。動くものこそが正であることは間違いない
そうであればこそ、コードは読みやすく書くに限る

61.ビルドをおろそかにしない

CIもプロダクト開発の一部であることを自覚しろ
オレのマシンでは動いてるよ(byエンジニアの名言メーゲン)にならないようにしろ
つまりはCIについてもっと勉強しろ

62.プリミティブ型よりドメイン固有の型を

ほんとこれ。ビジネスドメインの内容でクラスを作ってそれを型とすることこそがOOP
単一責任の原則にも反しにくくなる
JavaBeansパターン悪説

63.ユーザの操作ミスを防止する

フロントエンドに必要なことは思いやり。ユーザと開発者と間には情報の非対称性が存在しているから、それを埋めるよう開発者が努力しろ
ユーザに入力を求める画面のデザインはユニバーサルデザインであるべき。一番いいのはユーザがひと目見て何を入力すればよいかわかるデザイン
どんなに素晴らしいデザインでも入力ミスは発生する。その時のエラーメッセージもわかりやすく、かつユーザを苛立たせないメッセージにしろ。開発者の文章力の問題

64.プロのプログラマとは？

プログラマに教育を受けさせるのは会社の責任だというのは完全に間違い -> これには異論あり。多くの人間は最初から自分の価値を高めようなんて意識を持っていない。会社、あるいは組織はメンバーにその意識を持たせようと思わせることができる会社、組織作りをする努力をしたほうがいい。システムとして強制しないと、よほどできる人間でない限りやろうとしない。
プログラマを使う側の人間は、プログラマの怠惰をすべてプログラマの責任だと考えること自体が間違っている。プログラマも含めた全員が、課題・問題に対して自分の責任を追求し、改善を考える思考を持て。
最善の努力を尽くして良い製品を作ること -> プロダクト指向は重要。ただしビジネスサイドに理解されているかは別問題。ビジネスサイドはプロダクトよりも金を稼ぐことに興味がある(場合もある)。ここでビジネスサイドと技術サイドの意志の齟齬が発生する。
- Quick & Dirtyの神話。質と速さはトレードオフではない。時間を与えたからといって質の高い製品ができあがるわけではない。

65.バージョン管理システムを有効に使う

コミット・エンド・ランされないようなフックする仕組みを組み込みたい
コードだけでなく、関連するドキュメント全てバージョン管理システムで管理したい
バージョン管理したいから、バイナリファイルでドキュメント書きたくないよね
- ↑暗にExcel嫌いと言っています。

66.いったんコンピュータから離れてみる

なにかまったく別のことをやってて、そのことについて考えてもいないのに急にふと降りてくることってあるよね
コンピュータから離れるために山登りに行きます
っつって山でスマホポチポチしてるかもね

67.コードを読む

コードを書くことは大好きなのに、コードを読むのは嫌 -> 確かに妙なことだ
他人が読むのを嫌がらないようなコーディングしろ
AtCoderとかOSSとかでコード読むことが勉強になる

68.「人間」を知る

開発はだいたいがチームで行うもの。そのためコミュニケーションは不可欠。テレパシーができるわけではないから、自分の思考を完全に伝達することはできない
比喩は物事をわかりやすくするが、それで本質が理解できるわけではない。最終的には小難しい理論を自分の中で納得する必要がある。OOPの説明とかがいい例。変に比喩で現実世界に存在するクラスを作るから、ちゃんとした理解と納得にたどり着くまでに時間がかかる。
自分自身がユーザだったときのことを考えてプログラムしろ。

69.車輪の再発明の効用

失敗こそ貴重な財産。どんどん試行錯誤し、失敗しろ。
実際に試すことが大事。百聞は一見にしかず。ただし、人の時間は限られており、自分が経験できることにも限りがある。だから他人の経験をメディアから学ぶことも重要。
1から作るということは筋トレのようなものってことか。

70.シングルトンパターンの誘惑に負けない

デザインパターンって出来たの90年代だし、再考してまとめた本出してほしい。
シングルトンってもはやアンチパターンだろ。
SpringのDIもデフォルトでシングルトンって罠じゃん。

71.パフォーマンスへの道は地雷コードで敷き詰められている

これってパフォーマンスだけじゃなくて、機能改修のときも同じことが言える。
ホットスポットをメソッドとして独立させておいて、テストコードが用意されていれば改修も楽にるよね。
循環的複雑度を測ろう。

72.シンプルさは捨てることによって得られる

既存のコードがひどかったらそれを放置せず、せめて自分が触る部分はきれいにするという精神を持て。
目の前で作ったコード消すっていうのは上の人間がやるべきではない。見せしめみたいな行為だし、間違いを一緒に改善しようっていう意思を感じられない。心理的安全性が損なわれる。
下手に改修コード加えるぐらいなら全消ししてやり直したほうが速いってこともある。
- でも今動いているコードはテストをパスしている神であるから、それを消すっていのうは乱暴すぎるんじゃないか？影響範囲によってはどこまでテストするの？っていう議論になる。

73.単一責任原則

むずい
共通化よりも特化
特化しすぎると無尽蔵にクラスが増えるものではなくて？SRPが遵守されたWebシステムのコード見たことないからわからん

74.「イエス」から始める

「イエスマン」を見よう。
とりあえず否定から始める人より、まずは受け止める人のほうが印象がいいって何度言及されていることか。
物事の背景を知った上で回答することも大切。

75.面倒でも自動化できることは自動化する

テストだけでなく、日常業務でルーティン化されているものはスクリプトを組もう。
これRPAのことだよね。
初期投資はかかるができるところから自動化しろ。

76.コード分析ツールを利用する

ツールを活用し、コードの品質を上げろ。
循環的複雑度を解析して、技術的負債を溜め込まないようにしろ。
プロジェクトごとの規約をチェックできるように独自の静的チェックの設定をして、強制的にチームメンバーのコードを標準化しろ。

77.偶然の仕様ではなく本物の仕様のためのテストを書く

実装の都合でたまたまそうしている、という部分を「偶然の仕様」って呼ぶのいいね。
単体テストもユースケースに基づいたテストを書け。
改修してテストも修正した際に、本当の仕様から偶然の仕様にならないように注意しろ。

78.テストは夜間と週末に

合理的に考えれば、自分がPCを動かさない時間帯に他の仕事をPCにさせておくという結論に至るのは当たり前だよなぁ？
だから自動化できるものはなるべく自動化しておけ。
その自動化した処理が正しい動作をするかを担保することも重要。

79.テストのないソフトウェア開発はあり得ない

IT土方と呼ばれるが、共通点は働き方だけってことか。
テストを書く時間がないのではない。テストを書かないから時間がなくなる。
テストを書くことはエチケット。書いていない人は「私は無責任です」と言っているようなもの。

80.1人より2人

プログラマはもはや、技術が優れているだけでは十分でない->もはやというほどの話だろうか。プログラマに限らず、技術だけあってもコミュニケーション取れないと一緒に働くことはできない。
ペアプロ万歳！
最初こそ1つの仕事に2つのリソースが割かれることは無駄のように思えるが、それによって得られる知識や経験が個々人に蓄積されて、ある時点を境に作業効率が上がるのだろう。

81.エラーがエラーを相殺してしまう

マイナス×マイナスでプラスになる理論。
1つのバグを直して正しいものにしたら、他のバグが芋づる式に出てくる恐ろしさ。これがリリース後に起きたら地獄。
だからモジュールごとの依存性を低くしておくことが重要。

82.他者への思いやりを意識したコーディング

他人は思いやれなくても、未来の自分は思いやれるだろう。1ヶ月後、書いたコードを読み返すときに過去の自分を恨まないようなコーディングをしろ。
ZENモードに突入できるように、ヘッドホン着用を許可しろ。
- その境地に至る必要があるほどのプロダクト作ってないだろ。
  - 確かに。
Ubuntuは元々、ズールー語で「他者への思いやり」というような意味->20回へぇボタン押しました。Ubuntuの訳の意味も知らずにボーッと生きていました。

83.UNIXツールを友にする

もし無人島にIDEかUNIXツールのどちらかしか持って行けないとしたら->こんな2択は嫌だ。
プラグイン盛々動作激重のIDEを持っていって、少し動かしては食料探したり、寝床作ったりしてサバイバルするのがちょうどいいのでは？
私はいろいろ適度に最初から揃っているIDEのほうが好きです。

84.正しいアルゴリズムとデータ構造を選ぶ

無駄のない処理を書こう。
経験が浅いプログラマも、別に何も考えずにコードを書いているわけではない。そのときの実力で最大限の努力はしているはず。だから、コードレビューでスキルを教えてあげよう。

85.冗長なログは眠りを妨げる

DEBUG,INFO,WARN,ERRORをうまく使い分けよう。
動くものを作るだけではなく、運用を見据えてログ出力処理も書き込め。それを強制する静的チェックも入れろ。
ログ見てもよくわかんねえからローカルでデバッグして一から追わなきゃってなるのが最悪。

86.WETなシステムはボトルネックが見つかりにくい

DRYの反対としてWET（write every time）という略語にできていることが面白い。
WETだとボトルネックを一箇所直しても、他の処理は遅いままってこと。

87.プログラマとテスターが協力してできること

FIT？ATDD？初知り。
プログラミングもテストも自分でやっているから協力しあうというイメージがよくわからなかった。
バグを憎んで人を憎まず。この精神を忘れないようにしよう。

88.コードは生涯サポートするつもりで書く

あくまで「つもり」だからセーフ。
とりあえずリーダブルコードは何回でも読んどけ。
いいものは認められる。誰かが必ず評価する。だから常にいいものを作る、いいことをするという気持ちを忘れるな。

89.関数の「サイズ」を小さくする

関数が返却する可能性をなるべく減らすということか。
問題領域固有の型を使う->これってDDDで解決できる問題じゃないのか？
プログラミングにおいて、テクニカルな知識も大事だがドメイン知識も重要だということ。

90.コードを見る人のためにテストを書く

良いテストはドキュメントのようなはたらきをします->完全に同意。単体テストは仕様を表す。
- だいたいプログラマってのは設計書のドキュメントを読むよりコード読んでいるほうが楽しさを感じる生き物だから、なにもかもコードで表現されているほうが仕事のやる気も出るってもんなんだよ。
  - 主語がでけえよ。
テストのテストをするのも良いこと->この発想はなかった。仕様として定義されたテストをエラーコードによって保証するということか。やろう。
誰でも理解できるテストを書け。

91.良いプログラマになるには

今週はたまたま星回りが良いから良いコードができた->草。
結局はテクニックじゃなくて精神の問題になるんだよね。おれおれな態度で仕事していたら人はそっと離れていく。それはコードにも表れるということ。
正しさって、どこまで、どれだけ人に確認すればそれが担保されるのだろうか？

92.顧客の言葉はそのまま受け取らない

顧客が要求しているものと、顧客が本当に必要だったものには往々にして差異があるということ。
ビジネスドメイン言語の意味は人によって千差万別。絵や図は共通。つまりは絵と図を使って会話しよう。宇宙人とコミュニケーションをとるつもりでいろ。
ああ、私、「黒」って言いましたけど、あれは「白」っていう意味なんですよ…->？？？？？？こんなん言われたら発狂するわ。

93.エラーを無視するな

体も心もコードも不全が発生している場合には必ず信号を出す。エラーは必ずキャッチしてコントロールしろ。
納期が迫っているのに、余分な仕事を増やすわけにはいかない->Quick & Dirtyの神話。怠惰なコードを書いたツケが必ずどこかで回ってくる。そしてそれは納期間近になることもしばしば。
やはり気持ちの持ちよう。良いコードを書く技術を持っているかどうかではなく、良いコードを書こうとしているかという姿勢の問題だと思う。技術はコードレビューで学べばいい。

94.リンカは魔法のプログラムではない

リンカ知りませんでした。雑魚乙。
プログラムがなぜ、どうやって動くかのを知ろう。
基本となるプログラムほどシンプルで、設計の参考・知見となる。

95.ペアプログラミングと「フロー」

ペアプロはプログラマーズハイを持続させる。
ペアプロはリスクを分散させる。知識を共有し属人化を防いだり、課題の解決法を知っている確率が高まり解決されやすかったりする。
- ペアプロじゃなくても知識はドキュメント化されていればいいし、課題の解決はその時人に聞くこともできるよね。
  - ペアプロはそれらを容易に行える方法の1つであるというだけ。なぜならそれらが半強制的になるから。
  - 大概、知識のドキュメント化は進まないし、人に聞きたくても聞けない状況とか心理とかって場合が多い気がする。
パートナーが作業を引き継ぐっていう視点はなかった。

96.テストは正確に、具体的に

もう1つは、非常に複雑にして、欠陥があっても一見しただけではわからないようにするという方法である->草。
AAAが正確な仕様を表していればOKってこと。
誤解の余地がないように単一責任の制限されたオブジェクトを作る設計をしろ。

97.ステートに注目する

状態って列挙で表現するとプログラムしやすいって思っている。StateパターンもStrategyパターンもほぼ同じだし。
ステートに注目して考えれば、コードをよりシンプルに、そして堅牢にすることにつながります->コードっていうより設計がシンプルかつ堅牢になるっていうことだと思う。

98.命を吹き込む魔法

言霊的なこと？ちょっと違うか。
許されるなら無駄に長たらしくかっこいい名前とかがよくね？っていう厨二病の感想。
まず作る側がプロダクトを愛さなければ、ユーザにも愛されるわけがない。そのための一歩としてコードネームをつけるというのはありだと思う。

99.ロールプレイングゲーム

別にプログラマに限らず、人は誰しも仮面をかぶって生きているって社会学的には当たり前のお話なんじゃないの？
演じていれば、それが身につく。強いてやっていれば、それが自然とできるようになる。これもスポーツの練習とかと変わらないだろ。
演じるとはいっても、一定の境界線を決めておくことは大切だと思う。仕事だからといって割り切れることと割り切れないことって必ずあるから。

100.ルーチンワークをフローのきっかけに

助走のためのルーチンワークっていう考え方はあり。
腰が重いことでも、いざやり始めればどんどんハマっていくってよくあることだと思う。
私は時間で区切るっていうやり方をすることが多い気がする。

101.プログラマが持つべき3つのスキル

コード読む、テストする、デバッグするの3つのスキルの習得のために、OSSの開発を参考にするってなかなかレベル高くない？
- 向上心ねぇなぁ。
というか、なんでこの3つを特筆しているの？
プログラミングの好き具合によってスキルを上げていけばいいと思う。

102.快適な環境を追求する

自分が仕事しやすい環境にするのは当たり前だよなぁ？
BYODってどこまで許される？私はトラックボールマウスにしました。本当はメモリも追加したいし、心の癒やしとしてカービィのミニフィギュアも起きたいんだが。
デバイスとかツールだけでなく、テストを当たり前に書く意識とか、技術的助言をすぐ周りの人に求められる心理的安全性とか、内面の環境も整備しよう。

103.見知らぬ人ともうまくやるには

はじめから「出来ていいことだけを出来るようにする」と考える->ほんとこれ。常に必要なものだけ考えたい。
権限設定とその管理って難しいよね。

104.不具合にテストを書いて立ち向かう

不具合が起こること自体は悪いことではない。そこでテストを書くことによってさらなるコードの理解に繋がるので、取り扱い方によってはむしろプラスになる。
ペアプロのことでも思ったが、一見時間がかかることをやっているように見えて、それが後の利益に繋がるっていうことを理解しろ。
いまだにTDDとBDDの違いがいまいち理解できていない。

105.育ちのよいコード

育ちのよいコードって上手に改修、機能追加されて成長したコードのことを指しているのね。タイトル見て、プログラマの育ちのよさがコードにも現れている的な内容なのかと思った。
すでに出来上がっているコードを知るための近道としての知見って感じ。
育ちのよいコードを書いていけるようになりたいですわおほほほほ。

106.Noといえることの大事さ

まずは聞き入れるという意味でYes。そこから背景を聞き出し、本当に必要かを判断してYes or Noの決断をする。
作る側も顧客側も納得するところまでたどり着いてからでないと、合意なき期待が裏切られたと感じてコミュニケーションの不和が発生する。
作る側と顧客側という関係でなく、部下と上司という関係でも同じ。仕事を振られたときにも必要に応じてNoと言えるようになろう。常にYesと言っていたら自分を擦り切らすことになる。

107.名前重要

名前が重要なのは間違いない。小さなところで言えば変数名、大きなところになってくれば製品名、その名前を知って使う人が理解しやすく親しみやすいように命名しろ。
名は体を表す。
プログラミングってまずは技術的な知識よりも言語能力のほうが重要ってことかな。国語の授業はバカにできないということ。

プロジェクトマネージャーが知るべき97のことへ続く

プロジェクトマネージャーが知るべき97のことも読んでいるので感想文書くつもりです。
裏世界ピクニックシリーズと息吹読み終わったら書きます。