読者指向プログラミング

私は英語は苦手である。辞書があれば、英文を読むくらいなら何とかなるが、書く方はほとんどできない。日本語の場合も、読むよりも書くほうが難しいと思う。実際、こうしてブログを書いているが、なかなか上手く書けず、何度も書き直している。

しかし、プログラムのソースコードは、読むよりも書くほうが簡単な気がする。なぜだろう。

★

ソースコードを読むのが難しい理由のひとつは、プログラマによって書き方が大きく違うという点だろう。日本語の文章に例えれば、色々な方言が混ぜ合わされて書かれているようなものだろうか。

なるべく書き方が揃うようにと、「コーディング規約」のようなものを設けることも多いが、細かいところまでルール化するのは難しく、どうしてもプログラマの癖のようなものが出てしまう。

TMTOWTDI という言葉があるように、色々な書き方があるということは、必ずしも悪いことではない。しかし、コードの読みやすさという点に限って言えば、それを難しくしている要因のひとつだろう。

★

コードを読むのが難しいもうひとつの理由は、「表現下手なコード」が多いということだ。日本語でも、ブログなどを読んでいると、何を言いたいのか全く分からないような文章に出会うことがあると思う。ソースコードでは、それがもっと頻発する。

文章を書く場合は、その第一の目的が「伝える」ということなので、書き手は読みやすさということを意識するものだ。しかし、ソースコードを書く場合は、「伝える」ということ以前に「プログラムが正しく動作すること」に意識が行く。そのため、可読性はなおざりにされがちなのだろう（「誰のためのコード？」も参照）。

★

同じ機能のプログラムを作る場合でも、ソースコードは色々な書き方ができる。そんな中で、より読みやすい「表現」を選ぶこと。私はそれを「読者指向プログラミング」と呼んでいる。読みにくいコードはバグを混入させやすく、変更もしにくい。同じ機能を作るなら、読みやすいコードを書くべきである。

読みやすい文章を書くためには、ある程度の技術が必要である。それと同じ様に、読みやすいコードを書くためにも技術が必要だろう。例えば、関数設計、クラス設計が上手くできなければ、読みやすいコードを書くことはできない。しかし、読者志向プログラミングでもっと大事なことは、「読者を意識する」ということである。そして、どう書けば読みやすくなるか、ということを考えることだ。

★

プログラミング初心者には、どんなコードが読みやすいか分からないかもしれない。最初は、とにかく他人のコードを読むという経験が必要だろう。自分で多くのコードを読めば、どんなコードが読みやすく、どんなコードが読みにくいか、よく分かるようになるだろう。

そもそも、プログラマにとって、コードを読むことは、コードを書くことと同じくらい重要である。他人の書いたコードをデバッグしたり、改造したり、流用したりする際には必須のスキルだ。入手可能なコードは積極的に読み、読みにくいコードも読みこなせるような力をつけることも必要だろう。

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

ソースコードリーディングから学ぶ Javaの設計と実装

posted with amazlet on 06.12.24

WINGSプロジェクト佐藤匡剛山田祥寛
技術評論社
売り上げランキング: 9274

Amazon.co.jp で詳細を見る

Code Reading―オープンソースから学ぶソフトウェア開発技法

posted with amazlet on 06.12.24

トップスタジオまつもとゆきひろ平林俊一鵜飼文敏
毎日コミュニケーションズ
売り上げランキング: 50755

おすすめ度の平均:

意外なほどに教科書的な内容

ホップ・ステップ・ジャンプ

例題がわかりにくい

Amazon.co.jp で詳細を見る

私が資格を取ろうとしない理由

ITPro の「情報処理技術者試験は，存在価値がなくなったのか？」という記事を読んだ（※）。実は、私は資格を取ろうとしない技術者の一人である。いい機会なので、なぜ取ろうとしないのか、考えてみることにした。

★

まず思いつくのは、「他にもっとやりたいことが沢山ある」ということだ。この業界、常に新しく面白そうな技術が出てくる。調べてみたいことがどんどん増えて追いつかない状況だ。そんな中で、特に面白そうでもない資格試験の勉強をする気にはなれない。

