こんにちは。

りゅーそうです。

早速ですが、先日名著「リーダブルコード」を読み終えました。（プログラミング勉強歴半年以上で、今更感が強いですが。）

とても参考になった書籍でした。

「リーダブルコード」を書きたい！と思わせてくれる内容で、読んでいない方にぜひおすすめしたいです。

ということで、今回は「リーダブルコード」の感想です。

内容を細かく述べたりとかそんな不毛なことはしません（本読めばわかることだと思うので）。

実務未経験の僕でもすぐに取り入れられそうなことが多く書いてあったので、「これからはこんなことを意識してコードを書くぞ！」という決意表明をしたいと思います。

では、スタート〜！

１.後から読む人が読みやすいコードを書きます！

いきなり抽象的すぎてすいません。でも、この本から学んだ重要なテーマだと思います。

では読みやすいコードとはなんなのか？自分は今まで、短いコードが良いコードだと思っていたことがありました。長いコードのことが良いこともある。

その文章にはっとさせられました。例えば、if文と三項演算子どちらを使うのか？短さで言えば三項演算子なのかもしれません。けれども、処理のフローがわかりやすい方を選んで書くのが重要だと述べられていました。

単に効率だけを求めるのではなく、分かりやすさを重視する！それは最終的にチームの開発速度（自分自身がコードを読み直すことももちろんあります）を向上させることに繋がる。

頭の良いコードは求められていない。確かに高度な処理を書くことはエンジニアの生きがいのような気がするけれども、「後から読む人が分かりやすいコード」を書くのが「リーダブルコード」。

著書の中にありますが、エンジニアが直接システムに反映させるコードを書く時間は1日平均10行ほどだそうです。それだけコードを読む時間、その他の処理を書いている時間が多いということですね。読みやすいコードをかけるように心がけたいです。（具体的な内容は本書で。）

２.コメントにこだわってコードを書きます！

１の決意が抽象的すぎて、全ての内容が含まれてしまっているような気がしますが、、、笑

本書ではコメントの重要性についても述べられています。コメントにもこだわってコードを書いていこうと思いました。

コメントのためのコメントを書かない。処理を説明をしているだけのコメント。コメントで説明する前に変数名は適切か？処理は分かりやすいものがかけているか？など、コメント単体で考えるのではなく、その処理の分かりやすさも含めて書いていく必要があると思いました。

この話題の際に思い出したのが、この記事。

コメントについても勉強です。チームに欠かせないですよね。

３.「1度に1つのタスク」を徹底します。

分かりにくいコードの典型例が、一度の処理・関数に様々なタスクを与えるということです。一つに様々な処理が入ってしまっているので、処理のフローは分かりにくいものになってしまいます。また、一つの関数にタスクが多く詰め込まれていると、機能の追加の実装の際に苦労してしまうことになります。なので、本書では

巨大なコードは分割する。

1度に１つのタスクということを徹底する。　

ことの重要性が述べられています。このことを心がけて、コードを書いていけたらと思います。

この部分を読んでいた時に思い出したのがこちらのQiita

SOLID原則と呼ばれるやつですね。まさに現在の設計論にも繋がる話でした。

このあたりの原則を意識してReactは実装されているのでReact好きだなあ〜。

まとめ

もちろんこれ以外にも様々な原則・重要なことが書かれていたので、まだ読んでいない方は読んでみることをおすすめします。

サンプルコード等一切のせず、読みづらいものとなってしまいました。ここまで読んでくださってくださりありがとうございます。（本書ではたくさんのサンプルコードがのっています）

「リーダブルコード」を書きましょう！