Personal tools
You are here: Home ブログ 井上 質問が来たので答えてみる
« September 2010 »
Su Mo Tu We Th Fr Sa
      1 2 3 4
5 6 7 8 9 10 11
12 13 14 15 16 17 18
19 20 21 22 23 24 25
26 27 28 29 30    
Recent comments
Re:Javaの面白いバグ 徐です 2010-08-30
Re:Javaの面白いバグ inoue 2010-08-23
Re:Javaの面白いバグ 徐です 2010-08-18
Re:WebSocketのプロトコル inoue 2010-08-12
Re:WebSocketのプロトコル naruse 2010-08-11
Re:blogのコメントスパムが多すぎる inoue 2010-07-22
Re:マルチスケジューラv5.1.4をリリース - inspired by salesforceのchatter - inoue 2010-06-09
Re:マルチスケジューラv5.1.4をリリース - inspired by salesforceのchatter - hamabe 2010-06-08
Re:雑誌連載「Emacsのトラノマキ」の原稿(part4)公開 tune 2010-05-27
Re:雑誌連載「Emacsのトラノマキ」の原稿(part4)公開 tune 2010-05-27
Re:Emacs23.2が更に1ビット稼いだ秘密 inoue 2010-05-14
Re:Emacs23.2が更に1ビット稼いだ秘密 ef 2010-05-13
Categories
カテゴリなし
 
Document Actions

質問が来たので答えてみる

「動かなくてもいいから、動きそうなコードをかいてください。」 「動きそうも無いのに動くコードはいらない。」
Q1.「動きそうなコード」とはどういうコードですか?
動きそうもないのに、動くコードとは?

元の発言はシニカルで逆説的な言い方をしています。ぼくはシニカルで逆説的な表現が好きなのです。それを説明するのは野暮というもので、ぼくは野暮なことが嫌いです。嫌いですが、聞かれたので、蛇足をつけたします。

プログラムである以上、最終的には動かないと意味はありません。これは当然です。それでも敢えて、動くことより、読めるコードに価値があると倒錯した表現を使いました。「動きそうなコード」とは、人間が読めるコードであり、人間が理解できるコードです。

読めて理解できるコードであれば、例えそれが動かないコードだったとしても、動かせます。実行速度が遅ければ、速くできるかもしれません。下手なコードでも、読んで理解できれば改善できます。読んで理解するには、読み手の技量も重要ですが、とにかく、コードは人間が読んで理解できなければ存在価値が無いと思っています。

逆に、動作はしても、読んで理解できないコードは、保守できません。

他人の書いたコードを読んで理解するには一定の技量が必要で、これは実は想像以上に難しい技術です。だから、なんでもかんでも誰が読んでも容易に理解可能にすべき、というほど理想は求めていません(人も時間も有限です)。ただ、せめて自分が書いたコードぐらいは読めて理解できてほしいと思います。部外者から見ると信じられないかもしれませんが、自分の書いたコードがなぜ動いているか理解できていないのではないか、と思えるプログラマも世の中にはいます。忘れた、という次元の話ではありません。忘れるのは誰でもあります。昔自分で書いたコードが読めなくなっていることもあります。そういう次元ではなく、今、目の前で自分で書いているコードそのものを理解していないプログラマがいるのです。そんなんでプログラムは動くのかと思うかもしれませんが、困ったことに動くこともあるのです。

Q2. エレガントなコードを求めるのはどうしてですか?

誤解があるようです。エレガントの言葉の定義にもよりますが、別にエレガントなコードは求めていません。もちろん、エレガントなコードを否定もしません。エレガントなコードが美しいコードの意味だとすると、美しいに越したことはないですが、美しさよりも読めて理解できることの方を重視します。1の繰り返しになりますが、読めて理解できれば、下手なコードでも美しくできるかもしれないからです。

ぼくはプログラミングに関して原理主義者の側面もありますが、少なくとも大規模ソフトウェア開発に関しては現実主義者です。全てのコードに完璧さと美しさを求めたりはしません。コードには、カオスから守るべき領域とカオスを内包する領域の両方があることを認めています。カオスから守るべき部分、別の言い方をすると変化の影響を受けにくい部分は徹底的に守ります。守る防波堤(境界)がインターフェースです。だからインターフェースが重要です。カオスを内包する部分、別の言い方をすると変化を受け入れる部分も必要です。ここを見誤って、コードのあらゆる箇所に完全さを求めると窮屈なコードになります。コードには手を抜く部分も必要なのです。もっとも、手の抜き方は見かけほど簡単ではありません。

Q3. 「可能性」がありそう、と思われるエンジニアに共通点ってありますか? あったらいくつでも教えてください。

社会にうまく適応できない人の方が良いプログラマになる気もしますが、偏見かもしれません。時代も変わるし、変なチェック項目を作られるのが嫌ので、回答しません。

Q4. 尊敬している人と、その理由

rms

世界を変えたから。大衆に迎合しないから。信念のために戦うことを辞さないから。

The URL to Trackback this entry is:
http://dev.ariel-networks.com/Members/inoue/q-and-a/tbping
Add comment

You can add a comment by filling out the form below. Plain text formatting.

(Required)
(Required)
(Required)
This helps us prevent automated spamming.
Captcha Image


Copyright(C) 2001 - 2006 Ariel Networks, Inc. All rights reserved.