では、もっと時間に余裕があれば資格の勉強をするのだろうか？　と考えると、やはりしないだろう。おそらく、別の趣味に使うと思う（小説を読んだり、映画を観たり・・・）。・・・結局のところ、単に勉強が嫌いなだけかもしれない。

ここまできて、「勉強しなければ受からない」という前提で考えていることに気がついた。資格試験というと、どうしてもそういうイメージがある。周りで受験している人を見ていてもそんな感じだし、冒頭で紹介した記事にも、

現役のプロジェクトマネージャが必ず，「プロジェクトマネージャ試験」に合格できるわけではない。合格するには，知識を整理するための受験勉強の時間を日々の業務とは別に割く必要がある。

とあるから、実際、そうなのだろう。

「現場で通用する力がある人なら受けるだけで取れる」というようなものなら受けてみてもいいのだが・・・。

というと、「なにをふざけたことを」と思われるかもしれないが、このことは、資格試験の「妥当性」という観点から考えると、結構深い問題のような気もする。資格試験の本来の目的は、「現場で通用する力があるかどうか」を調べることのはずだからだ。

★

最後に断っておくが、私は資格無用論者ではない。「そんな役に立たないものはいらん」などと言うつもりはない。何事も、体系的な勉強をし、基礎的な力をつけることは重要だということは知っている。だから、勉強して試験を受け、資格を取っている人は尊敬する。もちろん、自分にできないからこそ尊敬しているわけだ。

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

※yasuhoの隠れ家さん経由。

ゆうき式逆転発想勉強術―「勉強したくない!」を活用する

posted with amazlet on 06.12.17

ゆうきゆう
スリーエーネットワーク
売り上げランキング: 848

おすすめ度の平均:

読みやすい　参考になる発想がたくさん

なるほど！・はは0ん...という感じ

勉強に対する考え方が少し変わった

Amazon.co.jp で詳細を見る

合格への総まとめソフトウェア開発技術者めざせスコア+100〈2006‐2007〉

posted with amazlet on 06.12.17

小口達夫
アイテック
売り上げランキング: 28668

おすすめ度の平均:

解説が超充実してます

かなりよい。

Amazon.co.jp で詳細を見る

プログラマは考えるのが仕事

私の職場では２つ穴のパイプファイル（リングファイル）をよく使う。そのため、私はデスクの上にハンディタイプの２穴パンチを置いている。紙の縁に噛ませてパチンと鋏むだけの、よくあるやつだ。

あるとき、若いプログラマがこのパンチを借りに来た。何気なく彼の様子を見ていると、紙の真ん中を決めるのに苦労しているようだ。私のパンチには紙の位置を合わせるためのガイドが付いていないので、うまくできないのだろう。バインダーに綴じられた紙は、縁が揃っておらず、ガタガタになっていた。

こういうパンチを使うときは、紙を半分に折って、折り目をパンチの真ん中（目印がついている）に合わせるのである。もちろん、折り目は紙の端にちょっとつけるだけでいい。デスクワーカーなら常識の部類かと思ったが、こうしたパンチを使った経験がない人が知らないのは仕方がない。そのときはそう思った。・・・しかし、本当にそうだろうか？

★

問題は、彼がこの手順を「知らなかった」ことではない。それを「考えつかなかった」ことである（※１）。世の中には、教えてもらわなければ絶対に分からないこともあるが、考えれば分かることもある。ましてや、彼はプログラマだ。考えることが仕事なのだ。

特に、この「紙の真ん中に穴を開ける手順」のような例は、一種のアルゴリズムだと言っていいだろう。アルゴリズムは勉強して覚えるものだと思っている人もいるかもしれないが、それは誤解だ。もちろん、よくある基本的なアルゴリズム（検索だの並べ替えだの）は本を読んで覚えればいいし、既存のライブラリ等を使って実装すればいい。しかし、何か新しいソフトウェアを作るとき、そのソフトウェア独自の処理については、自分でアルゴリズムを考えるしかないのである。

つまり、プログラミングという仕事は、アルゴリズムを考え、それをコーディングすることである。プログラマが、紙の真ん中に穴を開ける方法を考えつかないようでは困るのだ。

★

それでも、考えても分からないものは仕方がない、と思う人もいるかもしれない。しかし、残念なことだが、ガタガタのシステムを納品されて「しょうがない」で済ませてくれる顧客はいない。

