書籍 プリンシプルオブプログラミング 第5章 まとめ
5章
習慣 〜プログラマのルーティーン〜
5.1 プログラマの三大美徳
怠慢
全体の労力を減らすための手間を惜しまない - とにかく人の作業量を減らし、機械に仕事をさせる
繰り返しの仕組み化
- 手作業で行なっている部分を、コードを書いて自動化する(テストやビルドの自動化など)
- 最も自動化の効果がある部分を見極めて実装すること
- ドキュメントの作成も、フォーマットを作成して使いまわす
短気
- コードの不具合に対する怒り
- その怒りをコードの改善に向ける
問題を想定して行動する - ユーザからクレームが来そうな部分は、あらかじめ改善してしまう - 変更される部分とされない部分を見極め、分けて考えること - 変わらない部分をベースに、変更される部分は自由に変更できるようにする - ユーザで変更できるようにする
傲慢
- 自信を持って、誰に見られても恥ずかしくないコードを書く
- そのコードに対して、責任を持つ
人に見られても恥ずかしくない仕事をするプロ意識
- 綺麗なコードを心掛ける
- コードは機能ごとにモジュール化して管理
- 管理しやすくなる
- 他のソフトウェアで流用しやすくなる
総評：知識を使って、自分やチームの労力を減らすことに注力すること
5.2 ボーイズスカウトの法則
コードの腐敗を阻止する
コードは時間の経過と共に腐敗し、品質が低下しがちなので、それを阻止する
- 「前よりも綺麗にする」ということをチーム全員で心掛けること
コミットする際は改良してから
リポジトリから取得した時よりコードを綺麗にしてからコミットする
- 完璧は目指さないでもいい、少しでも綺麗にすること
急がば回れ
近道して品質を犠牲に、コストや時間を浮かせることは、結果的に無駄なコストの発生要因になるため、ある程度回り道をしてでも、品質を上げること
具体的には、以下のようなことは避けるべき。
ユニットテストの省略
- 手作業のテストになるため、負債が膨らみ続ける
目的が違う既存システムの流用
- 規模や機能が大きくなってくれば破綻し、結局作り直すハメになる
不適切なライブラリの放置
- 大規模化に伴い、競合の発生や無駄な複雑化を招く
5.3 パフォーマンスチューニングの箴言
速いコードは割に合わない
コードを最適化し過剰に速くしても、コードとして大切なものを失うことに繋がる
可読性の低下
- 最適化によってコードの処理が直接的なものでなくなり、意図を読み取るのが難しくなる。
品質の低下
- コードの処理が複雑になると、理解されずにスルーされてしまう部分が発生し、新たな欠陥へと繋がる。
複雑化の増大
- 最適化では、特殊なバックドアでモジュール間の連携を強めることで軽量化を実現する。そのため処理のフローが複雑になり、モジュール間で強い依存関係が構築されることで、移植性の低下も招く。
保守の阻害
- 最適化によって、コードが読みづらく理解するのが難しくなると、保守が困難になる(追いかけなければならない部分が増える)
環境間の結合
- 最適化は一つの環境に依存することが多く、別の環境で実行すると、かえって遅くなることもある
作業量の増大
- 単純に最適化という作業が増える(上記のデメリットを抱えながらも)
「良いコード」を書く
最初から最適化されたコードではなく、単純な良いコードを書くことを意識する。その上で、必要に応じて最適化していくこと。
5.4 エゴレスプログラミング
エゴを捨てる
- 自分のプライドやうぬぼれを捨て、チームで協力してコードを改善していく(お互いで積極的にコードレビューし合う)
よりよいものを作るという目的を忘れてはならない
エゴレスプログラミングの十戒(要約)
- 自分も間違えることがあり、それを素直に受け止める
- 書いたコードは自分自身ではない
- 上には上がいる
- 相談なしにコードは書き直さない(自分が正しいと思わないこと)
- スキルが低い人にも謙虚に
- 変わり続けることということは、今後もずっと起こる
- 権威は地位ではなく、知識から
- 信条に基づいて戦う、ただし負けは認める
- 部屋に篭りきらない
- 人には敬意を持ち、コードには厳しく接する
5.5 一歩ずつ少しずつ
「手堅い歩み」は効率的
小さな作業を一つずつ確実に行なう方が、結果的に効率が良い。
一度に複数やらない
複数の場所を同時に編集→実行すると、エラーの数が多くなることで原因解明が難しくなったり、ちょっとしたエラーに躓いてしまう可能性が高くなる。
機能の設計と同じよう、一つ一つの作業を細分化した上で、その中で以下に早く完成させられるかが作業の効率化において重要である。
思考も一歩ずつ着実に
ロジックを紐解くときも、いきなり1から10まで飛ばして考えない。
一つずつ着実にステップを踏み、各ステップを高速化することで、思考の高速化と高品質化を図れる。
論理的思考のコツ
- 瞬時に答えを得られると思わない、分からなくても考え続けること
- 考え始めて、すぐに答えに飛びつかない。思い込みを排除し、他の可能性も検討する
- 既に考えたこと、結論の出たことを覚えておく。何度も同じことを考え直さない
- 思考をアウトプットすることで、忘れにくくなったり、頭の中にある無駄な考えの整理も出来る
- 基本は論理だが過去の経験などから来る直感も、時には大切
- 但し直感のみで答えを導き出そうとせずに、最終的にはロジックで裏付けすること
5.6 TMTOWTDI
TMTOWTDI：やり方は一つでない
ツールの多様性は善
他人に使用してもらうAPIなどを作る際は、達成したい目標に対し手段を複数用意することで、利用者は複雑なコードを書かなくても済む。(例えば対応する言語を増やすなど)
作る側にとっては、より複雑になり時間もかかるが、APIのような複数の利用者がいるサービスの場合、使われる時間の方が長くなるため、全体を見れば効率化されたと言える。
