最低限の道具でどこまでできるか

客先で、ちょっとしたプログラムを作らなければならないことがある。そういうときに困るのが、開発環境が貧弱なことだ。例えば、メモ帳とインタープリタしかないような状態を考えて欲しい。

最低限の道具は揃っているので、開発できないわけではない。困るのは、実装に必要なクラス名やメソッド名、あるいは引数の渡し方などが思い出せない時だ。

特に珍しいクラスだとか、難しい名前の関数を使いたいというわけでもない。例えば、あるクラスの「データ数」を取得するメソッドは、「Size」だったか、「Length」だったか、それとも「GetLength」だったか？　そんなレベルの話だ。

実現方法は分かっているのに、すらすらと書けないというのはもどかしい。ちょうど、人の顔は浮かぶのに名前が浮かばないというときの感覚に似ているだろうか。

★

年齢のせいかと思ったりもするが、昔からそんなものだったような気もする。そもそも、私は子供の頃から記憶力がよい方ではないのだ。

普段の開発環境なら、キーを１つ押せば「ヘルプ」が表示される。メソッド名などは、エディタが自動的に選択肢を出して教えてくれる。PC は Web に繋がっているし、机上には技術書が置いてある。参考になるソースコードも沢山ころがっている。記憶力の悪い私がプログラマとしてなんとかやって来れたのは、こうした環境のおかげである。

★

今のプログラム言語には、大規模なライブラリやフレームワークが標準で付属している。その全てのクラスや関数を覚えることは不可能だろう。このような状況で、プログラマがリッチな開発環境に依存するのは、仕方がないことかもしれない。

しかし、心に止めておきたいのは、頭脳労働と思われているプログラマの仕事も、バランスよく頭を使っているわけではないということだ。思考力は使っても、記憶力はそれほど使わないのかもしれない。

テキストエディタだけでどこまでのプログラムが書けるか？　腕試しのつもりで、やってみるのも面白いかもしれない。

応援のクリックお願いします →

Javaトレーニングブック

posted with amazlet on 06.07.02

掌田津耶乃
ソーテック社 (2003/12)
売り上げランキング: 399,753

おすすめ度の平均:

わかりやすい

Amazon.co.jp で詳細を見る

脳力トレーナー

posted with amazlet on 06.07.02

インターチャネル (2005/02/04)
売り上げランキング: 49

おすすめ度の平均:

○か×か

マジで面白い！

コマメなバージョンアップで使えるソフトに変身♪

Amazon.co.jp で詳細を見る

プログラムは二度書け

私がこのブログに記事を書くときには、まず内容を考えてから書き始める。しかし、書いているうちに、内容が最初に考えていたものと徐々に変わっていくようなことがある。「書く」ということで、意見や主張が頭の中で整理され、考えもしなかった結論に至ることもある。

「書く」ということは、「何かを伝えるための行為」であるだけではなく、「何かを知るための行為」でもあるのかもしれない。

結城浩氏や平鍋健児氏は、ソフトウェア開発でも同様のニ面性が見られることを指摘している（※）。もちろん、どんなソフトを作るかという大枠（企画、要件）は、最初に決める。しかし、具体的にどのように作るかということ（設計）は、実際にプログラムを書きながら見つけていく方が現実的（効率的かつ低リスク）であることが多い。

★

しかし、本来、誰かに何かを伝えようとすることと、自分が何かを知ろうとすることは全く違う。そういう意味では、この２つの「書く」という行為は、明確に区別して理解すべきかもしれない。

例えば、数学の試験問題を解くことを考えれば分かりやすい。答えを導くために紙の上で行う「筆算」は、まさに「知るために書く」という行為である。しかし、最終的に解答用紙に残すべきなのは、「筆算の跡」ではなく、綺麗にまとめられた「数式」だ。つまり、別途「伝えるために書く」という行為が必要なのである。

暗算が得意な人なら「筆算」は不要かもしれない。同様に、優れたプログラマであれば、一度の「書く」という行為で、これらの２つの目的を達せられるだろう。しかし、普通のプログラマにとっては、それはなかなか難しいことである。

実際、「筆算の跡」がそのまま残ってしまったようなソースコードは、世の中に溢れている。「もっと単純に書けるのに、なんでこんなに複雑な書き方をしているのだろう？」と思うような記述の多くは、プログラミング中に試行錯誤しながら何度も書き直したものが、そのまま残っているのだろう。

★

「知るため」に書かれたコードは、密林を切り開きながら作った道のように曲がりくねっている。密林を抜ければそれでいいじゃないか、と思うかもしれない。しかし、その道を後から通る者（コードを保守する者）のことも考えて欲しい。見通しの悪い道では、後から来る人がいつ獣（バグ）に出くわすか分からない。

試行錯誤によって道を切り開くことができたら、次には、その道を綺麗に整えることを考えるべきである。プログラムが動いただけで安心してはいけない。振り返ってみたら、真っ直ぐできるはずのところが曲がっていたりするものだ。

