ソースコードって実際のところどういうふうに書いていますか？

私はプログラミングは結構自信があるんですが、他の人の作業をつぶさに観察したことがあるわけでもないので、自分で当たり前だと思っているコーディングの方法が他の人にとってはそうではないこともあると思ってます。上手い人がどういうふうにしてプログラムを書いているのか知りたいんですよね。

逆に私はどういうふうに書いているかちょっとまとめてみました。自分はこうしている、というのがあったらぜひ教えてください。

まず私の場合、ゼロからコードを書くよりも現在のプロジェクトのためのコードを書くことのほうが多いので、コードを書くというのは既存のコードに変更を加えることがほとんどです。既存のコードに手を加えるときは、新機能追加か、リファクタリング（動作は変えずにコードをきれいにすること）のどちらかになるわけですが、まず前者をどうしているかどうかをできるだけ説明してみます。

まず必要なのは考えることです。よく知っているコードの上で作業するわけなので、頭のなかで構想を立てることができます。簡単な機能はほとんど考えずに実装できますが、ある程度複雑な機能は複数の箇所を触ることになるので、「AをBのように変更して、CをDのようにすればうまくいくはずだ」といった構想を練ります。わかっているものの上で作業するので、本当に難しい問題以外はよく考えれば方針はすぐに決まります。

それから実際にコーディングにとりかかるわけですが、ここで非常に気をつけているのは、できる限りコードを正常動作する状態に保つことです。大きな変更を一気にやろうとするとわけがわからなくなるので、できるかぎり小さな変更を積み重ねていくことで最終的に構想通りの変更を行うようにしています。コードを書いている途中、コンパイルしてユニットテストが通せるまでは、危ない橋の上を歩いているような気分で、なるべく早く安定した状態に戻したいという気持ちがあります。

私の場合、きちんと計ってみたことはないですが、数行といったレベルごとにコンパイルとユニットテスト実行（スクリプト言語なら実行）をしていると思います。

小さい変更を積み重ねて大きな変更を行うにはある程度の慣れが必要でしょう。自分では無意識のうちにやっているのでどうやっているのか説明しにくいですが、いくつか私が気をつけていることを挙げてみます。

まずは直線的にゴールに向かうコード以外もよしとすること。小さな変更でもきちんと動くようにするには、最終的な結果には残らないコードを書く必要がありますが、それは躊躇せずにどんどん書いています。なるべく何も壊さずにインクリメンタルにゴールまでたどり着くのが目的で、途中のコード量を削減することは特に目的ではありません。

二つ目のコツはきちんとコンパイルできるところでコミットしておくこと。Gitのようなバージョン管理システムを使っていれば、こつこつコミットして、最後に1つのコミットにまとめることができるので、小さい単位でコミットしても特に失うことはありません。よくわからなくなったら前の段階からやり直せるので便利です。もしコミットしていなかったら全体がやり直しになってしまいます。

最後に、わけがわからなくなったら全部を捨ててやり直すこと。これは私もよいことなのかどうかはわからないのですが、私はある程度苦戦したらパッチ全体を捨てて元の状態からやり直しています。最初に構想を立ててコードを書いているわけですが、「AをBにすればいいと思っていたがAという前提は間違いだった」という状況がでてきます。それをその場で修正しようとしても、CもDも構想にうまく当てはまらなかった、というようになってくると、一度に必要な変更点が多すぎて手に負えなくなります。その時はバッサリ全部の変更を捨てて、もう一度考えるところからやり直しています。

まったく同じことを何度か試みると数回目にはきれいにコードが書けたりするので不思議です。いまでもどうしてそうなるのかはわからないのですが、諦めてやり直したほうが早いことはとても頻繁にあります。

リファクタリングのやり方も同じですね。一つのクラスや関数を変更するとそれを呼び出している箇所を全部変更したりしないといけなくなりますが、互換レイヤ（というと大げさですがただ古いものと新しいものをブリッジするクラスとか関数）を適当に作って、全体を一気に変更しなくても、一つ一つ変更していけるようにしています。最後にブリッジを削除して完成になるので本当にそれは工事現場の足組みと同じです。

と、こんなふうに作業しているわけですが、こういう最終結果に現れないものというのはソースコードをみても学べないので他の人がどうやって作業しているのかはいまだによくわかりません。みなさん、どうやっているんでしょうか？ ぜひ教えてください。