リーダブルコード 最終回

メイン記事

こんばんは!

今日でリーダブルコードは最終回です!

<前回記事>

<読んでる本>

リーダブルコード ―より良いコードを書くためのシンプルで実践的なテクニック (Theory in practice)

順当に進めると15章「分/時間カウンタ」を設計・実装する、があるんですが、実際のプロダクトコードのため割愛します。

そしてその後に解説として、今までの知識を踏まえて、どう実践していけば良いかが紹介されています。

まず1つ目のステップはは「実際にやる」ことです。

この本に限らず、本を読んだ後って達成感があるので、「なんかもう既にやった感」があるんですよね。

でもそれは実はもったいなくて、アウトプットすることで本当に身についていくものだと思います。

なので今回の場合は知識を思い出しながら、読みやすいコードにするのはどんなテクニックが使えるか考えながら、実際にやることが大切です。

また「他の人に読んでもらう」ことも大事だと書いてあります。

自分でどんなに完璧だと思ってたコードでもレビューしてもらうとあっさり修正が見つかるなんてこと、良くあります、、、。

それと同じで自分のチェックでは割と限界がすぐにくるため、誰かに見てもらい、率直な意見をもらうことが次の成長につながります。

以前どこかでエンジニアが「作ったアプリは強引に知り合いに使ってもらう。そしたら強引に勧めたもんだから、ここが使いにくいだの平気で文句を言ってくれる。そしてそれが改善箇所になる」と言っていました。笑

ちょっと手荒ですが、まさにそういうことですよね。

次に、「当たり前にする」というステップがあります。

意識して続けることで習慣にし、それを伝染させるようにチームを巻き込めば、読みやすいコードが生まれる連鎖になります。

そして最後のステップは「コードで伝える」ことです。

チームのメンバーはその時々で入れ替わっていきます。

新しく入ってきた人が読みやすいコードで理解できれば、自然とそのルールにそった書き方をしてくれるでしょう。

口でああせいこうせい、というよりも実際に物を見せた方が遥かにわかりやすいということですね。

本書には最後に例え自分が忘れてしまってもコードを見れば思い出せるような分かりやすいコードを書きましょうと締め括っていました。

ここからは私の率直な感想を付け足していきますが、まずは「どんなコードが分かりやすいという明確なルール」を知ることができました。

そのおかげで今後は自分がレビューする場合にも自信を持って提案できると思います。

逆にちょっと難しかったポイントとしては冒頭でプログラミング言語を問わず読めると謳っていましたが、やっぱり実例は複雑なものも多く、ある程度言語知識がないと理解が難しかったです。

自分的には読む人のことを想ってコードを書こう!というのが1番のメッセージではないかなと思いました。

あとはその使い所ですが、なんでもかんでも時間をかけて分かりやすくすればいいというわけではなく、そのコードが今後どのくらい読まれ、どのくらい処理で使われるのかを意識し、1度しか使われないとか、一時的な対応であとで修正する箇所にまで時間をかけることのないようにすることも大切ですね。

ということで「リーダブルコード」でした!

2021.2.11 ガオ

コメント

タイトルとURLをコピーしました