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
12
2020
1
2
3
4
5
6
7
8
9
10
11
12
2021
1
昨日の話の続き。 昨日、こんなコードを話題にしたけど: 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