我流コーディング術、あえて名付けるのなら、失敗駆動開発術
隣の席に座っていた若手のプログラマに「コーディングしてる時、何を考えてますか？」と質問されたことがあります。しばらく考えてみた結果、出た答えは「5行先に書く予定のコード……かな？」でした。何故そんな質問をしたのか訊いたところ、他のプログラマは手を止めて考え込んでいる時間が結構あるのに、わたしはのべつまくなしにキーボードを叩いているので、「なんでこの人、手が止まらないんだろう」と不思議に思った、と言われました。
わたしはコードをタイプしはじめたらほとんど手を止めません。考え事は手を動かしながらやります。
とにかくずんずん進みます。「ここ、どう書けばいいのかなあ」と迷うことも多々ありますけど、手は止めません。どんだけへっぽこなロジックでも、どんだけださい変数名でも、とにかく打ちます。もっといい手がありそうな気がする時でも、その場でそれしか思い浮かばないのならそそまま書いてしまいます。なんにも思いつかない部分はすっとばします。調べなきゃいけないことが発生した場合、簡単に答えがみつかりそうなことは調べますけど、ちょっと時間がかかりそうな時はやはりすっとばします。
コードを先に先にと進めながら、迷っていた部分についての解を探します。解がみつかったら、引き返して、迷って書いた部分を修正します。
そんな感じで、主に5行先のコードを考えつつ、書いたコードを検証しつつ、迷ってる部分の解を探しつつ、変数等のネーミングの妥当性に悩みつつ、全体のロジックに穴がないかを検討しつつ、ひたすらキーボードを叩き続けます。めちゃくちゃ忙しいです。
そんな荒っぽい書き方をしているので、最初のうちはかなりボロボロなコードになっていたりするんですが、気にせず突き進みます。まあ、人にはみせないようにしますけど（笑）。
打つ手が完全に途絶えることもあります。その時は、わざわざ遠くの自販機までジュースを買いに行くとかして、取りあえず歩きます。それも、若干スピード速めで。指のかわりに足をしゃきしゃき動かしていると、打つ手がひらめいたりするんです。
そうやってノンストップでコードを打ち続けていると、定時になるころには集中力が燃え尽きているので、さっさと帰ります。この燃え尽きっぷりがなかなかに悲惨なので、大抵のリーダーはつきあいはじめて1カ月もすると、気安く残業を頼んでこなくなります（苦笑）。
ちなみにわたしは基本的に8時間睡眠です。とにかくやたらとよく寝る人です。
朝イチの時間帯は、前日に「あとで調べておこう」と思っていたことを調べたり、迷っていた部分のコードを見直します。一晩、寝ると、何かが整理されるものらしく、調べものにしてもある程度、的が絞れるようになるし、前日にはこんがらがっていたものがすっきりしてみえたりするのです。
ここらへんの時間帯は比較的、のんびりめに行動してますね。コーヒーを飲みながら、ゆっくりと考えます。
そうやって、前日分の宿題を片付け、仕様書を再確認し、コード全体を大ざっぱに読み返し頭の中でロジックを再調整したら、また定時になるまでひたすらキーボードを叩き続ける、というのがわたしの基本的なコーディングのすすめかたです。
そんな様子が周囲の人たちには異常行動（笑）にみえるようなんですが、わたしだって最初っからこんなやり方をしていたわけではありません。
昔、リーダーに「一を聞いて十を知る、って言葉があるけど、おまえの場合、十まで納得しないと一から動き出さないな」と言われたことがあって、その時は「そういう性格なんだから仕方ないじゃない。ちゃんと締め切りは守れてるし問題ない」という考えだったんですけど、何年かたってから「このままじゃダメな気がする」というふうに変化したんですね。
全部、納得できたところから動き始めようとすると、どうしてもスタートに時間がかかってしまいます。スケジュールに余裕がある時はいいんですけど、短納期の場合、出遅れ分を取り戻すのは大変です。「これからは短納期の仕事が増えていきそうだし、このままだとプログラマとして食べていくのはむずかしいんじゃないか？」と考えた結果、「一しか分からないんなら、一だけで動き出そう。材料がそろわないとかぜいたくいってる場合じゃない。とにかくなんでもかんでも試してみて、そこから納得できる材料をみつけだそう」と決めたんです。
「失敗しても気にしないようにする」と自分に言い聞かせても、エラーが大量発生するとヘコんでしまって、「やっぱりもうちょっとじっくり考えてから……」という気持ちがどうしても出てきます。そんな感情をふっきるために、とにかく悩む時間を自分に与えないようにしないと、と思って、「手を止めないこと」を意識しながら、キーボードを叩きつづけました。
そういったことをなかば意地になって続けているうちに、失敗作をつくらないように注意深くやっているよりも、失敗作をつくりまくってる方が楽しいと感じるようになりました。
どれだけ失敗を重ねても、1つの成功さえ生まれれば、すべて帳消しになります。というか、「ふっふっふっ、ついにゴールにたどりついてやったぜ」的な達成感が上乗せされます。いつしか「また失敗した……」というネガティブ思考が、「NGパターン発見！ 1つ賢くなった！」というポジティブ思考にすりかわっていました。われながら単純です（笑）。
結果として、やり方を変えてから、仕事のスピードもあがりましたし、集中しやすくなったせいかバグもかなり減りました。なによりコーディングをするのが楽しくなりました。
というわけなので、タイトルに書いた「失敗駆動」というのは「失敗を糧にして前に進む」ではなく「失敗を楽しみととらえて、それをエネルギーに走り回っていれば、いつかはゴールにたどりつくさ」という意味だったりします（←なんか変態さんっぽいぞ！）。まあ、仕事でやっているんですから、当然、しめきりまでにゴールにたどりつく、というのは必須条件なので「いつか」ではマズいんですけど（苦笑）。
ソフト屋さんでよかった、と思うのは失敗が自分の中でおさまっているうちはほとんどコストがかからないことですね。ハード屋さんだと材料費とかいろいろありますから。
ところでこのやり方、一歩間違えると、同じところをぐるぐるしてるだけの永久ループ状態になってしまいます。失敗は許容しても、同じ失敗を繰り返すことは許さないように、自分を戒めつつ、キーボードを叩き続ける毎日です。
コメント
インドリ
そのやり方はテスト駆動型開発の流れをくむものだと思います。
私も頭の中で常に分析・設計・実装・テスト・運営・保守を並行処理しています。
分析している時でも実装している自分が並行して存在しているので、ユーザーとの会話の段階で全てが見通せて便利です。
情報システムに於いて実装できないものは無価値。
情報システムは常に実装も考えていないと駄目です。
ですから至極まっとうな開発法だと思います。
ひでみ
こんばんわです。ひでみです。
インドリさん。
> そのやり方はテスト駆動型開発の流れをくむものだと思います。
ほわ～。そうなんですか～。
なんとなくやりやすかったとか、こうやったらうまくいった、というのを適当に寄せ集めて淘汰していった結果が今のやり方なので、あんまりちゃんと理論立てて考えてはいなかったですね。
いろいろなことを並行して考えた方が、全体的にまとまりがいいというか、考えに偏りが少なくなるような気がします。
集中力が落ちると全部が一気に崩れ落ちるのが難点ですけどね（苦笑）。
> そのやり方はテスト駆動型開発の流れをくむものだと思います。
...そぉ?
「ちゃんとできたか検証する手立て(=テスト)を最初に仕込んでおく」
のがテスト駆動開発ですよね。
だとするとヒデミ流コーディングでテストに相当するものは何なんでしょ?
インドリ
ひでみさんは「成功するまで打ち続けている」というのですから、少なくとも頭の中には判断基準となるテストが存在する筈です。
明記されていませんが、下手すればユニットテストを用意しているかもしれません。
そもそも私はテスト駆動型開発そのものだとは言っていません。
ケント・ベック氏の開発思想に似ているから「流れを汲む」と表現しています。
上辺だけの事ではなく思想面まで含めて考える必要があります。
xUnitを使用しているからテスト駆動型開発なのではありません。
xUnitを使用するのはあくまでも手段です。
「動かない書類ではなくプログラムを生産する」ケント・ベック氏の考えをどこまで体現しているのかが大事なのです。
それはさておき、重要な事を忘れていたので書きます。
こういったコーディング術は弱点があるので注意して下さい。
弱点とは「大局を見渡せない傾向がある」事です。
設計に不備がある場合でもロジックの一部に頭を悩ませてしまう可能性があります。
その辺に注意すれば生産性がアップする合理的なプログラミング術です。
> ひでみさんは「成功するまで打ち続けている」というのですから、
> 少なくとも頭の中には判断基準となるテストが存在する筈です。
うまくいったときをイメージせずに/判断基準を持たずにコード書き続ける
阿呆はおらんでしょう。少なくともプロには。
それをもってしてテスト駆動開発の流れを汲むとするなら誰だってそうだね。
僕はどうだろう...ひたすらキーボードを叩き続ける感じじゃなさそう。
十数行先に着地点を(ここまでくればこうなってるハズ)を脳内に据え、
そこに向かってコードを書き、手を休めて(あるいは変数名とかのお掃除をしつつ)
次の着地点を想定する...を繰り返してますね。
インドリ
ひでみさんのコーディング術のポイントは「手を休めない」です。
リファクタリングを繰り返すプログラミングをし続けています。
人間はフロー状態になるのに時間がかかります。
「手を休めない」状態ならばフロー状態になりやすく、自然と生産性が上がります。
継続的インテグレーションにつながるひでみさんの考え方はケント・ベック氏と酷似しています。
ケント・べック氏と似た言葉が随所に見られますし、全体として似ていると判断しました。
長年プログラマをしていると似てくるのでしょう。
インドリ
もしかして、テスト駆動型開発は「正しいテストだけ」をあらかじめ設計していると思っているのかな？
ここから認識のずれがあるのかもしれませんね。
ケント・ベック氏が提唱しているのは、「とにかく動くコードを打て」で失敗を恐れずに正しいと思うプログラムを打ち続けるという考えがベースとなっています。
ですから、テスト駆動型開発のテストもまたリファクタリングするのが普通です。
失敗を恐れずに打ち続ける姿勢がそっくりなのです。
>「手を休めない」状態ならばフロー状態になりやすく、自然と生産性が上がります。
それは人それぞれちゃうかなー。
僕は一旦立ち止まって見渡したほうがやりやすい。
> 失敗を恐れずに正しいと思うプログラムを打ち続けるという考えがベースとなっています。
TDDのキモは「失敗を恐れないためにテストを準備しとけ」でしょ。
根拠のない自信はただの「驕り」あるいは「蛮勇」だわ。
# 議論はここまでにしとく。キリがなさそうだ。
インドリ
やはりよくわかっておられない。
ケント・べック氏の根源にあるのは「ゴールに向かってプログラミング」です。
そのゴールへ向かう道は、「トライしてみて上手くいかなかったら修正すればいい」というものです。
そして、テスト駆動型開発の源流は「プログラマならばだれでもするチェックプログラム」です。
プロならばアサーションやprintfデバッグなどと言ったチェックプログラムは当然書きます。
そのプログラムをユニットテストとして切り出したのが一種の進歩だったのです。
「テストそのものも試行錯誤で打つもの」だという思想をご存じないからテスト駆動型開発とひでみさんのコーディング術が結びつかないのでしょう。
仮にひでみさんが「テストするプログラムも休まず打つ」ならば殆ど同じだと言ってもよいぐらいです。
なにはともあれ、個人が抱いた感想にケチをつけるのは止めて頂きたいです。
ひでみ
こんばんわです。ひでみです。
επιστημηさん。
> それは人それぞれちゃうかなー。
> 僕は一旦立ち止まって見渡したほうがやりやすい。
人それぞれで、向き不向きというものは確実にありますね。
私の場合は子供の頃から集中の持続力だけは自信があったので、今のやり方が楽なんですよ。
ですので自然と、自分の性質に合ったやり方を選んだだけなんだと思います。
インドリ
何を言いたいのか分かりません。
何のためにしつこく食い下がっているのか理解できません。
ひでみさんのコーディング術がケント・べック氏の流儀と似ていて困る事があるのでしょうか？
それに加え、20年を超えるベテランプログラマを、勝手に蛮勇呼ばわりするのは如何なものでしょうか。
テストプログラムをプログラミングをしていないと明言していない以上、ひでみさんのキャリアも考慮してテストプログラムもプログラミングしていると考えるのが妥当でしょう。
「xUnitぐらい使っているけど」という可能性も大です。
他人を勝手に卑下するのは貴方自身も貶める行為です。
恥ずかしい行為だから止めた方がよろしいかと思います。
>> 僕は一旦立ち止まって見渡したほうがやりやすい。
> 人それぞれで、向き不向きというものは確実にありますね。
ですね。
僕は「のめりこむ」タチなので意識的にブレークしないと
「いぢりだしたらキリがなくなる」恐れがありまして^^;
それもあって敢えてキーボードの前から遠ざかり、紙とエンピツで
コーディングすることもしばしばです。方針のきまらんうちは特に。
ジェットマグロ
全くの無から有を作り出すよりも、何か「プロトタイプ」「叩き台」とでもいうべきものがあって、それを見てあちこち直しながら作った方が楽な場合が多いと思います。
ひでみさんは全くの無から、まず叩き台を（自分で）作り、それを後で（自分で）修正する、という手順を取っているのかなぁと感じました。
ひでみ
こんばんわです。ひでみです。
ジェットマグロさん。
> まず叩き台を（自分で）作り、それを後で（自分で）修正する、という手順を取っている
そうですね。そんなイメージです。
同じところに何度も手をいれることを「手戻り」とみるむきもあるかもしれませんが、スタート地点から動かない人は戻ることさえできませんからね。
でもまあ、本音をいえば、最初っから最短距離を探り当てられる人になりたいです。
セロ
動かなければ「失敗することもできない」な～と。
自分が書いているコードに「求められているもの」は見失わないようにしないとな～。
最短距離には地雷が埋まってたり。
時限式だったりした日には目も当てられませぬ。
インドリ
常に動き回るのと同時に、最短距離を探ろうとする姿勢は大事ですね。
ひでみさんの言葉に高いプロ意識を感じました。
仲澤＠失業者
失敗駆動ですかっ。
現在のデジタル系チップは書き直しができるので、似たようなこともできるの
ですが、大昔は、失敗は部品の破損に直結している場合が大半で、手戻りの
影響がでかすぎておおめだまをくらいましたね(笑)。ハードやってた頃は。
その影響でソフト屋になりたての頃は非常に慎重に一文字一文字書いてました。
その後、コンパイラが優秀になったり型のチェックが厳密になったりしたせい
なのか、てけと～に書いたコードをとりあえずコンパイルして表示されたエラー
を修正ってのがパターンになりました。
ちなみに20数年プログラマやってますけど、いまだにブラインドタッチが
できません(きっぱり)。最近は老眼が追い討ちをかけてきたので、キーを
打つのがさらにおっくぅ～になっちゃいました。まぁコードの自動生成
もできるし、マウスとショートカットキーで、だいたいいけちゃったりするんで、
キーを見なくてすむのはまことに具合がよろしい(vv;)。
てなわけで、最近はキーボードも頭もあんまり使ってないので、失敗も
あんまりしません。そのうちに「じじぃ。いつコード書いてんだよっ」
なんて聞かれる日がくるかもしれませんねぇ。
「若造。おみぁさんにゃむりぢゃ。老人力を使うんじゃよ。ふぇっふぇっ」
老人力駆動・・・う～む。
ひでみ
こんばんわです。ひでみです。
仲澤＠失業者さん。
ハード屋さんは失敗すると痛いですよねえ。
私がハード屋さんだったら、「失敗駆動」なんてこわくて言えないと思います（苦笑）。
私は普段はブラインドタッチはできないんですけど、コードをひたすら打ってる状態の時はできているようです。
「ようです」というのは自覚がないからなんですけど、なんかできてるような気がします（←自分のことなのにあやふや）。