『プリンシプル オブ プログラミング』読書記録　第５章

3433 ワード
プリンシプルオブプログラミング プリンシプルオブプログラミング テキストリンク

はじめに

今回『プリンシプル オブ プログラミング』という本を読みましたので、自分なりにアウトプットしていく目的でまとめます。
リンク：『プリンシプル オブ プログラミング ３年目までに身につけたい一生役立つ101の原理原則』

第５章　習慣〜プログラマのルーティーン〜

プログラマの３大美徳

　プログラマの３大美徳として「怠慢」「短気」「傲慢」が挙げられる。

  • 「怠慢」

    • 何度も繰り返すような作業を自動化するなど全体の労力を減らすために手間を惜しまない気質。

  • 「短気」

    • コンピュータ効率の悪い動きや、思い通りで無い動きをしている時に我慢せずすぐに直す気質。

  • 「傲慢」

    • プロの意識を持ち、自分のコードについて責任を持って恥ずかしくないコードを書く気質。

　一般的な職業美徳に「一生懸命」「我武者羅」など、ハードワークを意味するものがあるが、これはプログラマには当てはまらない。むしろ、自分の仕事の中での「無駄」を常に観察し効率化していく姿勢が必要である。例えば、繰り返し作業の仕組み化(「怠慢」)や、要望や変更が出そうな部分の事前の見極めと対応（「短気」）、プロ意識を持った保守（「傲慢」）など、働く時間や労力を減らすことがプロジェクトへの貢献に繋がる。

ボーイスカウトの規則

　Github等でコードをコミットする際には、コードをリポジトリからpullした時よりきれいにしてコミットをすることを心がける。小さな部分、例えば重複の排除や変数名の改良などでも、コードの腐敗を防ぐため積み重ねていくことが肝要である。コードは時間の経過に伴って品質が低下していく傾向にあるため、プロジェクトに関わる全プログラマがこのようなことを意識してコーディングすることが大切である。
　また、プログラミングは最短距離で目先の時間やコストを稼ごうとすると、あとで余計に時間やコストがかかることが往々にしてある。ユニットテストや、アーキテクチャ、ライブラリの選定などおろそかにしないことで、結果的に近道を取ることが出来る。

パフォーマンスチューニングの箴言

　パフォーマンスチューニングとは速いコードを書くことであり「最適化」とも言われる。この「最適化」を早い段階で行うと、様々な弊害を生む。

  • 可読性の低下
    • 「最適化」を行うともとよりも直接的ではないロジックで組むことになるため、可読性が下がる。
  • 品質の低下
    • アルゴリズムの流れが明瞭でないコードは障害を見逃しやすくなるため品質も下がりやすくなる。
  • 複雑性の増大
    • モジュール間の依存性の強化や結合度の高いコードなど、複雑で移植性のないコードとなる。
  • 保守の阻害
    • 処理の流れを追いにくくなるため、保守もしづらくなる。
  • 環境間の競合
    • ある環境に特化した最適化を行うと別の環境でのパフォーマンスの低下を招く。
  • 作業量の増大
    • 最適化は大きなコストのかかる作業であり、また真の原因を特定して的を絞った作業を行う事は容易ではないため、労力の浪費になる場合もある。

　このような理由で、まずは良いコードを作成し、それから最適化について本当に行うべきか検討していく必要がある。最適化は割に合わないことも多々あるので、状況とよく照らして考える必要がある。

エゴレスプログラミング

　プログラミングにおいては「エゴ」を捨てることが必要である。気をつけるべき点が「エゴレスプログラミングの十戒」という形で10個挙げられている。

  • 自分自身も間違いを犯すことを理解し、受け入れる
  • 書いたコードは、自分自身ではない
  • どれほど極めたと思っても、上には上がいる
  • 相談なしに、コードを書き直さない
  • 自分よりスキルが劣る人にも、尊敬と敬意と忍耐を持って接する
  • 世界で唯一変わらないのは、変わることである
  • 本当の権威は、地位ではなく、知識から生じる
  • 信じるもののために戦い、負けは潔く受け入れる
  • 部屋に籠りきりにならない
  • 「人に優しく、コードに厳しく」し、人ではなくコードを批評する

　上記を守りつつも、自分の仕事と自我を完全に切り離す事は難しいため、エゴのバランスを取ることが必要になってくる。

１歩ずつ少しずつ

　コードを書く上で、一度に複数の関数や処理を記述せずに、１つずつ書いてコンパイルしていくほうがよい。何か不具合が起きた際、一つ一つ行っていれば前の状態に戻すことは容易である。また、テストもコードを一気に書いてからテストを実装するのではなく、どちらも少しずつ書いていくことが必要である。
　思考に関しても同じことが言える。頭のいい人というのは手順を飛ばして考えているのではなく、やらなければならない論理ステップを構築し、各ステップをそれぞれ早く正確に行う。手順をしっかり踏んでコツコツ考えることが必要である。また、論理的に考えるためには、瞬時に答えを得ようとしたり、すぐに結論に飛びついたりせず、考えたことをアウトプットしつつ、また直感で思ったことを試しつつ、考えていく姿勢が必要となる。

TMTOWTDI

　ツール(APIなど)を設計する場合は、多くの選択肢を用意するべきである。「簡単なことは簡単に、難しいことは可能に」することを目指して取り組む。ツール自体は複雑になるが、ユーザーは多様な場面に置いてシンプルなコードを書けるようになる。様々な対象、複雑な対象をシンプルに記述するためには、ツール側である程度の複雑性・多様性を持っていたほうがよい。

　

参考文献

『プリンシプル オブ プログラミング　３年目までに身につけたい一生役立つ１０１の原理原則』上田勲 著　株式会社秀和システム　2016年3月29日　p.214-232