名前がないものは見えない――名前重要：問題解決力を高めるコツはプログラミングの原則・思考にあり（6）（3/3 ページ）

本連載では、さまざまなプログラミングの原則・思考の中から、特に問題解決力を高めるのに役立つものをピックアップ。プログラマーは、その思考法をビジネスに応用し、そうではない人はプログラマーと一緒に働く際に思い出してほしい。「ジョシュアツリーの法則」「バベルの塔」に見るように、名前や共通言語は重要だ。今回はプログラミングにおける「メンタルマッピング回避」「ループバックチェック」などから「命名」の重要性を確認しよう。

[上田勲，著]

コードの臭い

　英語　　Bad smell in code.

　What　〜コードの凶兆を見逃すな

　「コードの臭い」とは、コードの中で、理解しにくい、修正しにくい、拡張しにくい、と感じられる部分のことです。このコードの問題点の嫌疑を、不吉な兆候として、怪しいサインとして、「臭い」と呼びます。

　プログラマは、その「臭い」を嗅ぎ分け、適切なコードに改善していかなければなりません。

　Why　〜嗅覚はリファクタリングの必要条件

　コードを改善するためには、「リファクタリング」が必要です。

　「リファクタリング」とは、外部から見たコードの振る舞いを変えずに、コード内部の構造を改善する技法です。「コードの体質改善」と呼ばれることもあります。

　きれいなコードは読むのが楽で、修正するのが楽で、デバッグするのが楽です。これに対して、汚いコードはすべてが大変です。汚いコードが手元にある時は、新たな障害を出さずに、きれいなコードに書き換える必要があります。この行為、および技術がリファクタリングです。

　コードは生きています。ソフトウェアは1度作ってそれでおしまいではなく、障害を修正したり、機能を追加したり、あるいはソフトウェアを構成しているモジュールを他のソフトウェアで再利用したりします。成り行きまかせに修正したり、目先のことだけを考えて機能を追加したりすると、コードは次第に汚れていきます。そして、読むのも、修正するのも、デバッグするのも難しくなります。それはちょうど、健康管理をしていない人の体調が次第に悪くなっていくのに似ています。

　体質は、無駄なようでも、時間をかけて健康管理し、食事や運動に気を遣うことで、改善されます。それと同じように、コードも、無駄なようでも、リファクタリングを継続的に行っていれば、容易な修正、確実な機能追加が可能な体質に改善されるのです。

　ただ、リファクタリングして既存コードを改善するためには、どのコードを改善すればよいかを判断できなければなりません。リファクタリングのカタログから、ある程度その知見は得られます。しかし、カタログに書かれている状況と、自分が直面する状況は、たいてい異なります。

　そのため、設計上のよくある問題についての知識を身に付け、自分のコードにそれが現れた時に、察知できるようになっている必要があります。この設計上の問題点を、「臭い」として感じ取り、嗅ぎ分ける必要があるのです。

　How　〜臭いの傾向を知る

　「コードの臭い」の兆候を把握しておきましょう。

　コードの臭いには、以下のようないくつかの傾向があります。それぞれについて、「どういう状態が悪臭か」を把握するのはもちろん、「なぜこれが悪臭なのか」をきちんと把握しておきましょう。

• よく見る

　そっくりなコードがそこかしこに散らばっている状態です。コードをコピー・ペーストして作ってしまうと、重複コードがたくさん存在することになります。
　重複しているコードは、修正しにくくなります。見つかった障害を修正する際、たくさんの箇所を修正しなければならないからです。

　重複コードは、1つの関数にまとめるようにしましょう。

• 長すぎる

　関数が長すぎて、スクロールを何回繰り返しても終わらない状態です。
　関数が長すぎると、理解するのが難しくなります。「このメソッドでやっていることはAである」とひとことで言えません。「このメソッドではXとYとZと……」のように説明まで長くなってしまいます。

　長すぎたら、分割して短くしましょう。

• 大きすぎる

　モジュールが大きすぎて、管理不能な状態です。

　モジュールが大きすぎるということは、そのモジュールが担っている責務が大きすぎるということです。モジュールが大きすぎると、理解するのが難しくなります。また、責務が大きいので、修正の機会も多く、時間が経つにつれ、より大きく、より管理不能になっていきます。

　大きすぎたら、分解して小さくしましょう。

• 多すぎる

　モジュールが多すぎて、管理不能な状態です。

　モジュールが大きいからと言って、分解しすぎてはいけません。分解しすぎると、今度はモジュールが増えすぎてしまい、逆に管理不能な状態になってしまうからです。

　いくら責任を小さくするのがよいと言っても、物事には限度があります。大きなモジュールは理解しにくいものですが、モジュールの数が多すぎるのも、やはり理解を妨げます。関連が増えるため、コードの流れが読みにくくなるからです。

　多すぎたら、あまり仕事をしていない仲介役を削除したり、統廃合して数を減らしましょう。

• 名前が合わない

　名前と、実際のコードが合っていない状態です。

　名前は重要です。コードの中にはたくさんの名前が登場します。それらの名前はコードの読み手に適切な情報を伝える役目があります。コードを書く時に、プログラマは適切な名前を付けるように注意を払わなくてはなりません。

　しかも、名前は1回付けて終わりではありません。コードは生きています。修正を加えていくうちに、はじめは正しかった名前が、不適切になる場合が非常に多くあります。

　表現したい概念と名前が合っていないコードを発見したら、ただちに適切な名前に変更しましょう。

出典書籍

『Java言語で学ぶリファクタリング入門』結城浩, ソフトバンククリエイティブ（2007）

関連書籍

『新装版リファクタリングー既存のコードを安全に改善する』Martin Fowler , オーム社（2014）

『パターン指向リファクタリング入門〜ソフトウェア設計を改善する27の作法』ジョシュア・ケリーエブスキー, 日経BP社（2005）

『Clean Code アジャイルソフトウェア達人の技』Robert C. Martin , アスキー・メディアワークス（2009）

書籍紹介

プリンシプル オブ プログラミング 3年目までに身につけたい 一生役立つ101の原理原則

上田勲著
秀和システム　2,200円

一通りプログラミングができるようになった。しかし、読みにくい、遅い、頻繁にエラーが発生する、書いたコードを修正すると動かなくなる等々、なかなか「よいコード」を書けないとお悩みではありませんか？ 本書は、よいコードを書く上で指針となる前提・原則・思想、つまり「プリンシプル」を解説するプログラミングスキル改善書です。初心者向けの書籍では絶対に説明しない、古今東西のプログラマーの知恵をこの一冊に凝縮しました！