冒頭の穴あけパンチの例のように、「考える機会」は日常のいたるところに転がっている。そういう機会に、ちゃんと頭を使っている人と、適当なところで諦めている人とでは、プログラミングという仕事の上でも、差が出てくるだろう（※２）。

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

※１
あるいは、ガタガタでも構わないと思っていたのかもしれないが・・・。

※２
つまり、よきプログラマはよきライフハッカー（LifeHacker）でもあるということだ。ライフハックも、誰かが考えた情報を集めて実践するだけでは、自分の全ての仕事が改善できるわけではない（人それぞれやっている仕事が違うのだから）。自分の力でハッキングできなければ、やはりライフハッカーとは呼べないのである。

■関連記事
・プログラミングは体で覚えろ
・ビジネス書を読んだ気になる

■関連リンク
・A4用紙を手軽に三つ折りする方法（TImedia Biz.ID）

カールパンチ№35・ブルー №35-B

posted with amazlet on 06.12.09

カール事務機
売り上げランキング: 21418

Amazon.co.jp で詳細を見る

LifeHacks 楽しく効率よく仕事する技術

posted with amazlet on 06.12.10

原尻淳一小山龍介
宝島社
売り上げランキング: 1565

おすすめ度の平均:

いろんな方の仕事術を盗める本

Amazon.co.jp で詳細を見る

GOTOを使ってもいいんですか？

ある新人プログラマに質問を受けた。処理の流れをどう書いたらいいのか分からないという。

「GOTO を使ったらいいんじゃないの？」
「GOTO を使ってもいいんですか？」

なるほど、彼は GOTO を使ったらクビになるとでも思っているらしい。しかし、このケースでは、GOTO を使わなければ、既存の処理の流れを大きく書き直すか、かなり不自然な書き方をしなければ、目的を実現できなさそうだ。また、GOTO を使っても、コードがそれほど読みにくくなるようなこともないようだった。

「なるほど、どこかで GOTO を使ってはいけないと聞いたんだね。じゃぁ、なんで使ってはいけないと思う？」
「処理が追いかけにくくなるからです」

大きく違っているともいえないが、本質をついた答えではない。

確かに、GOTO を使えば、何処にでもジャンプできるので、読みにくいコードが書けてしまう。しかし、それは GOTO を使うこと自体が原因なのではなく、その使い方が原因なのだ。簡単に言えば、「道具ではなく人間が悪い」のである。

こうした「戒め」の背後には、必ず目的がある。ここでは、「コードを綺麗に書く」ということである。それなのに、戒めを守ることを優先して、本来の目的を逸脱していたのでは意味がない。GOTO を使わないことで汚いコードを書くぐらいなら、GOTO を使って綺麗なコードを書くべきだろう。

★

もちろん、私も、このような戒めが不要だとは思わない。なぜなら、ある程度プログラミングの経験を積まなければ、どんなコードが綺麗でどんなコードが汚いのか、分からないからだ（もっとも、経験しても分からない人もいるのだが・・・）。

例えば、子供を育てるときは「嘘をついてはいけない」と教えるだろう。しかし、大人同士の世界では「嘘も方便」などと言うし、「いい嘘」というのもある。だからといって、ものの善し悪しが分からない子供に対して、「場合によっては、嘘をついてもいいこともあるのだ」などと教えても、その子はただの嘘つきになってしまうだろう。だから、まずは「嘘をついてはいけない」と教えるのである（※）。

「GOTO を使うな」というのは、それと同じことだ。ソースコードの良し悪しが分からないプログラマに、GOTO を自由に使わせれば、劣悪なコードができてしまう。だから、とりあえず「GOTO を使うな」と言うのだ。つまり、「GOTO の扱いは難しいから、お前にはまだ早い」と言われているようなものだ。

★

冒頭の新人プログラマは、「GOTO を使うな」という戒めを知っていた。しかし、それに盲従してヘンテコな書き方をするようなこともなかった。どう書くのがよいのか、彼なりに悩んだのだろう。ちょうど、「嘘をついてはいけない」という戒めと「嘘が必要な時もある」という現実との狭間に悩む子供のように。

