プログラマが知るべき97のことを読み、今の自分にとって大切な考え方をピックアップ！
26. 言語だけでなく文化も学ぶ
- 多くの言語を学ぶことは、その言語の特性や文化から新たな発想を得て、同じ問題に対して違った解決策でアプローチできるようになること。
38.余分なコードは決して書かない
余分なコードを実装すると、実行時間の増加や保守の手間の原因となり得る。
では、余分の判断とはどのようなものであるか以下に示す。
- 余計かもしれないが、面白そうだと思えたコード(「面白い機能」はコードを書く理由にならない)
- 将来必要になるかもしれないと思ったコード(今不要なら、今書くべきではない。)YAGNI(You Ain't Gonna Need It. それはたぶん、必要ない)の原則に反する。
- 必要かどうか判断に迷ったコード
- 議論を経ておらず、ドキュメントにも書かれていない実装(要件を決めるのは顧客である。)
41. 無駄な警告を排除する
コードが増えるにつれて、警告もたくさん出るようになっていく。その警告の中には、即座に対応を要するわけではないものが多く含まれてくる。その中から真に意味のある警告を見つけるのが困難になってくる。そうなれば「警告」が本来の役割を果たさなくなる。
意味のある「警告」を見逃さないためには、
- ビルド時に警告が1つでも出たら、必ずその場でつぶす
- 出される警告が、どう考えても大した問題につながらない場合は、警告ポリシーの変更を検討する
44.IDEを知る
IDEの中には、「メソッドの抽出」の機能が存在するものも。
メソッドの中の一部のコードを選ぶと、その部分を新たなメソッドとして切り出してくれる機能。渡すべきパラメータも全てツールが自動的に判断してくれる。
48.いろいろな言葉を学ぶ
「いろいろな言葉」とは日本語・英語などやプログラミング言語だけのことではない。
「いろいろな言葉」とは、あらゆる分野に対する知識である。
例えば、会計士と話す際には、投資資本、使用資本といった基本的な知識が必要。
あらゆる分野の人とコミュニケーションをとるためには、それぞれの分野についての知識を学ぶことが大切であり、それらの相手の話に耳を傾けることが出来ることである。
60.真実を語るのはコードのみ
要件定義書やコメントがどれほど正確に書かれていたとしても、それが真実とはなり得ない。それらはどうゆう設定で作られる「予定だったか」を語っているに過ぎないし、実装(コード)と一致しない誤ったことが記載されている可能性もある。
真実を語るのはコードのみ。それを人が理解できるようにわかりやすく書くことが大切。
67.コードを読む
コードを読むことは自分の成長につながる。様々な人の発想に触れるからだ。また、過去の自分のコードを読み返すことも、自分の成長が感じられやる気につながる。プログラミング技術を磨くためのベストプラクティスの一つとして、「コードを読むこと」が挙げられる。
77. 偶然の仕様ではなく本物の仕様のためのテストを書く
実装の絶対条件ではなく「偶然の仕様」に対してテストして確かめても意味がないし、改善や保守の際の足かせとなる。
本当にテストすべきこと、本来の要求に合っているかを考え、的確なものにする必要がある。
78. テストは夜間と週末に
勤務中(平日の日中)にパソコンのパワーを最大限発揮するために、夜間や週末にテストすることを検討してみる。
- 長時間を要するテストの場合、週末を使えば金曜午後6時から月曜午前6時までの60時間取れる。
- 他の作業を控えたいパフォーマンステストをするのに夜間と週末が適切な時間
81. エラーがエラーを相殺してしまう
エラーが複数存在する場合、エラーがエラーを相殺し、見つけ出すことが困難な場合がある。どう対処すべきか絶対的な答えはないが、そういう問題が存在し得ると認識することが大切。
84. 正しいアルゴリズムとデータ構造を選ぶ
アルゴリズムやデータ構造に関して学ぶことは大切である。
Donald Knuthの「The Art of Computer Programming」を推奨する。
85. 冗長なログは眠り妨げる
ログにあまりに多くの情報が記録されると、システムの監視には約に立たなくなる。本当に重大な問題が起きた場合以外、基本的にエラーログには何も記録されないくらいの方がいい。その場合は、エラーログにメッセージがあるというだけで、システムに重大な問題が発生しているとすぐに判断できる。
89. 関数の「サイズ」を小さくする
96. テストは正確に、具体的に
テストに「具体例」を用いることで、わかりやすく曖昧さを残さず記述できる。
テストについては正確なだけではなく、誤解の余地がないものにしなくてはならない。