2005
6
7
8
9
10
11
12
2006
1
2
3
4
5
6
7
8
9
10
11
12
2007
1
2
3
4
5
6
7
8
9
10
11
12
2008
1
2
3
4
5
6
7
8
9
10
11
12
2009
1
2
3
4
5
6
7
8
9
10
11
12
2010
1
2
3
4
5
6
7
8
9
10
11
12
2011
1
2
3
4
5
6
7
8
9
10
11
12
2012
1
2
3
4
5
6
7
8
9
10
11
12
2013
1
2
3
4
5
6
7
8
9
10
11
12
2014
1
2
3
4
5
6
7
8
9
10
11
12
2015
1
2
3
4
5
6
7
8
9
10
11
12
2016
1
2
3
4
5
6
7
8
9
10
11
12
2017
1
2
3
4
5
6
7
8
9
10
11
12
2018
1
2
3
4
5
6
7
8
9
10
11
12
2019
1
2
3
4
5
6
7
8
9
10
11
昨日の話の続き。
昨日、こんなコードを話題にしたけど：
def foo
if @a == @b
return if @c != @d
do_something
end
end
で、これを見て、外側のif文は後から書き足されたんじゃ
ないかと推測するわけです。っていうのは：
def foo
if @a == @b
if @c == @d
do_something
end
end
end
みたいな書き方だとフツーにダメなコードで。こっちは
ダメはダメなりに一貫性がある。最初にあげたコードには、
その一貫性がないわけです。一貫性のなさは、別の人が
書いたと考えるのがフツーでしょう。
で、外側のほうが書き足されたっていうのは、内側の
ほうが正しく書かれてるように見えるから。そういう
正しいコードを書く人が、外側のif文の一貫性のなさを
気にしないわけがない。やるんだったら、昨日も書いた
ように：
def foo
return if @a != @b
return if @c != @d
do_something
end
くらいは書くでしょう。
で、そうすると、外側のif文を書いた人間が未熟だって
いうこともわかるわけです。どのくらい未熟かっていうと、
内側のif文がguard clauseであることに気づかない
くらいに未熟なわけです。ひょっとしたらロクにコードも
読んでないんじゃないかって疑われても仕方ない。
で、こういうことを推測したら、バージョン管理で履歴を
確かめることもありますよ。バージョン管理にはそういう
使い方もある。
でも、リファクタリングって間違い探しみたいなとこは
あるよね。
ある関数と別の関数が似てるときとか。そいつらを抜き
出してdiff取ったりね。diff取るためにそれぞれを整えて
わざと似せたりね。
大体、リファクタリングのきっかけって違和感でしょ。
『不吉な臭い』っていう言い方もされるけど、自分の
場合、違和感っていうほうがいいかな。
『このメソッドとあのメソッド、よく似てるけど違いは
何なの？』とか。『なんでこのメソッドがこのクラスに
あるの？』とか。
初歩的な例で、こないだこんなコードを見たんだけど：
def foo
if @a == @b
return if @c != @d
do_something
end
end
パッと見、ダメだよね。
書き方としては：
def foo
return if @a != @b
return if @c != @d
do_something
end
こうだし、よりベターには：
def foo
return if @a != @b or @c != @d
do_something
end
になる。
『パッと見』っていうのがポイントで、それは、いって
みれば、間違い探しの感覚に近い。
--
逆にいうと、こうした違和感っていうのは、個人の感覚に
よるものだから、共有するのは結構むずかしい。少なくとも
自分はそう感じるのね。
上のコードもレビューのときにチラ見したんだけど、
黙ってたんだよね。話しても共感してくれるかどうか
ビミョーだったから。まぁ、今は黙ってたことをちょっと
後悔してるんだけど (笑)。
リファクタリングの多くは、こうしたレトリックの話、
字面上の話で、くだらないっていわれたら、まぁ、
それまでの話なんだけど。でも、自分はそれを大切に
思ってるわけね。
自分は『丁寧に書こう』っていったりもするんだけど。
その『丁寧に』っていうのは、こういうレトリックの
話をいってるつもり。
--
NimotsuKunにしても、なんでStateっていう名前なの？
Stageでしょ？ だって、stageData.txt読み込んでるでしょ？
って、そういうところが気になっちゃうわけ。
多分、著者からしたら、そんなことを気にするヤツは
負け組だよって話なんだろうけど。
--
だから、丁寧と迅速を両立させるにはどうするかって
ことを考えちゃうし。それでも丁寧に書きたいんだから、
丁寧に書いてもプロジェクトが回るようにできないかとか、
丁寧に書いてもビジネスにできないかとか、そういう
ことを考えちゃうわけね。
雑でもいいから速くっていうんなら、最初っからそういう
人に頼めばいいだけの話だよね。でも、そういう人は
丁寧に書けないから雑に書いてるんであってね。雑にも
丁寧にも書ける人なんて実際にはいないでしょう。
プロフ * toRuby 第2回から参加 * Ruby 1.1bくらいのころから * 職業プログラマ * バカが征く * キれてない * 中二でもない * まことに遺憾である
サッカーでオートマチックとかオートマティズムっていう 言葉があるでしょう。 自分、サッカーのことには詳しくないんで適当な例が あげられないんですけど。野球でいえば、2アウトでフライが 上がったらランナーは走らなきゃいけないでしょう。 『こういう状況ならこういう動きをしなきゃいけない』って いうのがあるわけで、それをオートマティズムと呼ぶんだと 自分は理解してるわけです。 で、そのオートマティズムを身につけるためにトレーニングを するわけですよね。 で、そういうのを見て、『人権無視だ！』とか騒ぐ人は いないわけです。『個性がない』と嘆く人はいるかも しれないけど (笑)。でも、いくらサッカーがクリエイティブな スポーツだっていっても、オートマティズムがないチームは 勝てないでしょう。 自分らだってそうですよね。生産性を高めるには、 どうしたってオートマティズムが必要になる。 オートマティズムをより広く解釈すれば、規律っていう ことになるでしょう。 オートマティズムが大切だからといって創造性が大切 じゃないっていう話にはならなくって。どっちかって いうと、創造性を産むために規律があるっていうか。 で、規律から創造性を産むには、やっぱり、みんなが 規律に納得してないとダメだと思うんですよね。 -- う〜ん。なんていうか、設計とコードを分けて考えてる 人がまだ多いのかなぁと。 設計っていうと、UMLで図を描いたりとか、アルゴリズム 選んだりとか、データ構造決めたりとか、そういうふうに、 設計っていう活動にはコードが現れちゃいけないみたいに 考えてるんじゃないですかね。 まぁ、コードから離れた設計も大切なんですけど。 でも、最終的な製作物はコードだし、本当の意味での 設計図はコードなわけでしょう。コンピュータは、その 設計図に従って仮想世界を作るんですから。 だからね、コードの設計にももうちょっと気を配って いいと思うんですけどね。
品質を落とす大きな要因は時間なんだなぁ。 時間がないからテストを省く。時間がないから設計で 手を抜く。 まぁ、時間は無限にあるわけじゃないし、締め切りは 厳として存在する。時間に追われるのがこの商売の 宿命といってもいいんだけど。
Copyright © 1905 tko at jitu.org