関連文: プログラミングでメシが食えるか！？

プログラムの本来の姿とはどういったものか、そういったことを考える機会が多かった自分にとって、ふと本屋さんでこの本を目にしたとき、とても興味深く映りました。

ソフトウェア専門の開発現場で仕事をしたことは、現時点ではありませんが、よく耳にする 「人月」 という工数だとか 「ステップ」 という行数単位での開発スタイルが、自分のプログラミングスタイルと照らし合わせてみた時に、どうにも疑問に感じてならなかったんですよね。

 

この本にも記載されている 「プログラムの開発能力は、優秀な人とそうでない人とで 27 倍の開きがあるという」 という言葉がありました。

その言葉が示すように、実際に、自分だったら数日あれば設計から実装まで十分できるような仕事を、プログラム開発を経験してきた人が 1 か月かけても実装ができない、場合によってはプログラムはかけても設計ができないという人も居たりして。

昔から、同じ機能を作るにしても、時間のかかる人ほど高くなるという時間基準での評価に疑問を感じていただけに、この本に記されている内容は、とても共感のできるものでした。

 

それに、時間がかかる人のソースコードというのは、どうにも無駄に長くなってしまっていて、本人さえも把握できていないコードになっているように思うんですよね。自分で自分の首を絞めて工数が伸び、そのツケを依頼した側が払う。そしてそのコードの中には、単純なコードにさえも難解なバグも多く含まれていて。

この本でも 「構造化プログラミング」 という言葉が頻繁に顔を出しますが、構造化プログラミングができれば、自然とソースコードも短くなりますし、把握できる範囲にプログラミングが収まる分、単純なコードの中にバグが含まれる可能性はかなり少ないように思います。

 

さらに標準関数の整備やオブジェクト指向の発達により、第三者が作成したプログラムを活用することで、たった数行のコードで複雑なことをこなすことができるようになりました。これにより、同じ処理を作るにも、はるかに少ない行数で、より安全なプログラムを記述することができるようになっています。

オブジェクト指向については、この本では使いどころによるだろうというように記されていますが、個人的には、プログラムの制御をより確実に行うためにも、オブジェクト指向は必須と思えるくらい、注目しているところです。

この本では、オブジェクト指向の欠点として、無駄が増えたり、速度が犠牲になる可能性が示唆されていますけど、そこまで気にする必要のある場面というのは、そうそう無いように思うんですよね。ここが、著者との分野の違いなのかもしれないですけど、一般的な Windows アプリケーションであれば、それに見合うだけの品質は得られるだろうと思います。

 

他にも、この本の中では、仕様書は開発を行う上で必要かといったことにも触れられています。

個人的にもここは疑問を感じたことのある部分で、仕様書を先に作るよりも臨機応変に対応した方が、最終的にはずっと良いものができるのではないかと思っては、それを口にすれば猛反論といったことも幾度かありました。

開発規模にも依るとは思いますけど、今時の 「パーソナルコンピュータ」 を対象とした開発なら、仕様書は最後に、ソースコードだけでは捉えにくい、全体の大きな流れを記すのが、良いのではないかと思います。個人で開発するならなおさらですし、分担するにしても、2, 3 人規模ならそれで十分、大きなプログラムを開発できると思います。優秀な人材を 2, 3 人集めることが、大きな壁とも言えますけれど。

 

また、どれくらい過去の知識を蓄積できるか、専門分野を持てるかといった話もありましたけど、これはなかなか真似できるものではないなと感じました。著者はネットワークプログラムに関して、長年の経験とその分野を見通せる目を持っていて、そこへ到達するまでの時間は、相当なものであることが窺い知れます。

自分はそこまでの知識は持ち合わせていないですけど、他の人より早く開発出来ていたのはなぜだろうと考えたとき、次のようなことを感じました。

ひとつは、単純に運が良かったというところ。ネットワーク構築や HTML 作成、データベース構築などの知識があって、それがたまたま選択肢として選ぶことができたのは大きいことのように思います。検索するならデータベースを使えばいい、通信を暗号化するなら SSL など、幅広い引出があったことが開発速度につながったのでしょう。

いずれにしても、さまざまな機能を利用できるようになった昨今、広い引出を持つということが、開発速度と品質に多大な影響を及ぼすことは間違いないのだろうと思います。

まあ、この辺りこそが、著者の言う 「専門分野」 ということなのかもしれないですね。再利用可能な手段を如何に蓄えるか、その視点から見れば、もしかすると同じ事なのかもしれないです。

 

また、構造化にあやかって、一つの役割を担うソースコードを基本的に 1 画面に収める組み方も、開発速度の向上に繋がるものだと思います。

自分があまり頭が良くなかったのも幸いしてか、ソースコードが 2 画面とかになると、とたんに把握できなくなるんですよね。だから、関数に分割して整えて配置する。それによって、自分のプログラムを制御できなくなるようなこともなくなるし、バグを含みにくい、効率の良いソースコードになるのだろうと思います。

 

 

いずれにしても、この 「プログラミングでメシが食えるか！？」 という本は、そんな、古くからある開発手法や常識について、大胆に異論を唱えているところが面白いところでした。

プログラミングの速度に 27 倍の開きがあるというテーマの中で、その理由などをさまざまな角度から語る感じで、そこからさまざまなことを考えさせられる一冊です。多くの部分で自分の経験と照らし合わせて納得できる内容でした。

既存のプログラミングの在り方に疑問を抱いている方には、特にお勧めの一冊です。