クリアコードはもともとフリーソフトウェアの開発に関わってきたメンバーで設立した会社で、フリーソフトウェアの開発で学んだことを活かしてソフトウェアを開発しています。クリアコードで実践しているソフトウェアの開発方法をクリアコードの開発スタイルと呼んでいます。単にコードを書くことだけではなく、ソフトウェアの開発に付随するコードを書く以外のことも含んでいます。

普段は意識せずにやっていることなのですべてを網羅できているわけではありませんが、説明できる分だけクリアコードの開発スタイルを紹介します。説明できるものが増えたら順次追加していきます。

問題を見つけたらupstreamで直す

ソフトウェアを本当に一から作ることはありません。既存のツールやライブラリを利用して開発します。Emacsやgeditなどのエディターを使いますし、GCCやRubyなどの言語処理系も使います。WebアプリケーションならFirefoxやWebKitをレンダリングエンジンとしたWebブラウザーで動作を確認します。

ソフトウェアを開発していると既存のソフトウェアの問題にぶつかることがあります。そんなときあなたならどうしますか？既存のソフトウェアの開発元に問題を報告するかもしれません。自分が開発しているソフトウェア内で問題を回避するかもしれません。

クリアコードの開発スタイルは「既存のソフトウェアの開発元に問題を報告し、可能なら問題を修正するパッチを添える」です。ソフトウェアの開発元のことをupstream（アップストリーム）と呼ぶこともあるため、「upstreamで直す」と呼ぶこともあります。

例えば、Rubyに問題があったときはRuby本体に問題を修正するパッチ付きで問題を報告しました。

自分が開発しているソフトウェア内で問題を回避する方法の方が、問題にかける時間は少なくて済むでしょう。その分、自分が開発しているソフトウェアの開発に時間をかけることもできます。

それでも、クリアコードの開発スタイルでは既存のソフトウェアを修正する方向でどうにかできないかを考えます。なぜなら既存のソフトウェアで問題が修正された方がうれしい人が多いからです。同じ問題にぶつかる人を少なくしたいのです。

開発元で問題を修正しようということは、フリーソフトウェアの開発では日常的に行われていることです。クリアコードの開発スタイルでもそれを実践しています。

開発を続けられるコードを書く

使いたくなるフリーソフトウェアの多くは一度リリースしたらそれで終わりではなく、利用者からのフィードバックを受けながら改良・修正・リリースを繰り返します。そのようにして、利用価値のあるソフトウェアを作っていきます。

作って終わりのソフトウェアと、開発を続けられるソフトウェアでは作り方が違います。作って終わりのソフトウェアは、後で読めなくなるコードでも手早く動くものになるなら問題ありません。しかし、開発を続けられるソフトウェアでは、そのようなコードは問題です。まず、改良・修正することが難しくなります。これは、前に書いたコードがどのような意図で書かれたものなのかを読み取ることが難しいからです。あまりにひどいともう読みたくないコードになってしまいます。こうなると開発は続けられません。

クリアコードの開発スタイルではソフトウェアの開発を続けられるコードを書きます。どういうコードかというとリーダブルなコードです。つまり、他の人が見たときに理解しやすいコードです。具体的には、統一感のあるコード、わかりやすい名前を使ったコード、意図が伝わるコードです。

コードの動作確認を自動化するために自動テストも書きます。たとえ理解しやすくても、変更の影響範囲がわからなくて変更をするのが怖くなるようでは改良・修正することが難しくなります。自動テストを作成し、誰でもテストを実行できるようにすることで、改良・修正をしながら開発を続けられます。

相手が想像しなくてもわかるように説明する

複数の人で1つのフリーソフトウェアを開発する場合、地理的に離れていることが多くあります。国が違うことだってありますし、時差が大きいこともあります。一度も直接会ったことがないまま開発を進めていくこともあります。

