プログラミングを始めてから今日に至るまで、
様々なタイプのプログラマーと開発を共にしてきたが、
驚くべき速度で高い品質のソフトウェアを作り上げるプログラマーには、
一つ共通の特徴があるように思える。
それは、「はまる」時間が極端に短い、ということである。
様々なタイプのプログラマーと開発を共にしてきたが、
驚くべき速度で高い品質のソフトウェアを作り上げるプログラマーには、
一つ共通の特徴があるように思える。
それは、「はまる」時間が極端に短い、ということである。
私自身、「風のプログラマー」を指向しており、開発速度を重要視している。
例えば平成14年未踏ソフトウェア創造事業「PICSY」では、
発表直前に知人でプロジェクトリーダーの鈴木健にレスキュー隊として呼ばれて
2,3日でGUI全般と、クライアント/サーバー通信部分の設計と実装を終わらせたのだが、
このときなどは、大体の要件を口頭で聞いた後は、
ほぼまったく手が止まらずコードを書き続ける感じで開発をしていた。
「はまる」時間の長さは開発速度に直結するわけだが、
プログラマーが「はまる」場合にはある程度の傾向があると思うので、
今日は「はまる」プログラマーの傾向と、その対策を考えてみたい。
1. クラスやメソッドの命名が不適切
先日ネットで「きれいなソースコードを書くために必要な、たったひとつの単純な事」
という記事が話題になったが、この内容には私も全面的に賛成で、
クラスやフィールド、メソッド、名前空間など、とにかく文字として表れる名前には、
必ず、例外なく、正しく誤解のない命名を徹底することが非常に重要だ。
不適切な名前は、クラスやメソッドの機能の誤解を招き、まさかこの名前でそんな
動作をするとは思わなかった、という類のはまり方は本当に最悪で、
時間も無駄になるしモチベーションも減退するし、そのコードを書いたプログラマーに
対しての信頼も失われてしまう。
一人でコードを書いているときでさえ、コード規模がある程度以上になると、
自分がつけた適当な名前に自分自身ではまる、という三流パロディーのような事態が
起こりえるが、複数人で開発しているときに適当な名前をつけてしまうと、
各所で「はまる」事態が発生し、開発効率が激減する。
2. 「とりあえず」書いたコードが悪さをしている
命名と同様に、どんな忙しい状況でも、「自分でも納得でき、人に見せても恥ずかしく
ないコードしかコミットしない」ことを守り続けることが重要である。
「今回は時間がないのでとりあえずこのままコミットします」といってコミットしたコードは、
多くの場合次回以降に発見が難しいバグの原因になるし、
場合によっては「今回」もその箇所が原因となって他の箇所で問題が発生し、
はまる原因となる。
「とりあえず」書いたコードとは、例えば次のようなものだ。
- エラーを根本解決せず、外側で例外を強引に捕捉して凌いでいる
- 「理由はよくわからないんですが、とりあえずこうやって書くと動くので...」
- 「危険な臭い」のするアルゴリズム
- 明らかにリファクタリング対象となるような、見た目が極端に汚いコード
期日が迫っており、とにかく時間がない、というような状況だと、
つい「とりあえず」書いたコードをコミットしたくなるかも知れないが、
忙しいときこそ、「適当に書いたコードはコミットしない」ことを死守すべきだ。
ソフトウェアが完成した後に見つかった問題に対応するには、
ソフトウェア完成前の何倍もの手間がかかることを、
私たちは経験的に知っているわけだから。
3. 「このままでは何かがおかしい」と感じながら作業を続けている
これは例えば、「もっといいやり方があるはずなんですけどね...」とぼやきながら、
あまり望ましくないと思われるやり方で開発を続けてる、というようなケースである。
「もっといいやり方がある」と感じるのは、今のコードの書き方だと、
同じような処理の記述を複数箇所に分散せずるを得ない、という状況だったり、
依存関係的にここにこんなコードが入るはずないんだけど、という状況だったり、
意識する必要がないはずのインターナルなクラスや構造を意識しないと問題が解決
しないような状況だったりする場合である。
そして、たぶん、その直感は合っている。
何かがおかしいなら、時間をかけてでもそのおかしさの根本原因を最初に確認しないと、
後ですべてをやりなおすことになる。「何かがおかしい」状態で作業を続ければ
続けるほど、後で必ず修正することになるコードを積み足して行くことになる。
4. ツールに振り回されている
ときどき、いざ問題を解決せん、ということで、頭で考えて大体の当たりを付ける前に、
突然デバッガーを起動して色々なところにブレークポイントを置いてみたり、
プロファイラーを起動したり、ソースコード間を行ったり来たりして
ディスプレイの前で腕を組んで首を傾げ、一向に開発が進まない、という人がいる。
もしこういうはまり方をしやすい人がいたら、
その人に対するアドバイスとして、一度ツールを使うのをやめてみることを提案したい。
そもそも、最近のIDEに搭載されているような便利なツールが存在しなかった頃から、
先人達はデバッグを行ってきたのだ。
はまった時にまず最初に行うことは、ツールを立ち上げることではなく、
「どの辺りに問題があるのか」について、頭で考えて当たりをつけることだ。
そして、その関連箇所のソースコードを読んで処理内容を確認することだ。
問題箇所を頭で考えることに慣れてくれば、
大抵の場合、テキストエディタさえあれば問題は割とすぐ解決できる。
そして、ツールが本領を発揮するのは、当たりを付けていないプログラマーに対してではなく、
当たりを付けているプログラマーに対してである、ということを忘れてはいけない。
頭で考えて当たりをつけることができないプログラマーにとっては、
デバッガーは単に速度の若干遅い実行エンジンでしかない。
5. 「よくあるつくり」に対する理解が乏しい
一つの言語をある程度の深さで習得した人は、
「あの言語でいうＸＸを実現するにはこの言語ではどうすればいいのかな？」
といった要領で異なる言語に対しても理解が早いものである。
同様に、「pluggableな機構を用意しているフレームワークだったらこの辺りに拡張ポイント
がありそうじゃない？あ、ほら、あった」といった要領で、たくさんのソフトウェアの
「つくり」に触れたことがあるプログラマーは、他のソフトウェアに対する理解が格段に早い。
「つくり」を理解するには、単にソフトウェアを使っているだけではダメで、
使うことになったソフトウェアに「深入り」することが重要だ。
例えばIDEを使っているだけでは、IDEの「つくり」のほんの一部しか理解できないが、
IDEのプラグインを何個も作っていけば、そのIDEの「つくり」についての理解を深めて
行くことができる。
「最近ではＸＸというフレームワークがあって」というような表層の情報をたくさん
集めることよりも、少なくても良いので、これは面白そうだ、というものについて深入りして、
内部の構造や拡張ポイント、設計の指針などを理解する方が、
速く美しくコードを書けるプログラマーになるための近道だと思うわけである。
6. クラスライブラリの存在を認知できていない
慶応大学の頃、理工学部のとある研究室で、そこにいた助手の人が、
「僕は新しい言語を勉強するときは必ずクラスライブラリのリファレンスにざっと目を通すよ」
と話していたことがあった。
これは新しい言語を学ぶときのとても効率の良い学習方法だと思う。
「頑張って作った後に、言語の方で既に用意してくれているクラスライブラリがあることがわかった」
というのも一種の「はまっている」状況であると言える。
また、単に開発工数が余分にかかるだけでなく、すでにクラスライブラリの存在を知っている人から
見ると、「わざわざ作ったからには何か違う処理が必要だったのでは」という風に見えて
しまい、考える時間を使わせてしまうこともあるので、注意が必要だ。
私は、「あるものは使い、無いものを作る」ことはソフトウェア開発の大原則の一つ
だと考えているが、その観点から言っても、よく使うであろうということですでに言語の方で
クラスライブラリを用意してくれていたり、よく使われるライブラリがあったりする場合には、
何か特別な理由がない限りクラスライブラリを使うべきだし、また、「どの辺りを見ればどの類の
クラスライブラリ群がある」という頭の中のインデックスを、言語習得時に最初に頭に入れてしまうと、
こうした問題は起こりにくくなってくるだろう。
他にもいろいろとあるものの
他にも、ソースコードが世代管理されていないとか、自動化されたテストケースがない、
といったようなジョエルテスト的な話もあるだろうし、プログラマーとしての「読み書きそろばん」
のスキルにまず磨きをかける必要がある、という場合もあるだろう。
また、ウェブの情報に頼りすぎて、自分で解決する能力に磨きをかけられていない、という
ような話もあるだろう。
が、今回、上に書いたようなことにテーマを絞りたかった理由は、
(1) 適当に書いたコードは後でとても大きな被害をもたらす可能性が高い
(2) たくさんのソフトウェアの「つくり」に触れ、APIを熟知しよう
という二点を強調したかったからである。
もちろん、ソフトウェアのコンセプトを考えるときなどは、
むしろ、「はまる」ことの連続だし、それが健全な姿だろう。
が、ひとたび作るべきものが見えてくれば、そこから先の開発で
「はまる」時間は極力少なくすべきだし、上に書いたようなことを
気をつけながら開発を進めるように習慣をつけていけば、
頭の中で設計しながらサクサクとソースを書く、という感じで
プログラムが書けるようになってくるものだ。
■ 関連エントリ
・プログラマー面接時の技術的な質問事項(アプレッソ版)
・そして、ペアプログラミングが始まる
・ソースコードのコメント率は20%を切ることが望ましい
現時点で最良のアジャイル解説本
アジャイルなやり方の具体的なガイド
アジャイルのための練習曲集
例えば平成14年未踏ソフトウェア創造事業「PICSY」では、
発表直前に知人でプロジェクトリーダーの鈴木健にレスキュー隊として呼ばれて
2,3日でGUI全般と、クライアント/サーバー通信部分の設計と実装を終わらせたのだが、
このときなどは、大体の要件を口頭で聞いた後は、
ほぼまったく手が止まらずコードを書き続ける感じで開発をしていた。
「はまる」時間の長さは開発速度に直結するわけだが、
プログラマーが「はまる」場合にはある程度の傾向があると思うので、
今日は「はまる」プログラマーの傾向と、その対策を考えてみたい。
1. クラスやメソッドの命名が不適切
先日ネットで「きれいなソースコードを書くために必要な、たったひとつの単純な事」
という記事が話題になったが、この内容には私も全面的に賛成で、
クラスやフィールド、メソッド、名前空間など、とにかく文字として表れる名前には、
必ず、例外なく、正しく誤解のない命名を徹底することが非常に重要だ。
不適切な名前は、クラスやメソッドの機能の誤解を招き、まさかこの名前でそんな
動作をするとは思わなかった、という類のはまり方は本当に最悪で、
時間も無駄になるしモチベーションも減退するし、そのコードを書いたプログラマーに
対しての信頼も失われてしまう。
一人でコードを書いているときでさえ、コード規模がある程度以上になると、
自分がつけた適当な名前に自分自身ではまる、という三流パロディーのような事態が
起こりえるが、複数人で開発しているときに適当な名前をつけてしまうと、
各所で「はまる」事態が発生し、開発効率が激減する。
2. 「とりあえず」書いたコードが悪さをしている
命名と同様に、どんな忙しい状況でも、「自分でも納得でき、人に見せても恥ずかしく
ないコードしかコミットしない」ことを守り続けることが重要である。
「今回は時間がないのでとりあえずこのままコミットします」といってコミットしたコードは、
多くの場合次回以降に発見が難しいバグの原因になるし、
場合によっては「今回」もその箇所が原因となって他の箇所で問題が発生し、
はまる原因となる。
「とりあえず」書いたコードとは、例えば次のようなものだ。
- エラーを根本解決せず、外側で例外を強引に捕捉して凌いでいる
- 「理由はよくわからないんですが、とりあえずこうやって書くと動くので...」
- 「危険な臭い」のするアルゴリズム
- 明らかにリファクタリング対象となるような、見た目が極端に汚いコード
期日が迫っており、とにかく時間がない、というような状況だと、
つい「とりあえず」書いたコードをコミットしたくなるかも知れないが、
忙しいときこそ、「適当に書いたコードはコミットしない」ことを死守すべきだ。
ソフトウェアが完成した後に見つかった問題に対応するには、
ソフトウェア完成前の何倍もの手間がかかることを、
私たちは経験的に知っているわけだから。
3. 「このままでは何かがおかしい」と感じながら作業を続けている
これは例えば、「もっといいやり方があるはずなんですけどね...」とぼやきながら、
あまり望ましくないと思われるやり方で開発を続けてる、というようなケースである。
「もっといいやり方がある」と感じるのは、今のコードの書き方だと、
同じような処理の記述を複数箇所に分散せずるを得ない、という状況だったり、
依存関係的にここにこんなコードが入るはずないんだけど、という状況だったり、
意識する必要がないはずのインターナルなクラスや構造を意識しないと問題が解決
しないような状況だったりする場合である。
そして、たぶん、その直感は合っている。
何かがおかしいなら、時間をかけてでもそのおかしさの根本原因を最初に確認しないと、
後ですべてをやりなおすことになる。「何かがおかしい」状態で作業を続ければ
続けるほど、後で必ず修正することになるコードを積み足して行くことになる。
4. ツールに振り回されている
ときどき、いざ問題を解決せん、ということで、頭で考えて大体の当たりを付ける前に、
突然デバッガーを起動して色々なところにブレークポイントを置いてみたり、
プロファイラーを起動したり、ソースコード間を行ったり来たりして
ディスプレイの前で腕を組んで首を傾げ、一向に開発が進まない、という人がいる。
もしこういうはまり方をしやすい人がいたら、
その人に対するアドバイスとして、一度ツールを使うのをやめてみることを提案したい。
そもそも、最近のIDEに搭載されているような便利なツールが存在しなかった頃から、
先人達はデバッグを行ってきたのだ。
はまった時にまず最初に行うことは、ツールを立ち上げることではなく、
「どの辺りに問題があるのか」について、頭で考えて当たりをつけることだ。
そして、その関連箇所のソースコードを読んで処理内容を確認することだ。
問題箇所を頭で考えることに慣れてくれば、
大抵の場合、テキストエディタさえあれば問題は割とすぐ解決できる。
そして、ツールが本領を発揮するのは、当たりを付けていないプログラマーに対してではなく、
当たりを付けているプログラマーに対してである、ということを忘れてはいけない。
頭で考えて当たりをつけることができないプログラマーにとっては、
デバッガーは単に速度の若干遅い実行エンジンでしかない。
5. 「よくあるつくり」に対する理解が乏しい
一つの言語をある程度の深さで習得した人は、
「あの言語でいうＸＸを実現するにはこの言語ではどうすればいいのかな？」
といった要領で異なる言語に対しても理解が早いものである。
同様に、「pluggableな機構を用意しているフレームワークだったらこの辺りに拡張ポイント
がありそうじゃない？あ、ほら、あった」といった要領で、たくさんのソフトウェアの
「つくり」に触れたことがあるプログラマーは、他のソフトウェアに対する理解が格段に早い。
「つくり」を理解するには、単にソフトウェアを使っているだけではダメで、
使うことになったソフトウェアに「深入り」することが重要だ。
例えばIDEを使っているだけでは、IDEの「つくり」のほんの一部しか理解できないが、
IDEのプラグインを何個も作っていけば、そのIDEの「つくり」についての理解を深めて
行くことができる。
「最近ではＸＸというフレームワークがあって」というような表層の情報をたくさん
集めることよりも、少なくても良いので、これは面白そうだ、というものについて深入りして、
内部の構造や拡張ポイント、設計の指針などを理解する方が、
速く美しくコードを書けるプログラマーになるための近道だと思うわけである。
6. クラスライブラリの存在を認知できていない
慶応大学の頃、理工学部のとある研究室で、そこにいた助手の人が、
「僕は新しい言語を勉強するときは必ずクラスライブラリのリファレンスにざっと目を通すよ」
と話していたことがあった。
これは新しい言語を学ぶときのとても効率の良い学習方法だと思う。
「頑張って作った後に、言語の方で既に用意してくれているクラスライブラリがあることがわかった」
というのも一種の「はまっている」状況であると言える。
また、単に開発工数が余分にかかるだけでなく、すでにクラスライブラリの存在を知っている人から
見ると、「わざわざ作ったからには何か違う処理が必要だったのでは」という風に見えて
しまい、考える時間を使わせてしまうこともあるので、注意が必要だ。
私は、「あるものは使い、無いものを作る」ことはソフトウェア開発の大原則の一つ
だと考えているが、その観点から言っても、よく使うであろうということですでに言語の方で
クラスライブラリを用意してくれていたり、よく使われるライブラリがあったりする場合には、
何か特別な理由がない限りクラスライブラリを使うべきだし、また、「どの辺りを見ればどの類の
クラスライブラリ群がある」という頭の中のインデックスを、言語習得時に最初に頭に入れてしまうと、
こうした問題は起こりにくくなってくるだろう。
他にもいろいろとあるものの
他にも、ソースコードが世代管理されていないとか、自動化されたテストケースがない、
といったようなジョエルテスト的な話もあるだろうし、プログラマーとしての「読み書きそろばん」
のスキルにまず磨きをかける必要がある、という場合もあるだろう。
また、ウェブの情報に頼りすぎて、自分で解決する能力に磨きをかけられていない、という
ような話もあるだろう。
が、今回、上に書いたようなことにテーマを絞りたかった理由は、
(1) 適当に書いたコードは後でとても大きな被害をもたらす可能性が高い
(2) たくさんのソフトウェアの「つくり」に触れ、APIを熟知しよう
という二点を強調したかったからである。
もちろん、ソフトウェアのコンセプトを考えるときなどは、
むしろ、「はまる」ことの連続だし、それが健全な姿だろう。
が、ひとたび作るべきものが見えてくれば、そこから先の開発で
「はまる」時間は極力少なくすべきだし、上に書いたようなことを
気をつけながら開発を進めるように習慣をつけていけば、
頭の中で設計しながらサクサクとソースを書く、という感じで
プログラムが書けるようになってくるものだ。
■ 関連エントリ
・プログラマー面接時の技術的な質問事項(アプレッソ版)
・そして、ペアプログラミングが始まる
・ソースコードのコメント率は20%を切ることが望ましい
アート・オブ・アジャイル デベロップメント
―組織を成功に導くエクストリームプログラミング
―組織を成功に導くエクストリームプログラミング
posted with amazlet at 09.05.16
James Shore Shane Warden
オライリージャパン
売り上げランキング: 15793
オライリージャパン
売り上げランキング: 15793
おすすめ度の平均:
現時点で最良のアジャイル解説本 アジャイルなやり方の具体的なガイド アジャイルのための練習曲集
コメント
コメント一覧 (11)
没頭するという意味の「はまる」で読みはじめてしまい、？？？状態でしたｗｗｗ
本当に時間が無い時は「とりあえず」コードをコミットせざるを得ない状況もかなりあるかと思います。
※優秀ではないたくさんのPGの場合
「とりあえず」コードはある意味さけられない問題だと思いますので、後でどうリファクタリングしていくか、など体制面をしっかりする事で「はまる」を避ける事ができるかもしれませんね。
> ないコードしかコミットしない」ことを守り続けることが重要である。
上の通りすがりさんと同意見です。
クラッシュに備えたソースコード保管の意味でも、終電間際など場面によっての「とりあえずコミット」はアリだと思います。
要は１カ所集中管理するから「人に見せても恥ずかしくないコードしかコミットしない」というスタンスになるのであって、その為の分散リポジトリだったりするわけです。
> 6. APIの存在を認知できていない
> 「僕は新しい言語を勉強するときは必ずAPIリファレンスにざっと目を通すよ」
本来のAPIの存在定義を誤解されてませんか？
APIというのは本来WindowsやUnix/Linuxのようなシステムの機能を呼び出すための窓口であって、特定のプログラム言語に依存するものではありません。
恐らくJavaAPIの事を指しての発言だと思いますが、最近よく聞くJava APIやらWeb APIという単語は後から「何か名前をつけよう」ってな事になって、元々あったAPIって単語に後からつけ加えた歴史的背景があります。つまりAPIの意味を拡大解釈しちゃったわけですね。
言語に依存する実装としてはクラスライブラリやライブラリがありますが、こちらと勘違いされてませんか？
例えばWindowsのAPIはVC++からも叩けるしVBやDelphiからだって叩けます。
公の場で「VC++のAPIを勉強したよ」なんて発言しようものなら赤面ものでしょう。
たしかに「API」より「クラスライブラリ」の方が適切ですね。
本文を修正しました。
そんなことは無かろうもん。
unix なら、システムコールかライブラリだもんね。
Leopardユーザー> 公の場で「VC++のAPIを勉強したよ」なんて発言しようものなら赤面ものでしょう。
その発言は恥ずかしいけど、初めて Windows3.1 を触るときには、ざっと API の一覧には目を通したけどな。
> unix なら、システムコールかライブラリだもんね。
ちなみに、そのシステムコールやライブラリの総称を「API」とも言います。
> 初めて Windows3.1 を触るときには、ざっと API の一覧には目を通したけどな。
だから「初めて」さわった時でしょ？
初めてWindowsでプログラムを勉強した時にセットで勉強するのはわかるけど、それ踏まえて
> 「僕は新しい言語を勉強するときは必ずAPIリファレンスにざっと目を通すよ」
この発言はブログ主が大学在学の頃の助手の方の発言なわけで、卒業時期から考えれば１０年程度昔の話になります。
今ならWebAPIみたいな派生ワードがあるけど、当時の時代背景を考えればこの発言に疑問を感じたわけですよ。
むしろWin3.1のプログラムをされてたのなら１０年前は貴方は既にプロのはず。僕よりも貴方のほうが疑問に感じるはずだと思いますが？
「【言語】の API 」ってところが恥ずかしい、ってことね。
納得、納得 :=)
本当に時間が無い時は「とりあえず」コードをコミットせざるを得ない状況もかなりあるかと思います。
※優秀ではないたくさんのPGの場合
「とりあえず」コードはある意味さけられない問題だと思いますので、後でどうリファクタリングしていくか、など体制面をしっかりする事で「はまる」を避ける事ができるかもしれませんね。
はまる(フロー状態)が長いほど開発効率が良いはなしが来ると思ってしまった。
ある正月、思いたって数式処理を4日で3万行に到達しそうなレベルの
コードを一気に書いた。
そこで、作った構文解析・操作系の部品を、後に、丸1年かけた案件に
流用したが、流用部分は、他の部分より複雑度が高いのにも関わらず
品質面、可読性の面で、他の部分より断然よかった経験があった。
自分でもなぜ、生産性が高く、出来も良い作業ができたのか不思議でしたが
あるとき、フローのはなしを聞いて、これかと思ったことがありました。
そのはなしと思ったけど、違った。
勘違い。
終了。