2009年05月16日

プログラマーの開発速度は「はまる」時間の長さで決まる

Check このエントリーをはてなブックマークに追加
プログラミングを始めてから今日に至るまで、
様々なタイプのプログラマーと開発を共にしてきたが、
驚くべき速度で高い品質のソフトウェアを作り上げるプログラマーには、
一つ共通の特徴があるように思える。
それは、「はまる」時間が極端に短い、ということである。

私自身、「風のプログラマー」を指向しており、開発速度を重要視している。
例えば平成14年未踏ソフトウェア創造事業「PICSY」では、
発表直前に知人でプロジェクトリーダーの鈴木健にレスキュー隊として呼ばれて
2,3日でGUI全般と、クライアント/サーバー通信部分の設計と実装を終わらせたのだが、
このときなどは、大体の要件を口頭で聞いた後は、
ほぼまったく手が止まらずコードを書き続ける感じで開発をしていた。

「はまる」時間の長さは開発速度に直結するわけだが、
プログラマーが「はまる」場合にはある程度の傾向があると思うので、
今日は「はまる」プログラマーの傾向と、その対策を考えてみたい。

1. クラスやメソッドの命名が不適切
先日ネットで「きれいなソースコードを書くために必要な、たったひとつの単純な事
という記事が話題になったが、この内容には私も全面的に賛成で、
クラスやフィールド、メソッド、名前空間など、とにかく文字として表れる名前には、
必ず、例外なく、正しく誤解のない命名を徹底することが非常に重要だ。

不適切な名前は、クラスやメソッドの機能の誤解を招き、まさかこの名前でそんな
動作をするとは思わなかった、という類のはまり方は本当に最悪で、
時間も無駄になるしモチベーションも減退するし、そのコードを書いたプログラマーに
対しての信頼も失われてしまう。

一人でコードを書いているときでさえ、コード規模がある程度以上になると、
自分がつけた適当な名前に自分自身ではまる、という三流パロディーのような事態が
起こりえるが、複数人で開発しているときに適当な名前をつけてしまうと、
各所で「はまる」事態が発生し、開発効率が激減する。

2. 「とりあえず」書いたコードが悪さをしている
命名と同様に、どんな忙しい状況でも、「自分でも納得でき、人に見せても恥ずかしく
ないコードしかコミットしない」ことを守り続けることが重要である。

「今回は時間がないのでとりあえずこのままコミットします」といってコミットしたコードは、
多くの場合次回以降に発見が難しいバグの原因になるし、
場合によっては「今回」もその箇所が原因となって他の箇所で問題が発生し、
はまる原因となる。

「とりあえず」書いたコードとは、例えば次のようなものだ。

- エラーを根本解決せず、外側で例外を強引に捕捉して凌いでいる
- 「理由はよくわからないんですが、とりあえずこうやって書くと動くので...」
- 「危険な臭い」のするアルゴリズム
- 明らかにリファクタリング対象となるような、見た目が極端に汚いコード

期日が迫っており、とにかく時間がない、というような状況だと、
つい「とりあえず」書いたコードをコミットしたくなるかも知れないが、
忙しいときこそ、「適当に書いたコードはコミットしない」ことを死守すべきだ。

ソフトウェアが完成した後に見つかった問題に対応するには、
ソフトウェア完成前の何倍もの手間がかかることを、
私たちは経験的に知っているわけだから。

3. 「このままでは何かがおかしい」と感じながら作業を続けている
これは例えば、「もっといいやり方があるはずなんですけどね...」とぼやきながら、
あまり望ましくないと思われるやり方で開発を続けてる、というようなケースである。

「もっといいやり方がある」と感じるのは、今のコードの書き方だと、
同じような処理の記述を複数箇所に分散せずるを得ない、という状況だったり、
依存関係的にここにこんなコードが入るはずないんだけど、という状況だったり、
意識する必要がないはずのインターナルなクラスや構造を意識しないと問題が解決
しないような状況だったりする場合である。

そして、たぶん、その直感は合っている。

何かがおかしいなら、時間をかけてでもそのおかしさの根本原因を最初に確認しないと、
後ですべてをやりなおすことになる。「何かがおかしい」状態で作業を続ければ
続けるほど、後で必ず修正することになるコードを積み足して行くことになる。

4. ツールに振り回されている
ときどき、いざ問題を解決せん、ということで、頭で考えて大体の当たりを付ける前に、
突然デバッガーを起動して色々なところにブレークポイントを置いてみたり、
プロファイラーを起動したり、ソースコード間を行ったり来たりして
ディスプレイの前で腕を組んで首を傾げ、一向に開発が進まない、という人がいる。

