業務の現場で求められる「美しいソースコード」とは？

何やら巷では、こんなことが話題になっているらしい。

★同じ動作をするプログラムでも、ソースコードの書き方は人それぞれで変わってきます。わかりやすく「美しい」ソースコードは業務の現場では、あまり求められません。動けばＯＫと気楽に♪

そもそもプログラマーとは「ソロアーティスト」か「オーケストラの演奏者」か。

「ソロアーティスト」的プログラマー

プログラミングという仕事は、職人や芸術家、ソロアーティストのように、その独自の発想性・創造性を発揮し、その人間にしか作れないものを生み出す仕事である、という側面がある。

ナーシャ・ジベリというプログラマが居た。もっとも有名なのは、ファミコン版ファイナルファンタジーにおいて、飛空艇の４倍高速移動を実現させたことであろう。

金子勇というプログラマがいた。Peer to Peer技術を利用したファイル共有ソフト Winnyを実現した。

天才というにふさわしいプログラマは存在する。そして天才は、天才にしかなすことのできない仕事をしてきた。その仕事は確かに「美しい」ともいえるだろう。

「オーケストラの演奏者」的プログラマー

プログラミングという仕事は、オーケストラの演奏者のように、与えられた仕事を確実にこなすこと、そして、その仕事を確実に次に引き継ぐ仕事である、という側面もある。

無論、一人ひとりに高い能力が求められることはある。だがそれ以上に、周囲から協力を引き出し、また、周囲へ協力をすることで、個々人の能力の総和以上の成果を、組織として引き出す仕事でもある。その仕事は確かに「美しい」ともいえるだろう。

相反する「美しさ」

これらの美しさは（完全にとは言わないが）相反する「美しさ」である。

その人間にしかできない仕事をしてしまえば、他の人間がその内容を理解する事もできず、保守もできず、そして問題が起きれば一人の人間に依存せざるを得ない。そしてその人間以上の才能を持った人間が出てこない限りは、それ以上の成果を見込むことができなくなる、

一方で、組織で仕事をしようとするならば、そのために無駄が生じる事もリスクになる。誰にでもわかるようにドキュメントを用意し、ソースコードをきれいに書き直し、あるいは、変数名をわかりやすくする。そうした努力は、直接的な成果とは違い部分であり、時として「そこまでは求めていないよ」となる。

じゃあ、どういう教育をすればいいのか？

1) 失敗しても、何も壊れない。
2) 要求を満たさねば意味がない。
3) 他人に対して説明できる
4) 優れているという観点は多数ある。

失敗しても、何も壊れない

まず、プログラミングは 成功パターンを見つけるために、失敗を何度でも繰り返すもの ということを教育に入れなければならない。

例えばプログラミングの試験を考えてみよう。プログラミングに関する知識については確かにペーパーテストでよいだろう。しかし、実技に関して言えばペーパーテストなど意味がない。 トライアルアンドエラーで、納得できる結果を残せ ばよいのだ。そのためには、プログラミングは コンピュータ内で行われる実験であり、何度失敗しても基本的にはそのままもう一度チャレンジできる ということを教えなければならない。

要求を満たさねば、意味がない

そのうえで、ソースコードに求められるのは、要求をしっかりと満たさねば、価値がない事である。

1~10までの総和を表示するプログラムを作りなさい

に対して、

int i,sum;
for(i=1,sum=0;i<=10;i++){sum+=i;}
printf("%d",sum);

とまじめにループで書いても、

printf("%d", ( 1 + 10 ) * 10 / 2 );

と公式を使っても、

puts("55");

で即値で回答しても、全部要求を満たしている。

求められている要求を満たしているならば、それは正解である。要求を満たしていないものは価値がない ということを学ばせるべきである。

他人に対して、説明ができる

「業務としてのプログラミング」では、他人に対してソースコードの内容を説明できなければならない。

その日１日で終わる仕事だったら、引継ぎなんかもいらない。しかし、１日で終わらない仕事ならば、次の日に別の人がその業務を引き継げなければ、誰もそれをフォローできなくなってしまう。

プログラミングにおいては他人とソースコードを共有する事が非常に勉強になる。ある結果を生み出すための過程は多様であり、その中で自分が思いつかなかったものがあれば、それをどんどん吸収するべきなのである。

自分しか保守できないソースコードは、機能性がどんなに優れていても、将来的にゴミにしかならない ということを学ばせるべきである。

優れている、という観点は複数ある

そのうえで、プログラミング教育で学ぶべき点は優れている、という価値は複数あり、すべての価値を全うできる答えはごく少数。何を求めているのかに応じて、同じものが無価値になったり、最高になったりする事であろう。

例えば、速度を優先するならば、精度を無視したり、扱える範囲を限定的にしてもよい 場合もある。また、誰にでも読めるようにするために、 非効率でも丁寧に記載することが望ましい こともある。

例えば、図工などであれば、１人の人間がものを作る機材や時間は限られているので、１つの結果しか出せないだろう。そして、１つ作ると、それを改良することは難しい。

だが、プログラミングならばそれができる。１つのソースコードを基に改良し、改善し、いじくりまわすことができる。なんなら、他人のソースコードをもらってきて、自分好みに改良することもできる。　このことがこれまでの教育課程にはなかった話なのだ。

まとめると

本当はこう書くべきだったのではないか。

★同じ動作をするプログラムでも、ソースコードの書き方は人それぞれで変わってきます。業務の現場では、"できる限り一番いいやり方"のソースコードが求められます。でもそれは、たった１回のチャレンジの中で見つけるものではありません。自分のソースコードを直したり、先生や他人のソースコードを見たりして、良いところが何かを学び、そして自分が満足できるソースコードを目指しましょう♪