【プログラミング・初心者向け】ボーイスカウト・ルール～触る前よりも綺麗なソースに～
綺麗ではないソースについて
ソースは、綺麗でシンプルなものの方がバグを生みにくいというお話は
前回で少し触れたと思います。
ですが、修正を重ねたり、期間の短い改修プロジェクトで修正をしたりすると
どうしても、コピペや適当な変数をつけがちで汚いソースが生まれてしまうものです。
※ここで言う汚いソースとは
※・何に使っているか推測しにくい変数名
※・無駄な変数宣言
※・余計なループ..etc
実際、僕もそういうことはしょっちゅうなのですが、
こないだ仕事場の方に以下のことをまたアドバイスされました。
「ボーイスカウト・ルールでいこう！！！」
ボーイスカウト・ルールってなんね（再度混乱）
例の如く調べました。
ボーイスカウト・ルール
上記サイトの
「8.ボーイスカウト・ルール」
がわかりやすいかと思うのでご紹介します。
触る前よりも綺麗なソースに
ボーイスカウトでは、キャンプ場や広場について、以下のルールで動いています。
来たときよりも、綺麗に！
自分たちで汚してしまったところだけでなく、来たときよりもより綺麗に。
次ぎ使う人が気持ちよく使えるようにする。
それをソースに置き換えるというわけですね。
いきなり全てのソースを綺麗にする必要はない
いきなり、触る前の状態を完璧に綺麗に、修正するなんて
できないと思います。
なぜなら以下のことが懸念されるためです。
・通常、ソースを綺麗にする期間なんてとられないため、
時間が余計にとられる。
・動いている処理を直すことになるので、直す前の状態と同じ動作にできるか、
再度テストをしなくてはいけない。それも余計な時間がかかってしまう。
ということなので、まずは小さなことからはじめていくのが、一番リスクが少ないやり方なんですね。
綺麗にするためにできる小さなこと
・適当に付けられている変数名を予測しやすいものにする
→開発ツールなどを使って変数名を一発置換すると楽で、デグレードも置きにくいです。
・使っていない変数は削除する。
→あからさまに使用していない変数がある場合は、削除すべきです。
使用しているかしていないかは
変数名でソース内（外部のソースから参照されている場合は外部のソースも）で検索を行い、
使用可否を調べます。
上記の二つを行うだけでも少しずつソースは綺麗に見やすくなるのではないかなと思います。
よくあるのが
動いているのだから触るな！
というもの。
確かに一理ありますが、これだと技術的負債というものが溜まっていき、結果バグを生みやすいというものになるのです。
まとめ
動いているソースは触るな、動かなくなるから！！
という考えもわかりますが、そうするとどんどん負債が溜まっていき
最終的には誰もがわからなくなるソースになって、
余計に修正に時間がかかるという悪循環に陥るんですね。
来たときよりもきれいに！少しずつで良いので
綺麗にしてこう！
これ本当に大事です。
今回は以上です！！