ガンズターン 公式サイト

楽しいことに、まじめです。 ——ガンズターンアプリ研究所公式サイト

「リーダブルコード」を読み終えて

Pocket

新規アプリのチュートリアル機能実装完了

新規アプリのチュートリアル機能の実装をやっとこさ終えました。

どうも。ガンズターンのRyosukeです。

一口にチュートリアル機能といっても、背景は通常のゲーム画面とまったく同じなのにその挙動がまったく異なるなど、初めて実装するにはそれなりにハマりポイントが多かったです。

まあ、思わぬ副産物が色々と得られて、今後の開発のスピードアップにつながりそうなのはよかったです。

具体的に書くと、画面上のオブジェクトに対して、ユーザーの注意を向けるための色んな方法を簡単に実装できるようになりました。

例えば任意のスプライトを白く囲って点滅させたり、吹き出しを出してユーザの操作を促したり……。

新たに開放された機能への導線を強調表示したりすることも簡単にできるようになったので、今後どんどん活用していきたいです。

キャラデザとBGM、および効果音の作成も終わりまして、残すところは見栄えの調整とデバッグ。
ぐぅ……。かなりめんどくさい部分ですが、6月中にはなんとかアプリ申請したいのでがむばります!

閑話休題。

今日は最近読んだ技術系の書籍の話題でも。
「リーダブルコード」というかなり有名な本なのですが、ご存知でしょうか?

「リーダブルコード」表紙

「もっと綺麗にコードを書きたいけど、具体的にどこをどう手直ししたらよいかわからない!」
という、自分とまるっきり同じお悩みをお持ちのあなた。
もしまだ「リーダブルコード」をお読みでなかったなら、ぜひ手にとって読んでみることをオススメします。

以下に、わたしが本書を読んだ感想を簡単にまとめますので、買おうかどうか悩んでいる方のご参考に少しでもなれば幸いです。

1. わたしが「リーダブルコード」を手にとった理由

これまでこのブログを少しでも読まれた方であれば、わたしが「プロのプログラマ」ではないことはご承知のことかと思います。

当然、プログラミングに関する知識・技術は、数々の「入門用」テキストから得たものしかないわけで。
何かコードを書くたびに「このコード、もっと見やすくならんかなぁ……」と腑に落ちない気分を味わうのですが、圧倒的に経験が浅いため修正方法が思いつかず。
最終的には「どうせ自分しか読まないコードだからこのままでいいか」で済ませてしまう毎日……。

(このままじゃいかん……)

独立起業を機に、わたしはそのことを改める決心をしました。

じゃあ、どうするか?

かんたんな話です。「きれいなコード」を書けるようになればいいだけ。
しかし実のところ、これがいちばん大変で……。

わたしの場合はそもそも「どういうコードがきれい」で「どういうコードが汚い」のかという明確な基準が自分の中にないもので。

「なんとなく汚い」とか「なんとなくきれい(読みやすい)」という感想はあっても、そこから先どうするかについては皆目見当もつかないという状況でした。

そういう「判断基準」というか「コードをきれいにするための具体的な方法」がまとめられた書籍はどこかにないものか、と近所の本屋に出かけたら、青い表紙のこのお方に出会ったというわけです。

実は、会社員時代に同僚だった「プロのプログラマ」の人から「読んだ方がいい」とオススメだけはされていました。

パラパラと試し読みしてみたら、コードの具体例も豊富のようでしたし、何より本が薄いのが読みやすそうで、悩むことはありませんでした。

結果、今では買ってよかったと心底思っています。
もちろん、読んだだけで自分の書くコードがきれいになるわけではありませんが、少なくとも今後どういう方向に努力していけば「きれいなコード」を書けるようになるかという指標を得られただけでも精神的に楽になりました。

ためになる具体例の多い本書ですが、以下からは、わたしがとくに「これはすぐに使える」と思った例をご紹介します。
(本の内容を転記するつもりはないので、あくまで紹介だけにします。実際のところはご自身で本を読んでみてください)

2. 名前が重要だという話

これ、きっと「プロのプログラマ」の方々からすると「当たり前」以前の話かと思うのですが、改めて懇切丁寧にその理由が説明されているのを読んで、心底「これからはきちんと名前つけよう」と思えるようになりました。

例えば変数の名前。