コードを綺麗にするということ自体は、そう難しいことではない。深呼吸をしてコードを読み返すだけでも、直すべきところをいくつか発見できるだろう（もちろん、美しいプログラムとはどういうものか、ということが分かっていることが前提だが）。より本格的に取り組むなら、「リファクタリング」について学ぶとよいだろう。

あとは、コードを他の人に見せ、指摘してもらうことである。もし、自分のチームに、ソースコードをレビューしたり、ペアプログラミングを行ったりする習慣がないのであれば、それらを取り入れてみるのもいいだろう。

応援のクリックお願いします →

※下記リンクを参照
・結城浩氏「ソフトウェアは、私たちの想像よりもずっと複雑」
・平鍋健児氏「全体は詳細に先行するか？あるいは、「作り出す」ことの中心について。」

■関連記事
・真夜中のコード
・リファクタリング～動いているプログラムを触る

結城浩のPerlクイズ

posted with amazlet on 06.06.24

結城浩
ソフトバンククリエイティブ (2002/08)
売り上げランキング: 302,856

Amazon.co.jp で詳細を見る

オブジェクトハンドブック〈2002〉

posted with amazlet on 06.06.24

永和システムマネジメントオブジェクト倶楽部平鍋健児
ピアソンエデュケーション (2001/10)
売り上げランキング: 55,223

おすすめ度の平均:

OOのことを幅広く紹介している参考書

役には立たないが面白いヨ

オブジェクト指向のデスクトップリファレンス

Amazon.co.jp で詳細を見る

チームのために自分のスタイルを曲げる覚悟

ある開発プロジェクトで、コーディングルールなどを決めていたときのこと。外注プログラマの中に自己主張の強い人がいた。コメントはこう書くべきだ、モジュールの構成はこうすべきだと、意見を出してくる。それ自体はいいのだが、その内容は我々の経験からすると「一般的でない」と思われるものだった。しかし、彼はチームが初めて採用する技術について詳しいという触れ込みだったし、あまり熱心に主張するので、結局、彼の意見を取り入れて開発を進めることになった。

しかしである。開発を進めるうちに、その選択が間違いだったことが明らかになっていった。彼のルールのおかげで、開発効率は悪く、コードの保守もしにくくなった。しかも、彼自身の技術力も決して高いわけではなく、ただ「妙なこだわり」を持っているというだけであることが分かった。

「妙なこだわり」をもつ人が偉そうに喋っていると、「できる人」のように見えてしまうことがあるのだ。騙されてはいけない。

★

プログラマというのは、多かれ少なかれ、自分のやり方にこだわりを持っているものだ。コードの括弧の書き方や変数名の付け方から、設計方針、開発言語や実装技術の選択のようなものまで。

こだわりを持つこと自体は悪いことではない。しかし、それに固執するのは間違いだろう。どんなやり方にも一長一短があるものである。チームに必要であると思われることを提案していくのはよいことだが、それを最終的に採用するかどうかは、チームが判断することだ。個人的なこだわりを必要以上に主張すべきではないだろう。

★

マーチン・ファウラー氏は、「プロのプログラマというのは、チームのために自分のスタイルを曲げる覚悟がある」と言う（※１）。「覚悟」というと、ちょっと気負って聞こえるが、「自分のスタイルを曲げる」ということにストレスを感じるようでは、プロとはいえない。

ルールを無批判に受け入れよと言うつもりもないが、ルールをルールとして受け入れるだけの度量の広さを持ちたいものである。

応援のクリックお願いします →

※１　bliki_ja 「コードがドキュメントだ」より

超図解 Javaルールブック

posted with amazlet on 06.06.20

電通国際情報サービス開発技術部エクスメディア
エクスメディア (2004/04)
売り上げランキング: 70,864

おすすめ度の平均:

ルールは早めに身につけたほうが良い

Ｊａｖａを再利用化しやすくする為の工夫

Javaプログラマ必見！！

Amazon.co.jp で詳細を見る

覚悟すること

posted with amazlet on 06.06.20

徳岡孝夫
文藝春秋 (1997/12)
売り上げランキング: 1,111,543

Amazon.co.jp で詳細を見る

YAGNI ～予想でモノを作るな

人間には未来の出来事を知ることはできない。だから、せめてできる限りの予想をして未来に備えよう、ということになる。プログラマの仕事でもそうだ。

「次のバージョンアップでこんな機能が要求されてるんだけど」
「そんなこともあろうかと、その仕組みは既に作ってあります」

なんてことになれば、得意な気分になる。予想が当たれば嬉しいのは、ギャンブルもソフトウェア開発も同じだ。

★

しかし、予想に基づく行動にはリスクが伴う。それもギャンブルと同じである。

以前、私は、あるシステムの内部データを CSV ファイルとして出力するプログラムを作った。その際、将来のバージョンアップで出力するデータ項目が追加されるかもしれないと考えた。そこで、プログラムを直さなくても、「定義ファイル」に項目を追加するだけで、CSV に出力できるようにしておいた（顧客からそんな要望はなかったにも関わらずだ）。

