EarOwlの日記: コーディングの進め方について 2
日記 by
EarOwl
私の前に開発を担当していた人によると、そのソースコードは『後で直すつもりで雑な書き方のままの箇所が多く残っている』ということだったのですが、個人的にはこういうコーディングの進め方にはあまり賛同できない。
当初からきれいに書くことを意識していても、規模が大きくなるにつれて汚い部分が出てきてしまうことはままある。
まして最初から雑な書き方で進めていったら、後からの修正では雑な部分を取り除ききれなかったり、修正にかかる負担がかえって大きくなったりしてしまう。
さらに、とりあえず動作するコードを早急に書かなければならない場合でも、雑な分早く書くことが出来るかというと、あまりそうは思えない。むしろきれいに書くことを心がけた方が、見通しが良くなり早く完成させられるように思われる。
テストを作っているか否かによる (スコア:1)
きちんとテストでガードできていれば、TDD的アプローチとしては正しい。
もしそうでなけば、リファクタリング時に仕様を思い出すコストが高いと思われるので
最初からリファクタリングが無いようにきれいに書くべき。
発想をコードに落とし込んで、さらにきれいな構造に保つことはかなり消耗する。
余裕が無いときはちょっと無理。
個人的には、15分考えてきれいな構造をつくるより、動くコードを2分でコピペして
暇があるときにきれいにする方が好み。
どうしても最初は考慮漏れなんかが出てくるし、関数や変数の名前も最初からベストにたどり着けることは少ない。
もちろん、はじめから最終形で出力する方が満足度は高いので
趣味ならいくらでも時間をかけて考えちゃうけども。
綺麗に書いても早くコーディングできるわけではないが… (スコア:1)
綺麗に書くと、コーディングにかかる時間が伸びるというのは、嘘ではない。20%ぐらい伸びる。
でも、デバッグサイクル数が圧倒的に減るので、完成までの時間は圧倒的に短縮される。
例えば、私の記録は、1.2Mlineのプログラムを二ターン目でテストを通し(1ターン目でバグが4つ出た)、そのまま End Of Life までバグは増えなかった、というのがある。
汚いコーディングで 1.2Mline のプログラムを書いて、10ターン以内にテストを通せる人なんぞ、見たことがない。
そして、10ターンテストを回すと、1.2Mline なら大雑把にコーディングと同じぐらい時間がかかる。
そう考えると、プログラムを「リリースできる」までにかかる時間は、汚く書いた場合を100として、綺麗に書くと60で済む、ということだ。
それって、大雑把に言うと2週間かけてリリースするはずのコードを1週間と1日でリリースして、残り4日遊んで暮らせるってことだよね(後半に嘘が混じっております)。というわけで、私には「汚く書く」理由が判らない。
fjの教祖様