もしこういうはまり方をしやすい人がいたら、
その人に対するアドバイスとして、一度ツールを使うのをやめてみることを提案したい。

そもそも、最近のIDEに搭載されているような便利なツールが存在しなかった頃から、
先人達はデバッグを行ってきたのだ。

はまった時にまず最初に行うことは、ツールを立ち上げることではなく、
「どの辺りに問題があるのか」について、頭で考えて当たりをつけることだ。
そして、その関連箇所のソースコードを読んで処理内容を確認することだ。

問題箇所を頭で考えることに慣れてくれば、
大抵の場合、テキストエディタさえあれば問題は割とすぐ解決できる。
そして、ツールが本領を発揮するのは、当たりを付けていないプログラマーに対してではなく、
当たりを付けているプログラマーに対してである、ということを忘れてはいけない。

頭で考えて当たりをつけることができないプログラマーにとっては、
デバッガーは単に速度の若干遅い実行エンジンでしかない。

5. 「よくあるつくり」に対する理解が乏しい
一つの言語をある程度の深さで習得した人は、
「あの言語でいうXXを実現するにはこの言語ではどうすればいいのかな?」
といった要領で異なる言語に対しても理解が早いものである。

同様に、「pluggableな機構を用意しているフレームワークだったらこの辺りに拡張ポイント
がありそうじゃない?あ、ほら、あった」といった要領で、たくさんのソフトウェアの
「つくり」に触れたことがあるプログラマーは、他のソフトウェアに対する理解が格段に早い。

「つくり」を理解するには、単にソフトウェアを使っているだけではダメで、
使うことになったソフトウェアに「深入り」することが重要だ。

例えばIDEを使っているだけでは、IDEの「つくり」のほんの一部しか理解できないが、
IDEのプラグインを何個も作っていけば、そのIDEの「つくり」についての理解を深めて
行くことができる。

「最近ではXXというフレームワークがあって」というような表層の情報をたくさん
集めることよりも、少なくても良いので、これは面白そうだ、というものについて深入りして、
内部の構造や拡張ポイント、設計の指針などを理解する方が、
速く美しくコードを書けるプログラマーになるための近道だと思うわけである。

6. クラスライブラリの存在を認知できていない
慶応大学の頃、理工学部のとある研究室で、そこにいた助手の人が、
「僕は新しい言語を勉強するときは必ずクラスライブラリのリファレンスにざっと目を通すよ」
と話していたことがあった。

これは新しい言語を学ぶときのとても効率の良い学習方法だと思う。

「頑張って作った後に、言語の方で既に用意してくれているクラスライブラリがあることがわかった」
というのも一種の「はまっている」状況であると言える。

また、単に開発工数が余分にかかるだけでなく、すでにクラスライブラリの存在を知っている人から
見ると、「わざわざ作ったからには何か違う処理が必要だったのでは」という風に見えて
しまい、考える時間を使わせてしまうこともあるので、注意が必要だ。

私は、「あるものは使い、無いものを作る」ことはソフトウェア開発の大原則の一つ
だと考えているが、その観点から言っても、よく使うであろうということですでに言語の方で
クラスライブラリを用意してくれていたり、よく使われるライブラリがあったりする場合には、
何か特別な理由がない限りクラスライブラリを使うべきだし、また、「どの辺りを見ればどの類の
クラスライブラリ群がある」という頭の中のインデックスを、言語習得時に最初に頭に入れてしまうと、
こうした問題は起こりにくくなってくるだろう。

他にもいろいろとあるものの
他にも、ソースコードが世代管理されていないとか、自動化されたテストケースがない、
といったようなジョエルテスト的な話もあるだろうし、プログラマーとしての「読み書きそろばん
のスキルにまず磨きをかける必要がある、という場合もあるだろう。
また、ウェブの情報に頼りすぎて、自分で解決する能力に磨きをかけられていない、という
ような話もあるだろう。


が、今回、上に書いたようなことにテーマを絞りたかった理由は、

(1) 適当に書いたコードは後でとても大きな被害をもたらす可能性が高い
(2) たくさんのソフトウェアの「つくり」に触れ、APIを熟知しよう

という二点を強調したかったからである。

もちろん、ソフトウェアのコンセプトを考えるときなどは、
むしろ、「はまる」ことの連続だし、それが健全な姿だろう。

が、ひとたび作るべきものが見えてくれば、そこから先の開発で
「はまる」時間は極力少なくすべきだし、上に書いたようなことを
気をつけながら開発を進めるように習慣をつけていけば、
頭の中で設計しながらサクサクとソースを書く、という感じで
プログラムが書けるようになってくるものだ。

