手を動かしながら短期間で一気に開発したら、知らぬ間にゴミソースができたって話です。

きっかけ

4ヶ月くらい前に短期間でがーっとTracチケット管理ツールを作り、実際に運用して数か月たっていました。
チケット管理ツールとしてはある程度やりたいことができているので問題なかったのですが、メイン画面の表示が遅いなーとちょっと気になっていました。
久しぶりの個人開発だったし短期間で作っちゃったからソース汚かったしな、ちょうどこの3連休予定ないしちょっと直すかー、と思ってソースを見直してみました。

すると…

そこには想像をはるかに超えたゴミソースがあったのでした。。。（思い出したくもない）

なぜゴミソースができたのか？

設計をあまり詰めずに開発に着手してしまった
そもそもがっつり1からの開発が久しぶりだった
とりあえずいったん動くこと（メイン画面が表示される）を目標に開発をすすめた
いったん動いたところから少しずつ機能を足していった
開発してバグを出しながらあーでもないこーでもないとその場しのぎで動くように改変を続けた

その結果。。

とりあえず動くがメソッド名はかなりてきとう
同じような名前のメソッドが乱立（Get〇〇Data、Get〇〇List、…みたいな）
類似メソッドなのに戻り値が違う、複数のメソッド分の働きをさせているなどメソッドの粒度がばらつく
知識不足・勘違いによる謎コードが多々あった
とにかく可読性・保守性が低い

しかもたちが悪いのは、パット見ただけではなんとなくうまくかけていた（と思っていた）ため、いまのいままでソースが汚いことに気づかなかったことでした。（これは単純に頭悪い）

どうすれば最初からうまく書けたのか

コードレビューを受ける

普段から自分のソースを客観的に判断してもらうことが大切だと思います。
私自身はお恥ずかしながら転職するまでまともなコードレビューを受けたことがなく(転職は2月)、、、数か月前はなんとなく自分はうまく書けているという思い込みがありました。。
今思うととんでもないソースを自信満々に書いていたなぁと思います。
最近コードレビューを受けるようになり、自分のソースの悪い癖や可読性や保守性における「あるべき」ソースを学びました。
本などで読んでわかっていたつもりになっていましたが、指摘を受けることであらためて気づくことも多かったです。
またレビューを受けるからにはちゃんと調べて書かないと、という緊張感があったため、知識が向上したこともあるかもしれません。

あとはとにかく経験する

自分で最初からうまく書くには、とにかく設計・開発・保守までをしっかりと通しで経験して身に着けるしかないなと思いました。
設計がうまくできていないと開発でその場しのぎの対応が増えますし、開発で保守性の低いコードを書くと保守で苦労するし、とすべての経験はつながっているからです。
いろいろな立場を経験することで視野がひろがり、「あるべき」ソースがだんだんとわかってくるのかもしれません。

つまり経験がない人はとにかく小さな開発をたくさんするとよい

ここからはちょっと経験が浅めの人に対するアドバイスです
いきなり完璧なものを作ろう！とすると設計からハードルが高く、また開発もうまくいかずにリファクタリングどころかリリースまでこぎつけられないこともあると思います。
車輪の再開発でも既存の製品の劣化版パクリでも何でもよいので、とりあえず何か開発して運用するまで行うことが第一歩だと思います。
そのあとでリファクタリングまでことで、自分の間違いやソースの悪い癖に気づけることがあります。
個人開発・個人運用ならだれにも迷惑かけずにリファクタリングまで実践経験できるので、おすすめです。

ちなみに

リファクタリングまで行うことを考えるのであれば、TDDで組んでおくとよいと思います（せめてあとからUnitTest組んでおく）（長く運用するものであればなおさら）（まぁ私の開発では組み込めていませんが…）

というのも、転職してから単体テストを組むようになって非常に恩恵を受けたからです。
とにかく単体テストが出来上がっているとリファクタリングがやりやすくていいです。
ちょっとこのソースいけるかな？と思って試したいときに、ちょっと変更して単体テストを通してみるだけで自信をもって確信できます。もちろん単体テストを作成するときはIN/OUTのパターンを網羅する必要があるので、時間はかかるし結構大変です。それでも、それに見合った効果はあったなーと思いました。
TDDはいろいろと賛否両論ありますし、複雑なプログラムには向いてなかったり…などありますが、悪くないなと思った次第です。

今日はそんなところです。