驚くべき速度で高い品質のソフトウェアを作り上げるプログラマーには、
プログラマーの開発速度は「はまる」時間の長さで決まる
一つ共通の特徴があるように思える。
それは、「はまる」時間が極端に短い、ということである。
「記述量が減る」とか、「自動生成できる」とかは
ハマらない、ミスしないフレームワークが生産性を上げる
実はあんまり生産性に寄与せず、
ハマらない、ミスしない（ミスしたらすぐに気づける）ことが、
何よりも重要だと思います。
はまらないようにする事が大きく生産性を上げることについては、私も激しく同意します。
トルクモリモリのエンジンでも、エンストしたら元も子もないですからね。
私はこれに加えて、「手返しの速度」もかなり重要だと思っています。
「手返し」とは釣りの用語で、
餌を針に付ける⇒仕掛けを投入⇒アタリ待ち⇒仕掛けを回収 と言う一連の動作の事を言う。
手返し
という意味で、いわゆる反復作業の事です。
釣りの場合、このサイクルが速い人ほどよく釣れます。
エンジンで言うと、この速度は回転数に該当すると思います。
プログラマーで言う手返しはいろいろありますが、わかりやすいのは「コーディング->コンパイル->実行」かと思います。
「デバッグ->テスト->チケット登録」みたいなのもありますし、「リポジトリと同期化->マージ->コミット」という手返しもあります。
これら手返しは、1回の手返しでかかる時間が地味に蓄積されて行き、結果として大きな差として出てきます。
なので私は手返しを早くしようと思っていますが、心がけていることを上げると、次のような感じになります。
コードアシストを多用する
コードアシストは本当に有効なツールなので、積極的に使います。
スペルミスも減りますし、リズムに乗れますし。最近は変数名まで出してくれますしね。
コードアシストを使う場合、出てくる候補が少ないほうがよいので、フレームワークを選ぶ場合、
コードアシスタビリティも1つの選択肢になるのかと思います。
（クラスやメソッドが特定のプレフィックスで始まっている、とか）
テスト・デバッグ用機能を作る
例えばログイン後でないと実行できない画面の場合、ログイン画面を飛ばせる「ダミーログインフィルター」みたいなものを
作るとか、入力->結果の流れで結果だけデバックしたい場合にいきなり結果画面が出せるショートカットボタンを作るとか。
最終的に正常な流れでテストすればいいので、テスト・デバック時の手返しを早くする機能を検討します。
単体で再現する環境を作る
例えば既に動いているチャートやデータグリッドなどにちょっと手を加える様な場合、そのチャートが動いている画面を使って
機能追加をしようとして、効率が悪いケースがあります。例えばデータを入力しないとチャートが動かない画面で、毎回データを手入力しちゃうとか。
画面操作に慣れてしまうと毎回手間がかかることを無意識にやってしまうからだと思います。
そういう場合は画面に見切りをつけて、単体で開発できるものを用意して、作りたいところを集中的に実行できるようにします。
仮想環境を使う
VirtualPCやVirtualBoxなどを使って、テスト用の仮想環境を複数持ちます。
仮想OSは容易に複製・ロールバックできるため、環境がクリーンでないと出来ないテストの場合には相当手返しが早くなります。
また壊してもすぐ戻せるという勢いでテストができるので、心理的にも楽です。
ハードウェア性能を上げる
身も蓋もないですが、最近はマシンもディスプレイも安価になってきたので、十分費用対効果は出るでしょう。
ディスプレイは極力大きいほうがいいですね。仕様書とコードを横に並べられると、かなり手返しがよくなります。
ディスプレイは、1つの大きいディスプレイよりも、2つのディスプレイのほうがおすすめです。
ウィンドウを最大化した時、ディスプレイ1つだと全画面に張り付いてしまうからです。2つだと、片方だけに最大化されるので便利です。
あと個人的にはワイドタイプのディスプレイはお勧めしません。大抵のワイドタイプは縦方向の解像度が少ないからです。
マシンについては、最近のCPUは高性能なので、同じ予算ならディスクにお金をかけたほうがよいと思います。
こういった手返しの効率の悪さは、自分だけでやっていると気がつかない事も多いですが、横から見ていると割と気がつくことも多いです。
なのでペアコーディングまで行かなくとも、チームメンバーの開発している姿を観察するのもお互い勉強になるともいます。
11000回転まできっちり回せるようになりたいですね。
