はじめに
プラットフォームエンジニアは、大規模なプログラムはともかく、自動化のためのツールなど中小規模のプログラムを書く機会はしばしばあります。したがって、むちゃくちゃなコードを書かない最低限のプログラム設計スキルが求められます。
そこで今回は、理解しやすいコードが書けるようになる方法を紹介します。
『リーダブルコード』を読もう
まずは『リーダブルコード ―より良いコードを書くためのシンプルで実践的なテクニック』を通読しましょう。
どんな本なのかは以下紹介文を読むとわかると思います。
コードは理解しやすくなければならない。本書はこの原則を日々のコーディングの様々な場面に当てはめる方法を紹介します。
リーダブルコード ―より良いコードを書くためのシンプルで実践的なテクニック
名前の付け方、コメントの書き方など表面上の改善について。コードを動かすための制御フロー、論理式、変数などループとロジックについて。
またコードを再構成するための方法。さらにテストの書き方などについて、楽しいイラストと共に説明しています。
マインドマップにまとめよう
本の内容をマインドマップにまとめていきましょう。私の場合は以下のようにまとめています。
著作権の問題があるので、一部除いて情報を隠しています。まとめるポイントは次の通りです。
- 「理解しやすいコードを書けるようにするため」という目的を忘れない
- あえて詳細には踏み込まない
「理解しやすいコードを書けるようにするため」という目的を忘れない
目的に沿った内容をまとめるようにしましょう。
たとえば、この本には実践編となる「第Ⅳ部 選抜テーマ」というセクションがあります。このセクションはあくまで学んだことの実践編なので、新たな技法が出てくるわけではありません。したがって、このセクションの内容を愚直にまとめるメリットは大きくないためマインドマップに反映しないという判断をしました。
あえて詳細には踏み込まない
あまり細かい部分まで書く必要はないでしょう。
基準としては「リーダブルコードを読んで理解した人にとって何が書いてあるかわかる程度」です。リーダブルコードを読んだことがない人向けに書くのは無駄に工数がかかります。工数削減というメリット以上に、この基準で書いた内容がわからなければ本を見返した方がいいレベルまで忘れていることがわかる、というメリットもあるので便利です。
たとえば[命名 > 明確な単語を選ぶ]を見てみましょう。リーダブルコードを読んだことがない人にとっては意味不明なメモだと思います。一方で、読んで理解したことがある人なら「GetPage()
だとどこからページを取ってくるのか不明確。インターネットから取ってくる前提だったらFetchPage()
という命名にした方が明確でわかりやすい。ということが書いてあったな。」ということがわかると思います。
マインドマップを定期的に見返そう
定期的に見返して「何が書いてあるのかよくわからん」と思う箇所がないか点検しましょう。もしあれば、書籍を見返してあらためて理解しましょう。
もちろん、コードを書くとき、レビューするときも見返しましょう。経験上、このくらいやらないと本の内容はいつまで経っても身につきません。
さいごに
今回は理解しやすいコードを書けるようになるまでのトレーニング方法を紹介しました。自分で実際にやってみて効果を実感しているやり方なので、ぜひやってみてくださいね。
コメント