献本頂きました：良いコードを書く技術

point programming

かなり日が経ってしまいましたが、「良いコードを書く技術」の献本をいただきました。

良いコードを書く技術　?読みやすく保守しやすいプログラミング作法 (WEB+DB PRESS plus)

良いコードを書く技術　?読みやすく保守しやすいプログラミング作法 (WEB+DB PRESS plus)

個人的には大変いい本だと思っていますので、宣伝もかねて少しコメントしたいと思います。

対象読者

まずは、この本がターゲットとしている対象読者についてです。

ブログなどでよく見るようなWeb系企業だけでなくて、ぜんぜん表に出てこないようなSIerも含めたエンジニアの人口分布を考えてみます。自分のこれまでの経験から、以下のような分布になっているのではないかと考えています。



エンジニア人口の分布（想像）：※軸の説明は本文参照

縦軸は技術レベルを表します。

  • A 一人で完結して仕事が出来る人
    • AA 自力でサービスまで作れる、勉強会スピーカー、未踏戦士とか
  • B 中間の人
    • B+　うまく伸ばせば伸びる人
    • B- うまく教えれば人並みに出来る人
  • C ※お察しください

横軸は意識レベルを表します。

  • 1 コードに魂を売った人
  • 2 勉強会にも積極的に出て上を目指したい人
  • 3 プログラミングは嫌いではないが、仕事以外の時間は楽しみたい
  • 4 そもそもプログラミングが嫌い

色が付いているところがエンジニアの人口の分布で、B3あたりにピークがあって、斜めに分布が広がっているイメージです。

なお、他にも独立な軸はいくつかある(例えば環境とか仕事力とか)と思いますので、この図は適当に射影したものだと考えてください。また、いくつかの企業やSIerの現場を見てきた自分の経験をもとにしていますので、もしかしたらみなさんの現場とは違うかもしれません。

この分布図の中で、赤っぽい部分(B3周辺)が対象読者です。



対象読者の分布（想像）

ちなみに、はてなの皆様（この記事を読んでいるような皆さん）は水色のあたりだと思っています。アウトプットし続けたり難しい本や技術に挑戦していて、かなりレベルが高いと思っています。はてなの皆様に限らず、Code Complete（や巻末の参考文献など）を読んだり、Amazonに積極的に書評を書くような人もこのあたりに入ると思います。

なので、この本は、この記事を読んでいるような皆さん自身にとってはかなり物足りない内容のはずです。期待して買ってがっかりされた人もおられるかもしれません。ごめんなさい。

しかしながら、新人教育やメンバーの底上げには丁度良い分量と内容になっていると思います。かなり頑張って計算して内容や章立てを組み立ててありますし、この正味200ページという分量にも意味があります。

先程の分布を仮定するとターゲットとなる読者数が多いため、少しの効果でも人数が多ければ全体的効果が高いと思います。特にエンジニアの人数の多い(何十人以上)組織にお勧めです。

抽象化

この本でもう一つ個人的に重要だと思っているテーマが抽象化です。抽象化には哲学が重要だと思っていて、その抽象化に対する哲学がこの本にはちょっとだけ含まれています。個人的には抽象化については「SICP読め」で終わってしまうのですが、なかなか現実はそうもいきません。

情報系の研究室の方々や関数型言語をやっている人達には考えられないと思いますが、現場(特にSIer)では「プログラマ」を100人集めたとき9割以上の人は再帰を使ったプログラムが書けません。クイックソートはもちろんバブルソートすら書けない人も多いです。そもそも抽象化以前のレベルではありますが、こういう現状はFizzBuzzのテストや迷路の試験などの結果からも裏づけられていると思います。*1

こういう抽象化以前の現状に対して、どのように抽象化とそのパワー、そして各自のスキルの目指すべき方向を伝えられるか、ということがこの本のひとつの目標でした。(自分は書いてないけど)

現場でよく行なわれている「単に似ているところをまとめるだけの抽象化」だけでは限界がある、でも「勤勉な人の繊細なシステム」を作るような人にもなって欲くない。後半ではそういう微妙なラインを狙って章立てをしています。上の図でB2-B3の人達が業務しか経験していないと全く見ることがないであろう(でも現場ですぐに使えそうな感じの)具体例やテクニックを並べています。(自分は書いてないけど)

arton　勤勉中の勤勉なという人が世の中にはいるわけ。勤勉には飽きたらずもっと勤勉な人。そういう人はねいろんなこと勉強するから、色んなこと知ってるわけ。そうすっと、その人のプログラムがちょっと走った後には、なぜか String#length が実際の長さの 100 倍の値が返ってくるとかさ、色んな事が起きそうだよね。
　　:
arton　Web 2.0 系はβだから良いんだよ。直せば良い。masuidrive さんが一人で一所懸命頑張って作ったシステムっていうのと、勤勉な人たちが 1000 人ぐらいなぜか中国やインドから人を集めて作ったシステムは、繊細さが違うんだよ、繊細さが (笑) あまりにも繊細なものだから、息吹きかけてもやばいわけ。
一同　(笑)
ささだ　角谷さんウケすぎ。
角谷　「勤勉な人たちの作った繊細なシステム」という表現がもう素晴らし過ぎて (笑) 思い当たることがたくさん……。
　　:
(※ 引用の強調はkiwanamiの主観です)

この本の中で紹介した具体例を身に付けて欲しいというわけではありません。例示した内容を通して、「抽象化にはいろいろなレベルや方法があって、ちょっとしたテクニックでもすごい生産性が得られて早く家に帰れますよ。でも現場だけでは経験できないことが多いし無闇に使うと火傷するから、たくさん本や情報を得てバランスの良い選択をして欲しい。」ということが伝わればいいなと思っています。(自分は書いてないけど)

そこで興味を持ってもらった人には、ぜひ巻末の参考文献を取っ掛かりにして先に進んで欲しいです。

ということで、この本が多くの現場エンジニアに読まれて、少しでも現場の底上げに役立ってもらえるといいなあと祈念いたしまして、献本の謝辞にかえさせて頂きます。ありがとうございました。

*1:ただし逆に、現場の人はもっと重要な別のエンジニアリングがあります。例えば、業務知識の引き出し方・まとめ方・分割の仕方、部屋のレイアウト・クライアント配置・配線や電源も含めたインフラ整備、データ移行、システム導入計画や切り替えのマネージメント、稼動後の障害対応などなど挙げ始めるときりがありません。もちろん技術的スキル不足からブラックになっている現場も多々あるのですが、開発プロセスやテストコードやドメインなんとかの枝葉以前に、そもそも今から作ろうとしているシステムを一体誰が責任を持って稼動させるのかという視点が抜けているなあと思うことが多いです。そこがちゃんとしていれば多くの問題は解決するはずなのですが。すみません、余談が長すぎました。続きは別エントリでやるかもしれません。