リーダブルコード読み直しメモ Part.3

f:id:flat-M_M:20200407232852j:plain

リーダブルコードを改めて読み直し、終わりも見えてきた。

自分がプロジェクトを去っても、コードは残り続ける。

将来のチームメンバーのために、よりワクワクするものが作られ続けるために、今できる最大の思いやりを持ってコードを書いていこう。

はじめに

の続きです

関数やコードブロックを見た時に「そのコードが達成したい高レベルの目標は何か」を考えること。

そして、その内部実装を読んだ時に、その高レベルの目標に直接的に関係しない下位問題を解決する部分は含まれていないかを考え直す。

下位問題を解決するためのコードは別の関数に切り出すなどして抽出してあげることで、該当する関数やコードブロックが真に解決したい問題にのみ注目した内部実装とすることができ、結果として理解しやすいコードになるということ。

また、そうして抽出された下位問題を解決するためのコードは、主に汎用的なコードとなりうるもので、蓄積することで様々なプロジェクトで使うことができるライブラリになり得るメリットもある。

読みにくい関数があれば、その関数内で行われているタスクを列挙する。その上で、上記の「コードの再構成」で述べたような方法で別の関数やクラスに分割できるタスクが見えてくるはずである。また、分割しきれないタスクはそれ一つで処理のまとまりと考えることができ、コードの段落としてまとめることができる。

みるからに煩雑な実装になってしまった関数などがあれば、一度自分は何がしたいのか、その関数の高レベルの目標は何かを言語化する。

その上で、下位問題の解決に費やしている部分を別の関数に切り出すことで抽象化し、さらに切り出した関数は、抽象度の高い下位問題を解決するための関数となり、内部で使う変数名も抽象化することができる。

この項目に関しては、本に記されていたまとめをそのまま引用します。

• 不必要な機能をプロダクトから削除する。過剰な機能は持たせない
• 最も簡単に問題を解決できるような要求を考える
• 定期的に全てのAPIを読んで、標準ライブラリに慣れ親しんでおく

リーダブルコードを初めて読んだのは大学２年の時で、そのころは「作って終わり」のプロダクトばかりでその後のメンテナンスや機能拡張などは一切していなかったこともあり、「ふーん」程度に読んでいたのですが、インターンや運用しているプロダクトが徐々に出来てきた今読み直すと大きな価値がある本でした。

特に複数人で開発する際に全員がリーダブルコードで述べられている要点を意識している場合は、リーダブルコードを読む時点で、ある程度「他人にわかりやすいコードにしたい」と言う思いを抱いているからかもしれませんが開発しやすい印象があります。

今回はリーダブルコードの読後まとめを3つの記事に分けて作成しました。

誰かの参考になれば幸いです🙇‍♂️