わたし、けっこう頻繁に「一時変数」を使っちゃう癖があって、「tmp」とか「num」とか「str」とかが気づくと1つのコードの中に散乱している状況になっていることがあります。(下手すると「tmp2」とかも……笑)
自分でも半年後とかに読み返してみると、「あれ? なんでこんなとこで変数に代入してるんだっけ?」とわからなくなることもしばしば……。

しかしこういった「一見無意味な一時変数」がコードを読みづらくしている一因であることは、実は本書を読むまで考えになかったわたしでした。

けれど、こういった「一時変数」について、本書では「ぜったいに使うな!」と言っているわけではないのです。
「一時変数には一時変数なりの使うべきタイミングがある」ということを、本書は教えてくれました。

例えば「変数1と変数2の値を交換」する時などに、値を一時的に保持しておく変数などです。

また、「変数の名前をきちんと考えてつけると、無意味なコメントも減らせる」という考え方は、わたしにとっては天啓でした。
(というと、ちょっと大げさすぎますかね。 ^^; )

ただコードを書いているだけの立場だと「どうせ名前なんて何にしたって挙動は変わらないんだから関係無い」と思ってしまいがちですが、長い目で見て、保守性を高めるためには必須の考え方ですよね。
なぁんてことが具体的に分かっただけでも大きな収穫でした。

3. 「関数から早く返す」に目からウロコ

わたし、会社員時代に、新入社員研修でちょこっとだけプログラミングについて学んだのですが、その時に講師の方からは、
「関数からの出口は複数作るな!」
的なアドバイスを受けて、実のところ最近まで愚直にそれに従ってました。

例えば、ある変数が「偶数なら3で割ったあまり、奇数なら4で割ったあまり」を返すかんたんな関数(そんなのいつ使うんだというツッコミは考えないでください。苦笑)があるとして、このアドバイス通りに実装するとしたら以下のようになります。

int calcRest (int num) {
    int ret;
    if(num%2==0){
        ret = num%3;
    }else{
        ret = num%4;
    }
    return ret;
}

なんて冗長な書き方でしょう。
しかし関数からの出口(return)を一つしか使っちゃいけないというルールに厳密に従うとこう書かざるを得ません。

……まったく、バカだったと思います。

もちろんアドバイスをくださった「講師の方」に対してではなく、自分の頭で考えることなく何年もそのアドバイスをただ「鵜呑み」にしていた自分に対して、バカだと思うということです。

「なんで複数出口を作っちゃいけないんだろ?」
と、心底考えていたら、もっと早いうちに自力でこのことに気づけたんだと思います。

このアドバイスを一時忘れて、可能な限り早く関数から返すことを考えると上記関数は以下のようにかけます。

int calcRest (int num) {
    if(num%2 == 0) return num%3;
    return num%4;
}

……はい。たったの2行。実に3分の1になりました。(文字数換算だとさらに……?)
今回はこんなに単純な関数だから3分の1(それでも!笑)ですが、これがもっと複雑な関数になるとそこから得られる恩恵はさらに増えると思っていいですね。

こんな素晴らしいことにどうして自力で気づけなかったのか、今ではそちらのほうが不思議です。

4. 他にもたくさん読みどころ満載

ここまで紹介してきた事柄すべて、「プロ」の方からしてみると「当たり前」以前の話かもしれないのですが、たぶん「当たり前」過ぎて具体的に(直球で)アドバイスしてくれる人は少ないと思うんですよね。(とくに日本の場合は)

ほんとうに良書に巡り会えたと思っています。
もっと早く(具体的にはあと5年以上前に)読んでおきたかった……!

すでに「プロ」として活躍されている方にとっては「当たり前」過ぎて物足りない内容かもしれませんが、わたしのように独学でしかプログラミングに触れたことのない人間にとってはとてもよい「気づき」を与えてくれます。

けれど大変なのは、実はこの本を読んでからこの先どうするか、という点。
この本を読んでしまった以上、「そんなきれいなコードは思いつきませんでした」なんていういいわけは通用しなくなるわけですからね……。

「きれいなコード」を書くために必要なヒントが、ほんとうにたくさん、この本には詰まってます。

この記事を読んで、ほんのすこしでも「きれいなコード」に興味がわいたそこのあなた。
ぜひ、軽い気持ちで読んでみたらいかがでしょうか。

サイズも厚さも手頃なので、通勤途中でも難なく読めちゃうと思いますよ。

Pocket

コメントを残す

メールアドレスが公開されることはありません。 * が付いている欄は必須項目です

トラックバックURL: http://gunsturn.com/2015/06/17/readable_code_impression/trackback/