見出し画像

「プログラムを読む技術」を読んだ

はじめに

何で知ったのか覚えていないけど、気が付いたら買っていたのでちょっと感想を書くことにする。

感想

chapter1

読む力が必要なのかって言われたら書く時間より読む時間の方が多くなるから力は必要だなって漠然と思っていたけど、それの具体的な例が書かれている。
実際にどんな場面で読むのか、

  • 書籍などのサンプルプログラム

  • 先輩、後輩、知人、過去の自分が書いたのプログラム

仕事していたら、後者が多いけど、なぜ読まないといけないのか

  • バグの修正

  • 機能追加、仕様変更

  • レビュー

このあたり読むことになるけど、これらを行うためにはたくさん読む必要もあるし、読む力も欲しくなるって話

最後にたくさん読めばスキルアップに繋がるってことが書かれている。

chapter2

他人のプログラムを読むのが難しいのかについて書かれている。

  • 設計に対する考え方の違い

  • 書き方のクセの違い

  • スキルの違い

この3点の違いに注目したが、結局のところ最後のスキルの違いの一言で片付いてしまうのかもしれない。
自分よりスキルの高い/低いと思う人の書いたプログラムをどこまで理解できるのか、これはこのあとのchapter4に書かれてた書いた人に聞くこれを実践するしかないのだろうなーって思う。
書き方のクセは何回か読んでいると、あの人が書いたやつだとかわかってくる。わかってくると読みやすいかっていうと話は別ではあるけど、この本では、長い処理を書くと読みづらい、同じ処理は1つの関数にしようと書かれている。決まった処理は1つの場所に書かれていれば読みやすくなるのはわかる。

chapter3〜8

ここからサンプルプログラムが増えてきて読み飛ばした。
プログラムを読む技術の本なので読んだ方がいいのかもしれないけど、プログラムは本で読むよりは何かしらのエディタを使って読みたい気持ちになる。
なので、個人的に少し長めのサンプルコードがあるとちょっと読むのを諦めた。
ただ、先ほど書いた通り、chapter4については、プログラムを読む前にやるべきことが書かれているので、ここは読んだ。
やはり、ドキュメントを読む、書いた人に聞く、このあたりはプログラムを読む以上に大事なことではある。

まとめ

さっと読んだ感じの感想でした。

chapter1、chapter2を読んでおけば大体は満足できる本な気がします。
chapter3以降は2つの補足的に捉えればいいかもしれないです。


いいなと思ったら応援しよう!

この記事が参加している募集