解説 - TKBTK48/ReadableCode GitHub Wiki

解説

本書の内容を身につけて、自然にリーダブルコードを書けるようになるための3つのステップを紹介しよう。

  • 実際にやる
  • 当たり前にする
  • コードで伝える

1.実際にやる

まず 1 つめのステップは、実際にやるということだ。

当たり前だけどこれはとても大事なことだ。本書の内容を実践して、これから書くコードはリーダブルコードにしよう。実際にやるとはじめて気づくことがたくさんある。

実際にやるとぶつかること

まず、内容を活かす場所がぜんぜんないって思うだろう。でも、それはあなたの書いたコードがすでにリーダブルだからじゃない。単に「気づかない」からだ。実際のコードにはそういうヒントはないんだから、実際のコードを読んでいるときは見逃してしまうだろう。それが自分が書いている真っ最中のコードならなおさらだ。

他の人に読んでもらう

今、さらっと私に見せてみるといいなんて書いたけど、自分が書いたコードを人に読んでもらうということは、リーダブルコードを書くためのとてもいい機会になる。本書の中で、「他の人がこのコードを読んでどう思うか」ということを何度も気にしていたのを覚えているだろうか。

仲間と一緒にコードを書いているなら、仲間に見てもらうのがいいだろう。でも、そのときは「気になるところがあったら遠慮せずに言ってくれ!」と念を押すことを忘れずに。

おさらい

自然にリーダブルコードを書けるようになるための1つめのステップは、実際にやるということだ。

2.当たり前にする

次のステップは当たり前にするということだ。

一時の頑張りだけではリーダブルコードにはならない。もし、それを忘れてしまうとせっかくの意気込みが消えてしまう。それはとてももったいないことだ。

既存のコードをリーダブルにする前にやること

あなたが既存のコードを直し始めたとしよう。でも、仲間たちはその間も新しいコードを書いている。それらのコードはリーダブルコードではないかもしれない。まずは新しく書くコードがリーダブルコードだけになるようにしよう。既存のコードを直すことはそれまでガマンして欲しい。 他の人が新しく書いたコードについても同じくリーダブルコードにしていく。リーダブルじゃないコードだったらその人と相談してリーダブルコードにしよう。 これを続けてリーダブルコードを書くことを当たり前なことにしよう。

続けることが大事

本書で説明しているリーダブルコードを書くための方法は小さな基本的なことばかりだ。ソフトウェア全体をキレイにまとめるパターンなんかではない。1つの方法ではコードが少しキレイになるだけだ。しかし、これらの方法をコード全体に適用していけばコード全体がキレイなリーダブルコードになる。

3.コードで伝える

最後のステップはコードで伝えるということだ。

リーダブルコードがもっと当たり前であり続けるために

あなたには仲間が増える。それは若い子だったり新人だったりするかもしれない。新しい仲間は本書を読む前のあなたと同じだ。最後のステップでは新しい仲間を手伝って、新しい仲間もリーダブルコードを書くことが当たり前になれるようにする。ちょうど本書の著者があなたにやってくれたように。

コミットメールのススメ

ソフトウェアはコードの変更の積み重ねで作られている。それを管理するためのソフトウェアが Git や Subversion などのバージョン管理システムだ。リーダブルコードを書こうと試行錯誤するときにとても役立つ。仲間とコードを共有することにも便利だ。

コミットメールも用意しよう。コミットメールとはバージョン管理システムに変更を追加(コミット)したときに送られる通知メールのことだ。コミットした人は誰か、どんな変更だったかの説明なんかが書かれている。これを読めばどんな変更が入ったか、雰囲気がわかる。具体的な変更点(diff)は入ったり入らなかったりする。私はdiffも入れることを強くオススメする。diffもあるとどのようにコードが変更されたかまですぐに確認できる。

まずはあなたが読む

diff入りのコミットメールは仲間みんなに届くようにしよう。diffを読んで、リーダブルじゃないコードがあったら教えてあげよう。diffだけ読んでもリーダブルなコードにしないといけないんだ。

まずはあなたがdiffを読んで仲間にフィードバックしよう。「こうすればもっとリーダブルになるんじゃないかな?」それを続けていれば仲間もあなたのdiffを読んでくれるようになるはずだ。あなたがコミットするときはリーダブルなdiffになるようにコミットしよう。仲間のdiffを読んでいたあなたはどういうdiffがリーダブルかはわかっているはずだ。

わかりやすい目安はこうだ。1つのdiffに1つのことを。もし、あなたが本書中のコードをリーダブルにする方法でコードを変更したときは、1つの方法ごとにコミットすること。「2.1 明確な単語を選ぶ」と「4.4 縦の線をまっすぐにする」を一緒にコミットしてはいけない。「2.1 明確な単語を選ぶ」で1回、「4.4 縦の線をまっすぐにする」でもう1回コミットするんだ。そう、「11章 一度に1つのことを」だ。

添削コミット

他の人がリーダブルじゃないコードをコミットしたら、「こうすればもっとリーダブルになるんじゃないか」というコードをコミットしよう。そして、「今コミットしたように変更するともっとリーダブルになると思うんだけどどうかな?」と声をかけてみよう。 添削コミットではリーダブルコードにするための「具体的な書き方」がコミットの内容そのものになる。コミットメッセージにはどうしてこの書き方の方がリーダブルなのかの「理由」を書く。

おさらい

自然にリーダブルコードを書けるようになるための最後のステップは、コードで伝えるというだ。最後のステップではあなたがリーダブルコードを伝えられるようになることを重視する。あなたの意図をコードで伝えられるなら、それは本当にリーダブルコードになっているということだ。

最後に

解説として、本書の内容を身につけて自然にリーダブルコードを書けるようになるための3つのステップを紹介した。3つめのステップまでいけば「リーダブルコードを書かないなんてありえない!」となる。そうなったら著者が本書の最初で書いていたようなことが現実になる。

君はきっと優秀なプログラマになれるはずだ。
自分の仕事に誇りを持ち、周囲のみんなが喜んで使ってくれるような、バグの少ないコードを作り出せるようになる。

私はリーダブルじゃないコードを書く人とは一緒にコードを書きたくない。私がリーダブルじゃないコードを触るときは、まず、見た目を直してリーダブルにする。そう、本書の「第I部 表面上の改善」に相当することだ。本書を読んで「わかってるな!」と思ったところは、まず「第I部 表面上の改善」を持ってきているところだった。

あなたも本書の内容を活用して、リーダブルコードを書くプログラマとなってくれることを期待している。

リーダブルコードを書いて、自分が書いたコードを忘れてしまっても問題ないようにして欲しい。リーダブルコードを書こう。忘れてもいいコードを書こう。

「自分が書いたコードってどのくらい覚えているんですか?」

「ほとんど覚えていないですよ。」

「直すときどうするんですか?わからなくなってるじゃないですか。」

「忘れても見たら簡単にわかるように書いておくんですよ。」