しかしである。その後、実際に追加された出力項目は、どれも定義ファイルでは対応できないものばかりだった。今までにない計算が必要なものだったり、全く別のデータの参照が必要なものだったり・・・。結局、プログラムを変更して対応せざるをえなかった。そして、最初に定義ファイルを利用するために作ったソースコードの構造は、中途半端で邪魔な負の遺産として残ることになった。

このように、予測に基づくプログラミングにはリスクが伴う。予想が外れれば、先行投資した時間が無駄になるばかりか、ソースコードが無駄に複雑化し、以後のメンテナンスにも影響を与えるのである。

★

XP（エクストリーム・プログラミング）には、YAGNI という言葉がある。「You Aren't Going to Need It.」の略で、直訳すれば「あなたはそれを必要とするようにはならないだろう」。意訳すれば「そんなものいらないだろう」ということだ。つまり、「予想でモノを作るな」、「今必要な機能だけを作れ」ということである。

本当に必要な機能だけを作れば、プログラムの構造はシンプルになる。シンプルなプログラムには機能追加も楽にできるのだから、将来、別の機能が求められれば、そのときに作ればいいというわけである。

★

これは簡単なことのように見えるが、実は難しい。技術的に難しいのではなく、心理的に難しいのだ。特に、経験を積んだ技術者ほど、そう感じるのではないだろうか。プログラマというものは、多少の労力を払ってでも「拡張性」や「汎用性」が高く、気の利いた機能を持ったプログラムを作りたいと考えるからだ。

もちろん、そうした、いわば「理想的な」プログラムを目指すということも大切である。YAGNI を絶対視し、常にシンプルさを最優先すればよいというものでもないだろう。結局のところ、そのシステムの特徴や顧客の特徴、開発プロジェクトの状況などを踏まえ、適切なバランスを考えることが重要だろうと思う（※）。

それでも YAGNI という言葉にとても価値があると思うのは、ともすれば理想に走りがちな開発者に現実的なバランス感覚を与えてくれるからである。設計を始めるとき、あるいは設計に迷ったとき、思い出したい言葉である。

応援のクリックお願いします →

※言うまでもないが、「理想的なプログラムを作れるが、あえて作らない」ということと、「理想的なプログラムが作れない」ということは違う。また、「理想的なプログラムを開発すること」と、「理想的なプログラム開発」も違う。

■関連記事
・気の利いたプログラムは顧客満足度を上げ、開発工数を下げる

XPエクストリームプログラミング懐疑編
―XPはソフトウェア開発の救世主たりえるのか

posted with amazlet on 06.06.11

ピートマクブリーン
ピアソンエデュケーション (2002/12)
売り上げランキング: 271,315

おすすめ度の平均:

「自ら考える」ための一冊（決して XP をけなす本ではない）

宗教論争に待った！をかけてる？

Amazon.co.jp で詳細を見る

ペアプログラミング―エンジニアとしての指南書

posted with amazlet on 06.06.11

ローリーウィリアムズロバートケスラー
ピアソンエデュケーション (2003/03)
売り上げランキング: 61,747

おすすめ度の平均:

上司説得のための武器に

開発するにあたって

ペアプログラミングを包括した解説書

Amazon.co.jp で詳細を見る

プログラムの寿命

ひとつのプログラムをいつまで使い続けることができるだろうか。

ハードウェアであるコンピュータは老朽化するが、ソフトウェアであるプログラムは物理的には老朽化しない。０と１が並んでいるだけのただの「情報」なのだから。しかし、ある意味でプログラムにも寿命はある。プログラムは変わらなくとも、それを取り巻く環境が変わるからだ。

例えば、長い間会社の業務で使われているようなシステムも、業務のやり方が変更されると、そのままでは使えなくなってしまう。そんなことがなくても、扱うデータの量やユーザー数が増えて、システムが耐えられなくなることもある。あるいは、MS-DOS の時代が終わり、Windows の時代がやってきたように、実行環境自体が大きく変わってしまうこともある。Y2K問題（2000年問題）のように、プログラム自体が時限爆弾を内包していることもある。

★

プログラマの世界では、「動いているプログラムは触るな」と言われることも多いが、触らなければ安心というわけでもないのである。ソフトウェアが何年も使われ続けるということは、意外と難しいのだ。

システムが使えなくなれば、改造するか、新しく作ることになる。オーダーメイドの場合、それなりのコストも必要だ。つまり、ユーザーにとっては、長く使えるプログラムほど価値があるということになる（※）。

長生きできるシステムを作るためには、将来的な利用シーンを見据えた設計、将来性のある実行環境の選択、処理効率のよい実装など、色々な点での考慮が必要となるだろう。変化の速い業界にあっては難しい課題ではあると思うが、開発者がそうしたことを意識するかどうかで、システムの寿命もずいぶん違ってくるのではないだろうか。

応援のクリックお願いします →

※適度なタイミングでシステムを作り直したほうがソースがきれいになるし、開発会社の商売としてもありがたいのだが、それはまた別の話である。

■関連記事
・リファクタリング～動いているプログラムを触る