エンジニアが終末に備えて技術を磨く日記の26日目。
1日目はこちら。
「エンジニアが終末に備えて技術を磨く日記」カテゴリはこちら。
『リーダブルコード』を読みました。読みやすいコードの特徴を説明する本で、ある程度プログラミングに慣れてきたエンジニアが、自身のコードの質を高めるために手に取る本として有名な一冊です。
読みやすいコードとはどのようなコードか？ という大原則の解明から始まり、変数や関数の命名、コメントの書き方、コードの分割、そしてテストに至るまで、さまざまな観点から読みやすいコードの特徴を説明してくれます。
とても多くの有益な情報が書かれており、3ページに1つくらいペースで新しい学びを得られる良い本でした。すべての学びをここに書くことはできないので、一番役に立った事だけを書いておきます。
本書の10章では、汎用コードを使うことの有効性が説明されています。
製品として開発する場合、書いたコードはすべて出荷できる訳がなく、出荷前には念入りなテストと最適化が必要となります。
自分で書いたコードに対してはこれらを実施しなければなりませんが、標準ライブラリやプロジェクトのユーティリティライブラリで定義されている汎用コードは、すでにテストや最適化がなされたコードなので、問題なく使うことができます。
だから、既存のライブラリで代用できる部分は代用すべきだと紹介されています。
これはあたりまえと言えばあたりまえなのですが、こう言葉にされるまで曖昧にしか意識できていなかったので、それをはっきり意識できるようになった点で非常に役に立ちました。
大学生時代に趣味で開発していた時は、テストや最適化の重要性を理解できていませんでしたが、職業エンジニアになって製品を作るようになってからは、これらの重要性をしみじみと感じる毎日です。
自分の書いたプログラムを売って顧客からお金をもらっている以上、バグ1つの重さが趣味の個人開発とまるで違うんですね。
だから念入りにテストしないといけませんが、テストを作るのはまァめんどくさい。自分で実装した部分が多くなればなるほど、どこかにバグがひそんでいる気がして仕方がなくなり、過剰なまでにテストを作ってしまいます。
対して、標準ライブラリや先輩が作ったライブラリを使っている部分は、多分バグが起こりませんし、それ起因でバグが起きても僕の責任ではないので、プログラムを書いていて気が楽です。
既存の関数を呼び出す部分に関しては大してテストを書かなくても良いので、テストにかける時間も短くできます。
その事実に気付いていなかった訳ではないですが、明確に意識できていた訳でもないので、これを意識できるようになったのは『リーダブルコード』を読んだ大きな収穫でした。