ハマらない、ミスしないフレームワークが生産性を上げる

驚くべき速度で高い品質のソフトウェアを作り上げるプログラマーには、
一つ共通の特徴があるように思える。
それは、「はまる」時間が極端に短い、ということである。

プログラマーの開発速度は「はまる」時間の長さで決まる - 小野和俊のブログ

激しく同意します。ここに列挙されてる項目も、ぜひ若手に読んでもらいたいです。

また、逆も真なりで、非常に開発スピードが遅く、品質も悪いソフトウェアを
作るプログラマは、「はまる時間が極端に長い」と言えると思います。

たとえば、新人など、新人などプログラミング経験の少ない人。
彼ら・彼女らのハマり方は、以下の3つに大別できます。

• そもそも目的が分かっていない
• 目的は理解しているが、どういうロジック（アルゴリズム）にすれば良いか分からない
• ロジックは考えられたが、それを実現する文法やAPIが分からない

さらに悪いことには、自分が上の3つのうち「どの状態であるか」を自覚できていないため
ぐるぐる回って、時間だけを無駄に費やしてしまいます。

そんな人には、上の3つのうちのどれなのかを聞いてあげれば
（あるいは、質問を繰り返して、どの状態であるかを導いてあげれば）
意外と、ハマり状態から抜け出すことも多かったりします。

また、フレームワークを使う時も同様です。
ある程度の経験がある人でも、初めてフレームワークを利用する時には悩むでしょう。

• 目的を実現するための、文法やAPI、あるいはCoCなどに代表される、黒魔術が分からない
• そのフレームワークでの、お作法が分からない
• ミスした時に、原因がさっぱり分からない

こうしたハマり時間を、極力少なくすることが、
生産性を向上させる（あるいは低下させない）ために必須だと思います。

なので最近は、

• アンチ黒魔術。脱CoCで、しっかりと書かせる
• フレームワークは極力薄くする
• サンプルは豊富に作る
• エラーメッセージで丁寧に教える

こういう風に改善されてきているのだと思います。

「記述量が減る」とか、「自動生成できる」とかは
実はあんまり生産性に寄与せず、
ハマらない、ミスしない（ミスしたらすぐに気づける）ことが、
何よりも重要だと思います。