カタチづくりカタチづくり読者になるカタチづくりこの広告は、90日以上更新していないブログに表示しています。2007-08-01なぜソースコードは美しくあるべきなのかprogrammingFujiwoさんが「美しいソースコードのための七箇条」というエントリを書かれた。グッジョブです、Fujiwoさん!「美しいソースコードのための七箇条」というのを考えてみた。(Sho's))ただ、ちょっと思ったのは、こういうエントリって既に美しいソースコードの書き方を(ある程度以上)知っている人にしかウケないんじゃないかしら、という心配。「七箇条」を補完する意味で、「なぜソースコードは美しくあるべきなのか」を書いてみたい。うまく書けるかなぁ・・・。機能的まずここで言う「美しい」ってのは、雄大な自然が美しいとか、美しい芸術とは意味が違う。「機能的なものは美しい」とかっていう言葉があるけど、そういう意味。雄大な自然は理屈ぬきで美しいけど、美しいソースコードは背景に理屈がある。理屈抜きには語れない美しさ。「美しいソースコードのための七箇条」は「機能的なソースコードのための七箇条」と言い換えてもいい、はず。なんだけど、やっぱり「美しい」と言いたくなっちゃうんだね。美しいと言いたいかというと、ソースコードの美しさを体で理解した人にとっては、それはもはや左脳ではなくて右脳で感じる機能性になっているからだ。理屈抜きには語れない美しさのはずなのに、理屈ぬきに美しさを直観してしまう体になっている。いう体になっていない人にとっては、「ソースコードが美しい」なんて気持ち悪く感じてしまうかも。いう人は「美しい」を「機能的な」に置き換えて読んで構わないと思う。守備としての美しさサッカーやバスケと同様に、ソフトウェア開発にも攻めと守りがある。攻めはゴールを決めること。目的(ゴール!)となる機能を実現することであり、競合製品に対して優位に立つことであり、更に言えばその機能が売れてお金になることだ。対して守りとは、品質を落とさず長期にわたってメンテナンスや運用を継続していくこと。ここでいう「美しいソースコード」というのは「守りのための機能性を備えたソースコード」と考えれば良い。言い切ってしまうと、守りに理論はあるが、攻めに理論はない。スポーツでもそうじゃないかな。守りよりも攻めの方が才能が要求される。守りは地道な練習の成果だが、攻めは天才による芸術的なプレーに拠るところが大きい。「こういう練習をすれば誰でも芸術的なプレーが出来る」という理論はないんだ。守りが攻めのリズムを作る。リズムがないと芸術的な攻撃は出来ないのだ。スポーツでも守りの練習は重要だし、ソフトウェア開発でもそうだ。「美しいソースコード」といえばそれは守備の美しさなのだ。美しい守備がもたらすもの守備なんてつまらないという人もいるだろう。芸術的な攻撃的プレーに憧れているんだ、という人もいるだろう。いう人にこそ美しい守備が必要なのだ。次の事実も知って欲しい。プログラミングの時間の大半は、実は既存のコードを読んだり理解したり、あるいは修正したりといった作業に費やされている。純粋に新規開発に当てている時間は直観的に思うよりもずっと短い。ある機能の開発に取り掛かったとする。その機能にはAモジュールに定義されたBクラスを使う必要がありそうだ、じゃあBクラスの使い方は・・・、といった感じで、既存モジュールの既存クラスを調査することになる。純粋な新規開発はわずかだ。既存のコードを理解したり修正したりする作業を「守備」、純粋な新規開発を「攻撃」と捉えてみよう。すると上記の事実は次のように言い換えられる。「ソフトウェア開発の大半は攻撃よりも守備に追われている」。ソースコードは美しくあるべきなのか。それは守備に費やす時間を出来るだけ減らして、多くの時間を攻撃に回すためだ。ゴールを決めなきゃゲームには勝てない。出来るだけ攻撃に時間をまわさないといけない。美しい守備を心がけるべきなのだ。美しいコードはコントロールしやすいさっき守備を「既存のコードを理解したり修正したりする作業」と書いたけど、要するに守備とはコードをコントロールすることだ。守備がゲームを支配するんだ。美しいコードはコントロールしやすい。いうか、正確には、熟練したプログラマはコントロールしやすいコードを美しいと感じる。コントロールしやすいコードが機能的なコードであり、美しいコードなのだ。美しいコードとは読みやすいコードのことではない。熟練プログラマが書く美しいコードは、大抵の場合初心者には読みにくい。読みやすいとか読みにくいという指標は、読む人の技量や好みに左右されてしまうので、僕はあまり「読みやすい」という表現は使うべきではないと思っている。それよりもコントロールしやすいという方が誤解が少ない。コードをコントロールするってどういうことか。僕はコントロールには大きく分けて次の2種類があると思っている。帰納的なコントロール演繹的なコントロール帰納的なコントロールあなたにある関数が渡されたとしよう。その関数の仕様について何の説明も受けていないし、ソースコードにコメントもない。その関数を、中身のソースを一切読まないで動作を理解し自分の支配下に置くことが帰納的なコントロールだ。帰納的なコントロールにおいて、その関数は完全にブラックボックスだ。中身の見えない箱を眺めたり叩いたりして、その関数の動作を検証しなくてはならない。その関数がどんな性質を持っていれば帰納的にコントロールし易いだろうか。幾つか思いつくものを並べてみよう。関数の名前は機能の重要なヒントだ。引数は少ない方が調べやすそうだ。引数を2〜3パターン試す程度で予測可能な動作なら分かりやすい。逆に色んな引数を入れて試してみてもなかなか傾向がつかめない関数はコントロールしにくい。演繹的なコントロール演繹は帰納の対義語だ。あなたにある関数が渡されたとしよう。その関数の仕様について何の説明も受けていないし、ソースコードにコメントもない。その関数を、外側からのテストを一切行わず中身のソースを読むだけで動作を理解し自分の支配下に置くことが演繹的なコントロールだ。放って置くと、いつの間にかソフトウェアのエントロピーは増大し、プロジェクトはアンコントローラブル(制御不能)に陥ってしまう。僕の経験では、帰納的なコントロールよりも演繹的なコントロールの方が壊れやすいし、帰納的なコントロールを保つことはとても重要だ。演繹的なコントロールを失うと、次のようなことが起こる。あるフラグの意味を知りたいとしよう。最初はそのフラグの周辺のコードを読み始める。演繹的なコントロールを試みる。ところがスパゲッティコードでさっぱり意味が分からない。そこであなたはこう思いつく。試しにこのフラグを1から2に変えてみよう。その状態でソフトウェアを起動してみて、どんな動作になったかを確認すればいいじゃないか。これはまさに帰納的なコントロールだ。確かにフラグの意味は把握できたかもしれないが、ソフトウェアがあなたのコントロールから静かに零れ落ちようとする気配を感じないだろうか。これが不吉なにおいだ。ここでリファクタリングして演繹的なコントロールを取り戻さなくてはならない。しなければ、いずれ帰納的なコントロールも失い、制御不能に陥るだろう。まとめ美しいソースコードとは、機能的なソースコードだ美しいソースコードとは、守備の美しさだ守備に費やす時間を減らし、より攻撃に集中するためにこそ、美しい守備を心がけよう美しい守備はゲーム(プロジェクト)をコントロール可能にするコントロールには帰納的なものと演繹的なものがある演繹的なコントロールから先に壊れるなんか色々と漏れがありそうだし、議論も荒っぽいかな。いいや、叩き台として。読者になるこのブログについて検索リンクはてなブログブログをはじめる週刊はてなブログはてなブログPro最新記事はてなブログを開設してみたもう少し先の話だが引越しを検討しているの...7名の作家が自炊代行業者を訴えるそうだ。3はてなブログをはじめよう!u_1rohさんは、はてなブログを使っています。ブログを報告する引用をストックしましたストック一覧を見る閉じる引用するにはまずログインしてくださいログイン閉じる引用をストックできませんでした。再度お試しください閉じる限定公開記事のため引用できません。