そして、どうしたらいいのか分からなくなって、私のところに質問してきたのである。これは、コードの「良し悪し」が理解できてきている、という証拠だろう。

戒め（ルール）は必要だが、それに頼りきって、自分で判断するということができなければ、一人前とはいえない。「お前にはまだ早い」と言われ続けて終わるのが嫌なら、ルールの裏にある本来の目的を理解し、自分で「悩む」ということも必要なのだろう。

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

※昔の子供は「嘘をつくと閻魔様に舌を抜かれる」などと脅かされたものだが、今はどうなのだろう？　子供を下手に大人扱いして、世の中に嘘つきを増産してはいないだろうか？

新・C言語入門シニア編

posted with amazlet on 06.12.03

林晴比古
ソフトバンククリエイティブ
売り上げランキング: 74189

おすすめ度の平均:

ふとしたときの辞書代わりに

シニアとあるが、入門書、新人研修のテキスト

Ｃ言語の教育書としては最高と思う

Amazon.co.jp で詳細を見る

Code Complete第2版〈上〉
―完全なプログラミングを目指して

posted with amazlet on 06.12.03

スティーブマコネル Steve McConnell クイープ
日経BPソフトプレス
売り上げランキング: 4985

おすすめ度の平均:

これは理解できないとヤバイです。

我流プログラミングから抜け出す意思のあるひとへ

人に勧めたくなる本

Amazon.co.jp で詳細を見る

外見も重視してください

顧客から、既存システムの画面に注釈を表示して欲しいという依頼があり、画面上に数行の文章を追加したイメージ画像が送られてきた。

ちょうど手が空いた外注のプログラマがいたので、その画像を渡して、プログラムを変更してもらった。といっても、画面をデザインするツールを使って、「ラベル」を張り、文字列を書くだけの簡単な作業だ。

しかしである。後で出来上がった画面を確認すると、顧客から送られてきた画像と、かなり印象が違っていた。追加した文章の「行間」が開きすぎているのだ。

作業をお願いしたプログラマに指摘して直してもらってもよかったのだが、そのまま自分で修正した。そのほうが早かったし、彼もそうした細かいことを言われたくないかもしれないと思ったからだ。

しかし、その判断が彼にとって良かったのかどうかはわからない。それがもし自社の若手プログラマだったら、指摘して直させただろう。実際、少し前には、同じ理由で、新人プログラマに別の画面レイアウトを直させたばかりだった。

★

実は、そういう私も、新人の頃に同じようなことをして、リーダーに指摘されたことがある。

ある画面に、黒い三角形が表示されたボタンを付けたときのことだ。ちょうどカーソルキーのように、上下左右の方向を表す４つのボタンだった。私は、それらに、あえて顧客が作った資料の画像とは違った三角形を載せた。資料の三角形は大きすぎるし、並べたときのバランスも悪いと思ったからだ。つまり、自分では親切のつもりだったのだ。

しかし、リーダーに見せると、顧客の指定している通りに直してくれと言われた。今にして思えば当然である。受託開発では、開発しているプログラムは顧客のものであり、私のものではないのだから。

プログラマの中には、このようなシステムの動作に関係ないようなことはどうでもよいと思う人もいる。しかし、どうでもよいのなら、依頼者の意向に合わせてやればいいではないか。

顧客が提示するデザインには、こちらには分からない「こだわり」があるかもしれない。特に、デザイナーが携わっているような場合には、１ドットでも変えてしまえば、彼らの仕事を台無しにしてしまうかもしれない。

★

もちろん、現実には、顧客側に何のこだわりもない場合も多いだろう。ワープロの文書上に「罫線」で描かれているような画面を、そのままプログラムで再現することはできない。また、技術的な制限によって、顧客の希望通りにできないこともあるだろう。

しかし、どんな場合でも、なるべく顧客の意図を汲み取って、それに近づけようと努力はすべきだ。意図がはっきりしない場合、あるいは実現できない場合には、顧客とよく相談しながら進めていく必要がある（実際に画面を作って見てもらうということが最も有効だ）。それは、「データ処理」だろうと、「画面レイアウト」だろうと同じことなのである。

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

■関連記事
・デザイナーの屈辱
・アイコンの色を塗る時