■ 関連エントリ
プログラマー面接時の技術的な質問事項(アプレッソ版)
そして、ペアプログラミングが始まる
ソースコードのコメント率は20%を切ることが望ましい



アート・オブ・アジャイル デベロップメント<br>
―組織を成功に導くエクストリームプログラミング
James Shore Shane Warden
オライリージャパン
売り上げランキング: 15793
おすすめ度の平均: 5.0
5 現時点で最良のアジャイル解説本
5 アジャイルなやり方の具体的なガイド
5 アジャイルのための練習曲集


Check このエントリーをはてなブックマークに追加
lalha at 14:05 │プログラミング  │Comments(10)TrackBack(12)

トラックバックURL

この記事へのトラックバック

1. あなたのソースを汚くして生産性も下げる、たったひとつの間違い  [ よくわかりません ]   2009年05月17日 01:13
この内容には私も全面的に賛成で、クラスやフィールド、メソッド、名前空間など、とにかく文字として表れる名前には、必ず、例外なく、正しく誤解のない命名を徹底することが非常に重要だ。 http://blog.livedoor.jp/lalha/archives/50261226.html 先のエントリは、danさん*
2. 「はまらない」ような体制を作ろう  [ The net is vast ]   2009年05月17日 02:38
「はまる」時間で開発速度が決まるのであれば、そもそも「はまらない」ようにすればいい。そういう体制を作ろう。
3. 炎のプログラマー  [ 高密度小池 ]   2009年05月17日 12:53
4. 「はまる」時間  [ ♪8th Note♪ ]   2009年05月17日 23:15
 とても考えさせられ反省。。。私の場合確かにコーディングより考えている時間の方が...
