リーダブルコードを英語で読みました（The Art of Readable Code）
リーダブルコードの原著を英語で読みました。
（↓アフィじゃないです）
会社の制度を利用して経費で読ませてもらったので、せめてものということでアウトプットしたいと思います。
英語でしたが、毎日コツコツ読んで、TOEIC過去最高点795点程度の僕でも３週間で読み切れました。
なんで敢えて原著にしたかというと、まずこの本に限らず、基本的に日本語に翻訳された本の文体があまり好きではないからです。ちなみに、日本語版の方のAmazonレビューを見てみると「日本語が変！」という意見がちらほらありました。
それから英語に慣れたいと思っています。AWSのドキュメントなども日本語の機械翻訳の不自然さに若干ストレスを感じるので、プログラミング道を極めていく中で、英語にはぜひ慣れていきたいところ。
本著を読んだのは、プログラミングを始めてからちょうど1年6ヶ月というタイミング。
未経験転職してから9ヶ月。
仕事の案件に入ってから6ヶ月。
というタイミングでした。
読むタイミングとしては悪くなかったかなと思います。これより早く読んでもあまりピンと来ないことが多そうだし、遅すぎてもこれを読んでいるであろう同僚と価値観がズレる可能性があるかなと。
以下、学んだこと、アクションアイテムを順不同にババっと。
1. １つのプログラムには１つのタスクに専念させる
今の会社（Fusic）に入社して、OJTでアプリを作っていた時に、先輩にこういう質問をした記憶があります。
「どういうタイミングで関数って外に切り出すんですか？」
この答えはリーダブルコードにもありました。原則的には１つのプログラムには１つの処理をさせる。そうでなくてもなるべく細かく切り出していった方がいいです。他にも使えるかもしれないし、テストもしやすくなるし、メンテナンスもしやすくなります。これは本著に限らず、今日パラパラっと見ていた「新しいLinuxの教科書」にも似たようなことが書いてありました。
2. 変数名は説明チックに
「変数名はなるべく短い方がいい！」
僕は可読性を重視してそう考えている節がありましたが、それは単純すぎたかもしれません。他の人が見てすぐわかるように説明を加えるといいというアドバイスは有用でした。
ちょうど自分が携わっている案件で、`image_base64`と先輩が命名した変数を目が止まりました。単なる`image`よりも変数の中にどんなデータが入っているべきかがハッキリしますよね。
3. コメントは積極的に残そう
「プログラマーたるもの他人のコードもコメントなしでスラスラ読めるもの。コメントなんて女子供のすること（←言葉の綾です。女性蔑視の意図はありません）」
僕はそう考えている節がありましたが、M過ぎたのかもしれません。本著でももちろん「コードを読んですぐわかることをコメントすんな！」と釘を刺されていますが、プログラム全体のことなどは積極的にコメントしようと書いてありました。
そういえば、仕事でも僕が出すプルリクエストでつよい先輩から「ここちょっと複雑だからコメント残してください〜」とrequest changesが返ってくることがちょいちょいありました。
4. ハマったらテディーベアに話しかけよう
これを"rubber ducking"というらしいです。うちのオフィスにはちょうどくまモンがいるのですが、今やっとこいつの存在理由がわかりましたw
ハマるとついついその場に固執し、意地になって画面にかじりついてしまいますが、そこから離れて言葉に出してみるということをしていきたい。幸い、僕のチームは困ったら話を聞いてくれる人がたくさんおり、そういう意味では喋る歩くテディーベアに囲まれております。そしてくまモンもいます。
↓筆者とくまモン
5. 混乱したらまず文章で書こう
これは4に通じるものがありますね。既に割と実践していたことではありますが、こういう古典的名著にも書いてあると知って嬉しかったです。
6. 条件分岐では肯定文、シンプル、興味深い方を先に記述しよう
if - else文の順番に関して、今までは「自然な処理になるように順番を決める...」という曖昧な基準だった気がしていますが、コードをリーダブルにするためにこの教訓は有益だと思いました。
否定の条件文だと一瞬考えないといけないし、Rubyのunlessも一瞬「えっと...」ってなりやすいし、ひとつめの条件文が長いとelseはどこだろう...と探してしまいます。
場合によってはこの限りではないと思いますので、あくまで原則として。
7. 100%を目指すな！
この感想文でちょいちょい書いてきたことですが、これに関しても最近の仕事でちょうど思い当たるものがあります。
何か解決しないといけない問題がある時に、僕はつい一番理想の形を提案してしまう癖に最近気づき始めました。駆け出しエンジニアとして、きちんとロジックを固めないと！という気負いがあるのだと思っています。でも、最近それを聞いた先輩から「それはできるけど、費用対効果を考えるとそこまでしなくていい」と窘められることがちょいちょいありました。
まさに自分は100%を目指してしまっていたのだと思います。本著にも、問題解決の90%をこなすのは、残りの10%をこなすよりも短い時間でできることが多いとありました。
最後に
普段の仕事の中で、先輩方から指摘されるようなことが古典的常識でもあるということを再確認できて良き！でした。
いいなと思ったら応援しよう！
