こんにちは、しらたきです。デザイナーをしている友人がJavaScriptを勉強し始めました。コードレビューしていたら、気になるポイントがたくさんあったので、リーダブルコードを薦めてみました。
はじめに
元々、パティシエをしていた友人がWebデザイナーの勉強を始め、ついでにJavaScriptも勉強しておきたいとプログラミングの勉強をはじめました。
コードレビューをしていたのですけど、基本的なノウハウを１つずつ伝えていくのが大変なので、この本をオススメしてみました。
リーダブルコードを薦める背景
私は某電機機器メーカでプロジェクトリーダを務めているのですが、学生時代の専門はコンピュータ工学、新人当時はプログラマを務めていたのでC/C++ガチ勢です。
現在、多くの派遣エンジニアや委託先からコードが上がってくるのをコードレビューする立場にあるのですが、糞コードを連発する技術者がいると、リーダブルコードを薦めています。
オライリージャパン
売り上げランキング: 1,230
リーダブルコードは、コード品質を高めるためにコードの読みやすさに主眼を置いたプログラミングノウハウ本です。動物の絵でお馴染みのオライリーが出版していますが、表紙は動物の絵ではありません。
ここ数年で入社してきた若者が「オライリーって何ですか？」と言ってきて、ジェネレーションギャップを感じる近頃です。最近は、技術書買わない技術者が増えたみたいですね。。。
糞コードを書くエンジニアがなぜ生まれるか
さてさて、私の経験上、読みづらいコードを書く人は２種類居て、
- 経験が少ないためにノウハウを知らない人
- 特殊な環境下に居てコーディングに制限のある中で仕事をしつづけてきた人
に分けられます。
前者は教えればいいだけなので楽なのですが、後者はやっかいです。
組み込み機器の分野では限られたサイズのROMにソフトウェアを搭載しなければならない制約がありますし、古くは変数名が3文字以内でなければコンパイルできない、なんて時代を生きたプログラマが現役で仕事をしていると、その名残で変数の名前を省略しがちになります。
私自身もsprintfを数個書いたら、処理が間に合わないような世界でコードを書いたことがあるので、そういった技術を持った技術者のことは尊敬しているのですが、Visual C++やLL言語(Perl/PHP等々）で変数名を極端に省略するメリットはありません。
例えば、メーカで装置を開発していると、一つのソリューションファイルに、ハードウェアのDSP制御のコードと、Windows表示系のコードが一緒に含まれる場合があります。表示系の担当者が”Display”を”dsp”と表現し、ハードウェア担当者は”DSP”と表現していて、コードを検索する際に「大文字と小文字を区別する」のチェックを入れて、”dsp”を検索していた時には目頭が熱くなりました。
継続的インテグレーションだ継続的デプロイだという世界にいる人からすると冗談のような話ですが、日本のメーカ企業の多くはこんな糞みたいな環境でコーディングをしているのが我が国の現状です（急に話がでかくなった）。
ということで、リソース制約を回避するために身についてしまった悪癖が、それを知らない人から見ると糞コードを連発する糞プログラマに見えてしまうことが多いなと感じています。
エディタをパッと見て美しいかが大事
大量のコードをレビューするので、新規に作られたコードをレビューする時には、コードレビューの前段階でフィルタをかけます。エディタでソースを開いて、パッと見てコード全体が美しくなかったら、部下に見て貰うようにしています。
インデントが深かったり、一関数が一画面に収まらないようなコードは大概、糞コードを含んでいます。なので、個別のレビューをする前に、感覚的に糞コードが含まれているかどうかを見るには、「美しいか」という観点は案外使える観点です。
前プロジェクトに巻き込まれないために
ビジネスでソフトウェア開発に関わると、一つのプロジェクトに居続けることは難しく、色々なプロジェクトを渡り歩くことになります。しかし、同じ企業に居続ける限りは、前のプロジェクトでの負債に怯えることになります。不具合が発生すれば、前のプロジェクトの担当者から「これってどう設計してあるの？」と質問が来る場合があります。
「俺はプロジェクトから抜けてるんだから、設計書とコード見ろよ、糞が」（意訳）と伝えますが、コードが読みづらいと「分からないから教えて」と追撃が来ることがチラホラ（若い頃はよくありました）。
コーディングの効率としては、三項演算子を使った方が早いものでも、if elseで書き、条件処理のコードが一行であっても{}を書くようにしています。だって、引き継いだ担当者のレベルが低かったら、こんなことでも質問が来るのですもの。
自己防衛のため、プログラミングを覚えたての新人でも分かるよう、できるだけ読みやすいコードを目指しています。
おわりに
とはいえデザインパターンとか使っているものでも読みづらいと言われると、えー・・・って気持ちもありつつ、でもできるだけ読みやすいコードを書くことは大事です。
技術書にしては安く、読みやすい文体なので、ソフトウェアを噛じっている方は読んでみるといいかもです。