プログラミング技術さえ身に付けば、プログラマとして一人前と言えるでしょうか?プログラミングを始めたばかりのうちは、プログラミング言語の習得や周辺の知識を得ることばかりに目がいきがちですが、それだけでは一流のプログラマになれません。
(プログラミング言語を学びたいなら、まずこちら:写経で身につけるプログラミングの基本

プログラマとして成長するためには、プログラミング技術を学ぶだけではなく、良いソフトウェアを作るための良い習慣を身に付けることが大事になります。初心者のうちに良い習慣を身につけておけば、ただ知識を追い求めるのではなく地に足をつけた成長ができるはずです。

pka karate-pittsburgh-kids karate-kidz zone-class-sept 2011-17
pka karate-pittsburgh-kids karate-kidz zone-class-sept 2011-17 / PKA Karate

SonicGardenの教育事業では、たまに訪問する家庭教師的なスタイルではなく、教育対象の方に弊社のオフィスにフルタイムで来て頂いて、一緒に仕事をしながらOJTでペアプログラミングやコードレビューを通じて、身に付けてもらうというものです。そこで身に付けてもらうようにしている習慣を紹介します。これらは元々は私が先人たちから学んだことでもあります。

自分で書いたすべてのコードを説明できるようになれ

プログラミングは全て、明確な判断の結果です。if文を使うべきかどうか、どのAPIを使うのか、メソッドで切り出すかどうか、それらすべてロジックで作られていて、そのロジックを決めているのは、作っているプログラマの判断です。

プログラムの中で、曖昧なままに作っている部分があるとしたら、それは確実にバグの温床になります。作っている本人が「なぜこう書いたのか?」を説明できない部分というのは、本来あってはいけないのです。ましてや仕事で作っているプログラムで。

なので、学習を始めたばかりのプログラマたちには「自分の書いたすべてのソースコードについて説明できるようにしなさい」と指導するようにしています。プログラムのどの部分についても「なぜこう書いたのか?」を説明できる習慣を付けるのです。

原理や動作を理解しないまま、Googleで検索したサンプルコードや、他の誰かの書いたコードからコピー&ペーストして、何度かパラメータを変えてみたりして動いたらOK、なんていうプログラミングの悪習慣を身につけてしまってはいけません。

優秀なプログラマはたとえ動いたとしても「動いてよかった」なんて思わずに、その「なぜか動いている」という状態をとても気持ち悪いと思ってしまうのです。論理的でないことを嫌うのです。

プログラミングの世界では、DRY(Don't Repeat Yourself)という言葉があります。プログラム中に同じコードを繰り返し存在させてはいけないという考えかたです。すべてのコードを説明できる状態になれば、自然とDRYになっていきます。

SonicGardenのコードレビューでは「なぜこう書いたのか?」を確認します。大事なことは、プログラマが自分で判断した結果であることで、理由を言えることです。もしその理由が間違っているのであれば、正しく直せば成長の機会につながりますが、理由もいえないソースコードであれば、レビューする価値すらもありません。

プログラミングに取りかかる前にTODOリストを作れ

プログラミングを始めると、並列に作業が進むことはなくて、ひとつひとつ順番に作業をしていくことになります。その作っていく順序を、頭の中でシミュレーションして事前に把握しておくことが、できるプログラマの優れた習慣になります。

行き当たりばったりで作っていってしまうと、作業に漏れが発生することがありますし、どれくらい進んでいて、どれくらいかかりそうか、ということもわからなくなります。プログラムというのは、つくり方もロジカルであるべきなのです。

たとえベテランのプログラマであっても、順番に進む作業スピードが速いというだけで、進めていく内容に違いがあるわけではありません。その作っていく際の作業の順番、すなわちTODOリストが頭の中になければいけません。

なので、プログラミングを始めたばかりの人たちには「作業の前にTODOリストを作りなさい」と教えています。何をどういった順番で作って行くかというチェックリストです。作業が終わったかどうかのチェックを付けていきます。

もしTODOリストが作れないとしたら、やろうとしていることのゴールが明確でなかったり情報が足りなかったりしているということがわかります。

TODOリストは、特にツールを使う必要はなく、テキストエディタでも良いし、手元の紙でもいいのです。大事なことは、見えるようにすることです。見えるようにすることで、自分も迷うことがなくなるし、誰かに進捗を聞かれた時にもすぐに共有することが出来ます。

初心者のうちはなるべく細かく細かくTODOにする位でちょうど良いでしょう。最大でも一時間以内で終わるように刻むのです。終わるまでに一日以上かかるのはもはやTODOとは言えません。

最初、初級者のうちはTODOの粒度が小さくなってしまいますが、それが成長するにつれて大きな粒度でも扱えるようになります。この一歩の歩幅の大きさが成長の証です。

この歩幅が小さいうちは、何を作るにも大変かもしれません。プログラマとして成長するというのは、新しい知識を得るのではなく、この一歩の歩幅を大きくしていくことなのです。

わからないところを想像で補うのではなく話し合え

TODOリストを作る際や実際にプログラミングしている際に、ときには仕様でわからない点が出て来たりするはずです。そうしたときに、つい先に進めたいがために「きっとここはこういうことだろう」と決めつけて、先に進めてしまうことがあります。しかし、想像で作ったところは往々にして後から見直しが入ることが多いです。

仕様ではっきりしないところがあればどうするか、答えはシンプルで、わかる人に聞けば良いのです。SonicGardenではプロダクトオーナーという仕様に関する責任者がいますので、その人と改めて共有するしかありません。なるべく困ったときは「想像して決めつけずに話をしよう」と言っています。

プロダクトオーナーと話してみると、プロダクトオーナー自身もわかってなかったことや考慮出来てなかった点だったりして、そこからお互いに議論して正解の仕様をつくっていくことになることも多いです。

こうしたことを実現するためには、プロダクトオーナー側がいつでも質問を受け付けられる姿勢でいることと、素早いレスポンスが求められます。これはプロダクトオーナーにとってみると大変なことですが、もし本当に良いソフトウェアを作りたいなら、これくらいのことは必須条件になります。

仕様を把握する際のポイントは、ソフトウェアの動作を詳細に決めていくことも大事ですが、そもそものひとつひとつの要件の背景にある意図を把握することが大事になります。その機能がなぜ必要なのか、を知ることで、実現方法をプログラマから提案することができるようにもなります。

また、初心者のうちは、どうしても細かい動きまで確認してからでないと作れないことも多いのですが、一般的なソフトウェアの動作に関するコモンセンスを身につけていくことで、プロダクトオーナーやユーザのニーズの意図を汲み取るだけで、だいたいのことがプログラミングできるようになります。

「どうも難しい仕様だな」と思ったときに、そのまま頑張ってプログラミングして実現することに努力する前に、「もっとシンプルな仕様にできないか」と考えて、プロダクトオーナーにシンプルに実現できる仕様を提案することが出来るようなプログラマを目指したいところです。

皆さんの考える「プログラマが身につけたい良い習慣」があれば @kuranuki に教えて下さい。