開発をしながら開発者同士でやりとりしたいことがいろいろあります。このAPIはどうしよう、新しくこんなクールな機能を追加したいんだけどどう思う？などです。直接会ってやりとりできる場合は相手の表情などを見て、相手がどう感じているかを察しながら相談することもできますが、時差などで直接会えない場合は難しいです。そうすると、チャットやメール、チケットへのコメントなど非同期でできるテキスト情報でのやりとりが主なやりとりの手段になります。もちろん、必要に応じて文書だけではなくパッチやスクリーンショットなども使います。自然言語でのテキスト情報だけに制限されているわけではありません。しかし、相手の表情などがわからないため、話しながらフィードバックをもらってさらに話を進める、ということはできません。

このように、すぐに相手の反応をもらえない状態で説明をする場合、情報が抜けていると読む人はそこを補いながら読む必要があります。読む人が補ってくれた情報が自分の考えていることと同じであれば問題ありませんが、違った場合は説明が伝わりません。そうすると、読んだ人が不足している情報を聞いたり再度説明をお願いしたりするなど、やりとりが増えます。やりとりが増えても、伝わるのであればよいですが伝えきれない場合もあります。そうすると開発を進めていく上で支障がでてしまいます。

クリアコードの開発スタイルでは、できるだけスムーズに考えていることをちゃんと伝えられるように「相手が読んだらどう思うだろうか」ということを考えてやりとりをします。例えば、相手が知らない言葉には説明をつける、要求をするときは省略せずに理由もちゃんと説明するなどです。相手が想像しなくても説明が伝わるようにします。

コードを書くときは、読んだ人にちゃんと意図が伝わるかを考えながらコードを書きますが、やりとりをするときも読んだ人にちゃんと意図が伝わるかを考えながら説明するということです。

楽しく開発する

フリーソフトウェアを開発するモチベーションは人それぞれいろいろあります。プログラミングそれ自体が楽しい、新しい機能ができると嬉しい、開発したものを喜んで使ってくれるユーザーがいて嬉しい、その分野で自由に使えるソフトウェアがないから、などです。フリーソフトウェアの開発において、開発者自身が楽しいとか嬉しいと感じることはとても大事なことです。楽しいことがモチベーションだった開発者は、楽しいと感じられなくなるとそのソフトウェアの開発から手を引きます。手を引いた開発者はまた別のソフトウェアを楽しく開発するかもしれません。ある開発者が手を引いたソフトウェアでも、別の開発者が参加して楽しく開発することがあります。

クリアコードの開発スタイルでも、楽しく開発することを大事にします。

まず、開発者自身が楽しく開発することを意識します。つまらないと思っていれば何でもつまらないと感じてしまいます。プログラミングは楽しいはずなので、なにかしら楽しく開発する方法を考えます。クリアコードのメンバーも一緒に相談にのります。

もう少し具体例を考えてみましょう。

もう見たくないコードは書きません。いくらプログラミングが楽しくても、汚いコードに触れ続けるとつらくなります。そうならないように、日頃からクリアなコードを書きます。

健康を大事にします。睡眠時間など仕事以外の時間を削って書いたコードは雑になりやすく、また、開発それ自体をツライものに感じます。残業をしませんし、そもそも残業を前提として開発を進めません。

困ったときに相談にのります。開発していると悩むことはたくさんあります。コードを書いていればよい名前に悩みますし、いくつかの技術を検討しているときどの視点で比較するかに悩みます。困ったときに他のメンバーに相談すれば一緒に考えてくれますし、他のメンバーから相談されれば一緒に考えます。

他の人のコードを読みます。1人でソフトウェアを開発しているとなんとなくつまらなくなってしまうことがあります。複数人で開発していると他の人のコミットが刺激になりますが、1人だとそれがないからかもしれません。クリアコードでは担当しているかどうかに関わらず、すべてのプロジェクトのコミットがdiff付きで開発者全員に送られます。コミットを見て、気になることがあればプロジェクトに関係なくコメントします。これにより、たとえ1人のプロジェクトでも複数人で開発しているときのように刺激を受けつつ開発できます。