中途半端に優秀なプログラマが「迷信」だと思いこみがちな３つの「正しいプログラミングテクニック」

プログラムは人間の思いとは裏腹に、ただただ冷徹に書かれたコードの通りに動く。

その淡々たる様に反して、プログラミングというのはあまりに曖昧で、プログラミングテクニックと呼ばれるものは皆、ごくごく微妙な且つ大量の前提条件のパラメータによって、適用の可否が分かれる。

以下の３つの事項は、90%以上の前提条件のもとで、正しいのだが、ごく稀にそれを適用しない方が良いという例外事項がある。

そう、例外事項がある。

ただし、それはあくまで例外事項であって、そのプログラミングテクニックが迷信なわけではない。プログラミングテクニックの例外を理解し始めた時には、例外的なシチュエーションばかり考えてしまうことがあるが、それはプログラミングを学ぶ上での通過儀礼と言えよう。

「変数のスコープは狭いほど良い」

まず間違いなく狭い方が良い。

大量のゴミ変数がスコープ内にある状態ではインテリセンスは全く役に立たなくなる。変数スコープを狭くしておくことは、メソッドを抽出して構造化を行うというリファクタリングの第一歩だ。

処理フローをそこそこ書けるようになったら、データ構造について学ぶべきだ。データ構造の設計が拙いと、オブジェクトにデータを隠ぺいするよりもグローバル変数的にした方がマシと思えることすらある。それは、正解ではなく、その拙い設計はグローバル変数以下だと言うことに過ぎない。

かといって、グローバル変数は一切不要なのかというとそうでもない。グローバルなスコープで用いられる状態というのは少なからず必要になる。gotoが排除されforとbreakになったり、try・catch・finallyになって例外という概念でコントロールされたように、グローバル変数はGoFデザインパターンのsingletonパターンなどによってオブジェクトにラップされる。

オブジェクトにラップしたところで、グローバルであることに変わりはない。singletonなどはグローバル変数を去勢するものであって、原則としては多用してはいけない。スコープは極力狭くすることが原則だ。

しかし、実際にグローバルな状況下で唯一のリソースといったものが存在するわけで、そのようなリソースやデータは本質の通りグローバルであればよい。ただし去勢を施して、だ。

原則としてスコープは狭くする。ただし例外もある。その例外を正しく判断して、「これは例外だ」と言えるようになると設計はよりよくなる。

「同じロジックのコードを2度以上書くな」

コピペによって作られた重複コードはコードクローンと呼ばれる。コードクローンは存在してはならない。
コピペで作ったわけではないが似たような処理のコードというのも原則として存在してはならない。
構造化を施し、オブジェクト指向やジェネリクスを駆使し、これを排除する。

半端なプログラマは、構造化が拙い。「この部分の処理を共通化するためにメソッドにしました」と彼らは言う。しかし、ではそのメソッドに名前をつけよというと困惑する。

「コードを単一にする」という目的ばかりに目が行って、構造化する際の区切りが別の領域を犯しているのである。うまく構造化されたメソッドは「こういう目的のメソッド」という目的感がはっきりしている。目的がはっきりしているので名付けに困ることがない。

ただし、この原則にも例外はある。

コードクローンのデメリットが顔を出さない部分においては、敢えて割り切ってコピペから作業をすることもある。使い捨てのコードならば、保守性を考えて手間をかけることがむしろ無駄ということもある。コードクローンは保守性を下げるが、保守が不要と言う条件下ではあまり目くじらを立てる必要がない。

なぜフェンスが建ててあるのかを理解しないうちはフェンスを倒してはならない。

同じロジックが複数回現れることのデメリットをよく理解して、デメリットが顔を出さないようなシチュエーションであるならば、そのときは踏み込んでも良い。

「まずは一つのプログラミング言語を極めるのが大切」

上に挙げてきたようなことは、何か一つの言語でプログラミングを極めていれば理解していることだろう。なぜなら、こうしたことは言語を問わず、プログラミング全般に共通する本質的なテクニックであるからだ。

そうした事象を理解するには、少なくともまず単一の言語でもよいから自在にコードを書けるところまで辿りつかなくてはならない。

物事を理解するには、その前提となるステップを理解しておく必要がある。まずはどんな言語でもよいからひとつを極める。それによって開ける道がある。

プログラミングとはどういうものかを理解したら、あとは作ろうとするモノに必要な知識を、必要になった時点で広げていけばよい。それはプロトコルへの理解であったり、パフォーマンスチューニングであったり、セキュリティであったりするかもしれない。

だが、こうした技能はプログラミング能力があって初めて解することができる。まずは土台となるプログラミング技能を身につけることが大事だ。

まとめ

本稿は中途半端に優秀なプログラマが「正しいプログラミングテクニック」だと妄信しがちな３つポイント - 分裂勘違い君劇場 by ふろむだを揶揄したものだが、読めば分かるように、本質的には賛同するものである。

唯一、それは違う、と主張するのは「迷信」の部分である。例外のある原則を、例外をあげつらって迷信だ、というのは頂けない。

単に原則はこうだが、例外もある、禁止される理由を正しく理解して、敢えて踏み外すべき時があれば自分の責任で踏み外せばよい、ということのほうが真実に近い。
「迷信」というのを真に受け、曲解し、構造化なんていらないんだとか言い出す奴が出ないためにも、原則禁止であり例外もある、という位置づけのほうがよい。