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

ホーム

2011年01月12日

昨日の話の続き。

昨日、こんなコードを話題にしたけど:

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であることに気づかない
くらいに未熟なわけです。ひょっとしたらロクにコードも
読んでないんじゃないかって疑われても仕方ない。

で、こういうことを推測したら、バージョン管理で履歴を
確かめることもありますよ。バージョン管理にはそういう
使い方もある。

本家Permlink


2011年01月11日

でも、リファクタリングって間違い探しみたいなとこは
あるよね。

ある関数と別の関数が似てるときとか。そいつらを抜き
出して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読み込んでるでしょ?
って、そういうところが気になっちゃうわけ。

多分、著者からしたら、そんなことを気にするヤツは
負け組だよって話なんだろうけど。

--

だから、丁寧と迅速を両立させるにはどうするかって
ことを考えちゃうし。それでも丁寧に書きたいんだから、
丁寧に書いてもプロジェクトが回るようにできないかとか、
丁寧に書いてもビジネスにできないかとか、そういう
ことを考えちゃうわけね。

雑でもいいから速くっていうんなら、最初っからそういう
人に頼めばいいだけの話だよね。でも、そういう人は
丁寧に書けないから雑に書いてるんであってね。雑にも
丁寧にも書ける人なんて実際にはいないでしょう。

本家Permlink


2011年01月06日

プロフ

* toRuby 第2回から参加
* Ruby 1.1bくらいのころから
* 職業プログラマ
* バカが征く
* キれてない
* 中二でもない
* まことに遺憾である

本家Permlink


2011年01月04日

サッカーでオートマチックとかオートマティズムっていう
言葉があるでしょう。

自分、サッカーのことには詳しくないんで適当な例が
あげられないんですけど。野球でいえば、2アウトでフライが
上がったらランナーは走らなきゃいけないでしょう。

『こういう状況ならこういう動きをしなきゃいけない』って
いうのがあるわけで、それをオートマティズムと呼ぶんだと
自分は理解してるわけです。

で、そのオートマティズムを身につけるためにトレーニングを
するわけですよね。

で、そういうのを見て、『人権無視だ!』とか騒ぐ人は
いないわけです。『個性がない』と嘆く人はいるかも
しれないけど (笑)。でも、いくらサッカーがクリエイティブな
スポーツだっていっても、オートマティズムがないチームは
勝てないでしょう。

自分らだってそうですよね。生産性を高めるには、
どうしたってオートマティズムが必要になる。

オートマティズムをより広く解釈すれば、規律っていう
ことになるでしょう。

オートマティズムが大切だからといって創造性が大切
じゃないっていう話にはならなくって。どっちかって
いうと、創造性を産むために規律があるっていうか。

で、規律から創造性を産むには、やっぱり、みんなが
規律に納得してないとダメだと思うんですよね。

--

う〜ん。なんていうか、設計とコードを分けて考えてる
人がまだ多いのかなぁと。

設計っていうと、UMLで図を描いたりとか、アルゴリズム
選んだりとか、データ構造決めたりとか、そういうふうに、
設計っていう活動にはコードが現れちゃいけないみたいに
考えてるんじゃないですかね。

まぁ、コードから離れた設計も大切なんですけど。

でも、最終的な製作物はコードだし、本当の意味での
設計図はコードなわけでしょう。コンピュータは、その
設計図に従って仮想世界を作るんですから。

だからね、コードの設計にももうちょっと気を配って
いいと思うんですけどね。

本家Permlink


2011年01月02日

品質を落とす大きな要因は時間なんだなぁ。

時間がないからテストを省く。時間がないから設計で
手を抜く。

まぁ、時間は無限にあるわけじゃないし、締め切りは
厳として存在する。時間に追われるのがこの商売の
宿命といってもいいんだけど。

本家Permlink


Copyright © 1905 tko at jitu.org

バカが征く on Rails