5. 先に進むスピードを妨げるもの。  [ コーチングでさらに先の自分へ。blog版 ]   2009年05月20日 21:27
↓応援よろしくお願いします! 人気blogランキング こんにちは。コーチ・心理カウンセラーの粟野 剛史です。 小野和俊さんという方のブログ、明快な文章が好きで、折に触れて読んでいるのですが、ちょうど最近書いてるテーマに&nbsp;結びつく話があ...
6. ハマらないためにツールはある.  [ 後悔^H^H公開日記:別館 ]   2009年05月25日 10:54
ログラミングを始めてから今日に至るまで、 様々なタイプのプログラマーと開発を共にしてきたが、 驚くべき速度で高い品質のソフトウェアを作り上げるプログラマーには、 一つ共通の特徴があるように思える。 それは、「はまる」時間が極端に短い、ということである。 小野
プログラミングを始めてから今日に至るまで、様々なタイプのプログラマーと開発を共にしてきたが、驚くべき速度で高い品質のソフトウェアを作り上げるプログラマーには、一つの共通の特徴があるように思える。それは、「はまる」時間が極端に短い、ということである。
8. 開発速度  [ 気の向くままに・・・ ]   2009年05月27日 23:16
プログラマーの開発速度は「はまる」時間の長さで決まる 1. クラスやメソッドの命
9. 「はまる」傾向のプログラミング  [ アイビースター ]   2009年05月28日 06:01
昨日の「バグの無いプログラムを書く10個の方法」と似たような内容なのですが、プログラムを作っていると時々 「はまった??!」 と叫びたくなるようなことがあります。「はまる」と...
10. はまる時間が短い  [ それって食えるのか? ]   2009年06月17日 01:22
「『はまる』時間が短い」のは、特徴じゃなくて、結果だと思うけどな >揚げ足取り ;-) プログラマーの開発速度は「はまる」時間の長さで決...
11. An efficient programming!  [ gdgdっと無気力生活 (  ノ´ω`)ノ~゜ ]   2009年08月12日 21:06
小野和俊のブログ:プログラマーの開発速度は「はまる」時間の長さで決まる http://blog.livedoor.jp/lalha/archives/50261226.html
12. システムトレードのプログラミングの基本 -リンク集-  [ トレード環境構築ブログ ]   2010年11月19日 07:50
ほとんどプログラムの知識がない私が自作のシストレプログラムを書き始めてかれこれ1年近くたちました、空いた時間で少しずつ書き足してきたプログラムですが、何もかもが手探りでフローチャート等はたまにしか書かず設計図の大部分は頭の中というようなものが多い状態です、...

この記事へのコメント

1. Posted by sabazo   2009年05月16日 17:07
ああ、問題にはまるといった、本来の否定的な意味での「はまる」か。
没頭するという意味の「はまる」で読みはじめてしまい、???状態でしたwww
2. Posted by あ!パンダ   2009年05月16日 22:53
プログラムは パソコンにとって チャンスを与えるようなものです 大人だなぁー チャンスが輝き始めた瞬間が 達成がありますね
3. Posted by とおりすがり   2009年05月17日 09:37
>2. 「とりあえず」書いたコードが悪さをしている
本当に時間が無い時は「とりあえず」コードをコミットせざるを得ない状況もかなりあるかと思います。
※優秀ではないたくさんのPGの場合
「とりあえず」コードはある意味さけられない問題だと思いますので、後でどうリファクタリングしていくか、など体制面をしっかりする事で「はまる」を避ける事ができるかもしれませんね。
4. Posted by Leopardユーザー   2009年05月31日 23:33
3 > 命名と同様に、どんな忙しい状況でも、「自分でも納得でき、人に見せても恥ずかしく
> ないコードしかコミットしない」ことを守り続けることが重要である。

上の通りすがりさんと同意見です。
クラッシュに備えたソースコード保管の意味でも、終電間際など場面によっての「とりあえずコミット」はアリだと思います。
要は1カ所集中管理するから「人に見せても恥ずかしくないコードしかコミットしない」というスタンスになるのであって、その為の分散リポジトリだったりするわけです。

> 6. APIの存在を認知できていない
> 「僕は新しい言語を勉強するときは必ずAPIリファレンスにざっと目を通すよ」

本来のAPIの存在定義を誤解されてませんか?
APIというのは本来WindowsやUnix/Linuxのようなシステムの機能を呼び出すための窓口であって、特定のプログラム言語に依存するものではありません。

恐らくJavaAPIの事を指しての発言だと思いますが、最近よく聞くJava APIやらWeb APIという単語は後から「何か名前をつけよう」ってな事になって、元々あったAPIって単語に後からつけ加えた歴史的背景があります。つまりAPIの意味を拡大解釈しちゃったわけですね。

言語に依存する実装としてはクラスライブラリやライブラリがありますが、こちらと勘違いされてませんか?

例えばWindowsのAPIはVC++からも叩けるしVBやDelphiからだって叩けます。
公の場で「VC++のAPIを勉強したよ」なんて発言しようものなら赤面ものでしょう。
5. Posted by 小野和俊   2009年06月01日 04:20
> leopardユーザーさん

たしかに「API」より「クラスライブラリ」の方が適切ですね。
本文を修正しました。
6. Posted by jimsie   2009年06月17日 01:32
Leopardユーザー> APIというのは本来WindowsやUnix/Linuxのようなシステムの機能を呼び出すための窓口であって...

そんなことは無かろうもん。
unix なら、システムコールかライブラリだもんね。

Leopardユーザー> 公の場で「VC++のAPIを勉強したよ」なんて発言しようものなら赤面ものでしょう。

その発言は恥ずかしいけど、初めて Windows3.1 を触るときには、ざっと API の一覧には目を通したけどな。
7. Posted by Leopardユーザー   2009年06月20日 06:04
> jimsieさん

> unix なら、システムコールかライブラリだもんね。
ちなみに、そのシステムコールやライブラリの総称を「API」とも言います。

> 初めて Windows3.1 を触るときには、ざっと API の一覧には目を通したけどな。

だから「初めて」さわった時でしょ?
初めてWindowsでプログラムを勉強した時にセットで勉強するのはわかるけど、それ踏まえて

> 「僕は新しい言語を勉強するときは必ずAPIリファレンスにざっと目を通すよ」

この発言はブログ主が大学在学の頃の助手の方の発言なわけで、卒業時期から考えれば10年程度昔の話になります。
今ならWebAPIみたいな派生ワードがあるけど、当時の時代背景を考えればこの発言に疑問を感じたわけですよ。
むしろWin3.1のプログラムをされてたのなら10年前は貴方は既にプロのはず。僕よりも貴方のほうが疑問に感じるはずだと思いますが?
8. Posted by jimsie   2009年06月21日 19:59
あー、分かった。
「【言語】の API 」ってところが恥ずかしい、ってことね。
納得、納得 :=)
9. Posted by _   2009年09月28日 02:43
はまらない事を前提として考えたら、何になるかな
10. Posted by Movers   2011年04月28日 12:03
とりあえず」書いたコードが悪さをしている
本当に時間が無い時は「とりあえず」コードをコミットせざるを得ない状況もかなりあるかと思います。
※優秀ではないたくさんのPGの場合
「とりあえず」コードはある意味さけられない問題だと思いますので、後でどうリファクタリングしていくか、など体制面をしっかりする事で「はまる」を避ける事ができるかもしれませんね。

この記事にコメントする
(スパム対策のため、英数字のみからなるコメントは自動削除されますのでご注意ください。)

名前:
URL:
  情報を記憶: 評価: 顔