■

あれですな。
プリントアウトしてここがどーのとかいちいち言っていられませんな。
ソースが画面を見ながら。
悪い個所はその場で改修。
これがいちばんらくちん♪
どう直せばよいかわからなくても、その回答は現物をもって答えることができる。
すんげー間違った方向にも行きにくいおまけ付。

それに、口だけで言われたものをがんばって改修するかといわれたら、
ほぼ確実に後回しにされる。
目先のスケジュールに遅れが生じる要因として扱われるため。

そんなやつらにひとこといいたい。
（n´Д｀)η＜ばかやろーーー

なぜ改修をくらうか考えろ。
なぜ改修されるソースを作ったか考えろ。
なぜ改修が必要か考えろ。
それらを端的に表した言葉をつかうと次のようになる。
(..゜Д゜)＜おまいのソースは汚くて使えん。
汚いソースは読むのにも変更するにも時間がかかるのだ。

不自由で小難しくて誰かに説明するのにもめいっぱい時間がかかるようなソースに固執するのはなぜだ？
論理的に考えて導き出したとしても、今の形は複雑すぎではないのか？
仕様は変わる。それに対応しやすい形式は「単純な仕組みであること」ではないのか？
まさか「( ´∀｀)ノ＜これは変わりませんから〜」という言葉を信じているのではあるまいな？

ソース作成時に「( ´∀｀)あ、ちょっとくらいええかな？」って思うことはよくある。
そうやって本来あるべき姿を外れた特殊ケースが増やしてしまいたい衝動にかられることもある。
コピー元のソースがヘタレだったから〜っと自分を言い聞かせてしまうこともよくある。

だがしかし。

そういうのは直さねばならんのだ。
他人とソースを共有するためには、自分だけのロジックを組み上げてはつぶしがきかなくなるのだ。
明日から1週間くらい休みをとっても、おいらの仕事はだれかがやれるって状況は作っておくものなのだ。
備えあれば憂い無し。
のんだくれて二日酔いがひどい時には１日くらい会社を休めるのだ。

シンプルロジックを保ちつづけるのにはモチベーションが大事である。
仕様を考えて、実装形態を把握したうえで作られるソースは大抵綺麗であるのだが、
たまには勘違いが起こることもある。
勘違いからへんなもんを作ってしまったはいいけれども、
つじつま合わせで軌道修正ってのはやってしまうものである。
これを綺麗にするのには思い切りがいる。
よっしゃーやったるでーってくらい気合がいる。
そこでま〜いいやってほったらかしにしてしまっては火種が残ることになるのでいただけない。
モチベーションを高めてでも直すことをしたい。

常日頃からずーーっと1人で高めていることはできない。
そんなんムリムリ。
けれど、誰かを使えばわりと気楽にやれる。
1人でやるよりはずっと。
ちょくちょくソースレビューをちょっとだけされると思っていれば、
今そこにあるちょっとした修正に取り掛かる動機になる。
どーせほっといても言われるんだから〜という暗黙の強制力である。
人間、耳に痛いことはなるべく聞きたくないものだ。
だからなるべく痛みを回避しようとする。
ちっちゃい痛みですむならそれがいいと思うのも人情である。
どーせなら痛くないほうがいいのだが、
今、痛くなくてもあとからとんでもないしっぺ返しがきたりするといやなので我慢する。
仕様変更に振り回されたくはない。
ソースの不便さに毒づきたくもない。
便利な道具と、綺麗なソースの中でいきていたい。
改修は楽なほうがやっぱりいいと感じるのだ。

以上、大きく2点のよいところを持ち出して（・∀・）イイ! って言う根拠にする。
　・わるいところが手早く改修できる
　・その結果、仕事している時間がだんだん短くなっていく

ちいさなことからコツコツ積み上げていけば、
コードの記述ミスは減り、コピー後の変更手間も減り、
複雑難解なソースに仕上がることもなく、
なんでこんなことやってるの？ってな不可思議なソースに仕上がることもない。
時間を大きく取られる要素が減っていくのだ。
週40時間労働も夢幻ではなくなるのですよこれがまた( ´∀｀)ノ