久保清隆のブログ

ライフハック、健康、旅行など、役立つ情報を書きます。

『ビューティフル コード』×『プログラマ35歳定年説』 by まつもとゆきひろ セミナーまとめ

プログラミング

web-career.comに参加した。
内容のまとめと感想を書いた。

ビューティフルコード

※セミナーでBeautiful Code: Leading Programmers Explain How They Think (Theory in Practice (O'Reilly))を紹介していた。
 それも参考にするとよいかも。

コードとは?

コードの美を考える前に、まずコードについて考える。

  • よくある誤解

コードは、工業製品と同じように考えられてしまい、よく誤解されている。
しかし、コードは工業製品ではなく、新しいものが毎年大量に作られていて、コピーは一瞬でできる。
コードは、車の開発で言うと設計書。
ソフトウェア製作はクリエイティブな作業なのに、工場のラインの作業のように誤解されている。しかし、実際のソフトウェア製作は、デザインであり、職人芸であり、一品物で誰が作っても同じ、といったものではない。

  • コードは実用品

コードは、実用に使ってナンボ。

 コードを読む技術、どう読めば効果的なのかが書かれている。

    • コードは教材、知識の宝庫、オープンソース

 コードはネット上にたくさんある。
 コードは教材。コードとは、行動のプロセスをPCに教えるもの。
 曖昧性を排除。人間と人間の関わり合いにも通じる。
 ソースは知識の宝庫。アルゴリズムなどが得られる。
 実用レベルのOSを知るにはそのソースコードを見る必要がある。
 オープンソースにより皆がソースコードを読める。
 積極的にソースコードを読むような人が優れたプログラマーになれる。

コードの美とは?

美しいコードとは、理解度に基づいたコードである。
理解度とは、本当に求めているものをどれだけ知っているか、作成条件や、チームのことや、顧客のことなどをどれだけ考慮できるか、ということ。
この理解の対象によって、コードの美は2つに分けられる。
それは、外面の美(人間の理解に基づくもの)と内面の美(機械の理解に基づくもの)。

  • 外面の美

外面の美は、人がどう感じるか、ということに基づく美しさ。

    • 用の美

 コードは実用品。使って美しさを感じる。

      • どのようなコードが読みやすいか
      • どのように使えると使いやすいか

など。
人の心は単純じゃない。単純が好き、複雑が好き、簡単な問題が好き、難しい問題が好き、ということが人によって違うだけでなく、同じ人でも気分によって違う。
人間は知識によって進化し、その過程で何が美しいか、という価値観が変わる。
これは、唯一の正解がない、非理系的なもの。
長い目で見た効率を考えるのが重要。

  • 内面の美

機械の理解に基づく美。
2つある。パワーの美と効率の美。

    • パワーの美
      • アルゴリズムの力

  例えば表示速度が遅い時の対応。
  普通のプログラマは、小手先の技術でここをああすれば早くなるとか考え改善する。
  これだと改善しても数倍にしか速度は改善されない。
  スーパープログラマは、基本的なデータ構造を見直し、本質的なアルゴリズムを読みだす。
  そしてアルゴリズムを改善し、美しい、感動させるようなコードに変え、1000倍以上速度を改善してしまう。

      • 出来ないを出来るにするのが本当のプログラマ

  Rubyの文字列処理に関して松本さんは最初、SJISとEUCはできていたが、
  UTF-8は無理だと思っていたのでやらなかった。
  でも吉田さんという人がUTF-8も対応可能にした。

※アルゴリズムについて
アルゴリズムについても話していたので、一応書いておく。
◆計算量について
O記法で示される。
O(1)    :データが増えても計算量は増えない。理想的なアルゴリズム。
O(n)    :データが2倍になると、計算量も2倍になる。
O(n*log(n)) :O(n)とO(n^2)の中間。
O(n^2)   :データが2倍になると、計算量は4(2^2)倍になる。指数関数的に増加。

◆ソートアルゴリズム
バブルソート :O(n^2)。遅い。
マージンソート:O(n*log(n))。まぁまぁな速度。
クイックソート:早いが、あるケースではO(n^2)になるという弱点がある。
    • 効率の美
      • 生産性

  コードの生産性を上げる。

      • 簡潔さ

  Succintness is Power(簡潔さは力なり) by Paul Graham
  簡潔さは力なのか?
  人月の神話に、Brooksの生産性普遍の法則がある。
  これは、ある人が一日にコードを500行書けるとすると、どの言語を用いても500行書ける。
  しかし、同じ500行でも、言語によって生産性は変わる。
  簡潔な言語なら、プログラミングの本質に集中できるので、簡潔さは力となる。
  Javaは、書かなければならないコードが多いが、Rubyだと少なくてすむ。

  では簡潔さ(シンプル)は美しいのか?
  シンプルさには罠がある。
  言語自体をシンプルにすると、ソフトウェアのコードは複雑になる。
  言語自体を複雑にすれば、ソフトウェアのコードはシンプルにできる。

  怠惰のための勤勉
  手抜きをするのは美しくない。
  でも苦労をみせびらかすのは粋じゃない。
  水鳥のごとく。水上では優雅に、水面下では懸命に。

※Rubyについて
Rubyは冗長性を排除した簡潔な言語。
DRY(Don't Repeat Yourself)という性格。
なぜDRYがいいかというと、コードが繰り返されるとバグも繰り返される。
そうするとソフトウェアの質が下がる。
そうすると顧客満足度も下がる。

言語自体をシンプルにするか、複雑にするかという問題では、
Rubyは言語自体を複雑にした。
なぜかというと、人間にフォーカスしたから。
思いやり、やさしさを人間に向けた。
おかげで、Rubyを使ってソフトウェアを作るとき、シンプルなコードで書ける。

また、Rubyは思考の流れに沿って書ける。
〜して、〜して、〜する。みたいな感じ。
一方、Haskellは、思考の流れと逆の語順になる。
プログラマ=アーティスト+エンジニア

プログラマはアーティストである。
歯車ではないし、作業員ではない。
想像的で自発的(やりたいからやる)である。
しかし、アーティストだからといって、これは嫌だからやらない、というわけにはいかない。
実際は、納期を気にしないといけないし、顧客やチームのことも考慮する。
プログラマ=アーティスト+エンジニアである。
ここで、他の業界のアーティストに目を向けてみるとよい。
アーティストの心を持ちながら仕事をしている人は多い。
他業界の人から見習える点があるはず。

寓話


ある旅人が道を歩いていました。すると、ある職人がレンガを積んでいる人がいました。
旅人が「何をしているんですか?」と尋ねると、職人は「見ればわかるだろ。レンガを積んでるんだよ。」と答えました。
さらに歩いているとまた別の職人がいました。旅人がまた何をしているか尋ねると、職人は「レンガを積んで壁を作っているんだ。」と答えました。
さらに歩くとまた別の職人がいました。旅人がまた何をしているか尋ねると、職人は「ここに教会を作っていろんな人がお祈り出来るようにするんだ。」と答えました。
セミナーでは、この話じゃないけど、これに似た話をしていた。
ようは自分の仕事にどれだけの意味を持たせることができるかは自分次第。
これがモチベーションにつながるし、プロフェッショナルな意識につながると思う。
この寓話では、3人の職人が同じことをしているけど、皆考えが違う。
最初の人は言われたことだけやる人、次の人はやっていることに意味を見出している、最後の職人は大きな志を持って仕事をしている。
この3人の中で誰が一番いい仕事をするかというと、おそらく3人目だろう。
プログラマもお金のためだけに書いたり、言われたものと作ってるより、もっと大きなビジョンを持って仕事に取り組むことが大切だと思う。

まとめ
  • コードは美しい
  • コードはアート
  • プログラマはアーティスト(+エンジニア)
  • 誤解の蔓延
    • ソフトウェア工場
    • シンプルは善
    • アーティストは仕事にはならない

感想

純粋なプログラミング系のセミナーに出たのは初めてだったけど、思ったより理解できたし面白かった。今まではプログラミングに関する言葉とかがわからなそうだから多分聞いてもあまり意味わからないんだろうな、と思ってたけど意外に大丈夫だった。これからはもっと参加していこうかな。

松本さんはしゃべるのが速めで、頭の回転も速いんだろうなと思った。
美しいコードに関することだけでなく、プログラミング言語を作るときの考えや仕事の仕方、プログラマとして必要なことも話して下さって勉強になった。松本さんは、人生逆はり。東京が嫌だったので地方に行った。レアな所に行くと大切にしてもらえ待遇もよかったらしい。東京には仕事が多いが仕事は1つしか選べないので、地方でも仕事が1つ決まれば問題ないと言っていたのがなるほど、と思った。

また、
「プログラミングにはセンスは必要だが、一番大切なのは自覚。アーティストとしての自覚を持つことが大切。自覚している人はほっておいても学ぶし、成長する。」
と言っていた。
今まではあまりそういう自覚は持ってなかった。
今後は意識していこう。


他の業界のアーティストから学ぶという点では、ミュージシャンや画家や作家から学ぶことが多いと思う。
ミュージシャンは自分たちの芸術と思う音楽を作っていても売れなかったりして、売れるような曲にするかやりたいことを貫くかという方向性でよく議論になっている。
彼らの思想からプロフェッショナルな意識を学びとりたい。