Hatena::ブログ(Diary)

杉風呂2.0 - A Lifelog -

2013-01-20(日)

[]『リーダブルコード』を他書と読み比べる(その1)

よい本なので、他書と比較しながら再読していきます。短期集中連載のつもり。

1章 理解しやすいコード

ここでは本書の根底となる「すべての原則が生じるテーマ」と「読みやすさの基本定理」について説明がされています。

コードは理解しやすくなければいけない。

コードは他の人が最短時間で理解できるように書かなければいけない。

C++ スタイルブック (IT Architects’ Archive―CLASSIC MODERN COMPUTING)』の「はじめに」には次のように書かれています。

チームが成果を上げるには、誰もが、他の人の書いたコードを読んで理解できなければならない。

Code Craft ~エクセレントなコードを書くための実践的技法~』1章「防御的プログラミングの技法」には次のように書かれています。

簡潔性よりも明瞭性を重視してコードを書く

簡潔ではあるのものの混乱を招くおそれのあるコードと、明瞭ではあるものの長く退屈に感じられる可能性のあるコードのどちらかを選べる状況では、洗練性には多少欠けるとしても、誤解なく明確に意図を読み取れるコードの方を使用します。(中略)自分が書いたコードが誰かに読まれる可能性があるのかを考えてみてください。そのコードの保守を比較的経験の浅いプログラマーに任せなければならない場合もあるかもしれません。その担当者がコードのロジックを理解できないとしたら、間違いが起きることは必至でしょう。複雑な構文や言語仕様を巧みに利用した小技を使えば、演算子の優先順位を知り尽くした博識ぶりを見せつけることはできるかもしれませんが、それによってコードの保守性は無残に損なわれてしまいます。「コードは常にシンプルに」が鉄則です。

Javaプログラミングの処方箋 (Programmer’s foundations)』には、逆に読みにくいコードがもたらす弊害について書かれています。

このようなコードは非常に読みにくく、このあとにこのコードを読む人に誤解を与えます。また、一度このような「汚いコード」が入ると、その汚いコードがほかにもどんどん波及していきます。元のコードが美しければ、それを「汚す」には勇気がいりますが、もともとが汚ければ誰しもコードを綺麗に保とうとしなくなります。

プログラマのためのサバイバルマニュアル』には次のように表現されています。

人は、複雑さの逆と言われると、単純を思い浮かべる。しかし、私たちの分野には避けられない複雑さがあるので、いつでも単純なコードが書けるとは限らない。複雑さの反対語としてより適切なのは、明快である。あなたのコードがしていることは、読者にとって明解だろうか。

プログラマのためのサバイバルマニュアル』は上記文章のあとで「2つの明快」について説明が続くのですが、「避けられない複雑さ」というのが気になります。『Developer's Code 本物のプログラマがしていること』(電子書籍もあるよ!)第4章「複雑さ」に面白いことが書かれています。

ほとんどのアイデアーーー見た目にはシンプルなアイデアーーーはその詳細に立ち入るとひどく複雑なものになる。高いレベルで考えている限り、アイデアはいつもシンプルだ。(中略)詳細に分け入ってみれば、ロジックのどこに穴があるのか、そのすべての場所が見えてくる。詳細とはそういうものなんだ。最後まで考え抜かれていないアイデア(つまりほとんどのアイデア)はこの時点で、複雑であることから逃れられなくなる。(中略)僕らは不十分であることを恐れている。そこにその答えがある。何かをシンプルに構築すると、それが十分なもののような気がしないんだ。

『Developer's Code』ではこのあと、複雑さを「コードが書くのが難しい」ことと複雑さがユーザに転移してしまった「使うのがむずかしい」ことの2つを引き起こし、「複雑さを表に出さない」こと、コードの複雑さを嫌うあまり「リファクタリングをあまりに早い段階で行うことの危険性」についての議論になっていきます。

コーディングの際にバイブル的な本として有名な『CODE COMPLETE 第2版 上 完全なプログラミングを目指して』を参照してみると、5.2.1「ソフトウェアの鉄則: 複雑さへの対応」に、Fred Brooksの定義を引用していますね。

Brooksによれば、ソフトウェア開発を難しくするのは、本質的な(essential)問題と偶発的な(accidental)問題という、2種類の問題であるという。

どうやら、複雑さへの対応として読みやすさが重要であるようですね。また、『CODE COMPLETE』5.2.2「設計に望ましい特性」に設計の内部特性を10個挙げています。

  • 最小限の複雑さ
  • 保守性
  • 粗結合
  • 拡張性
  • 再利用性
  • 高いファンイン
  • 低いファンアウト
  • 移植性
  • 無駄のなさ
  • 階層化

このうち、保守性がリーダビリティに関係あります。

保守の容易さとは、保守プログラマのために設計することである。保守プログラマがあなたの書いているコードについてどのような質問をするか常に想像しよう。保守プログラマを顧客と見なし、見ればすぐわかるようなシステムを設計しよう。

Kent Beckは『実装パターン』で次のように述べています。

何をシンプルとするかは人それぞれだ。ツールと技術を知り尽くしたプログラマから見たシンプルは、初心者には複雑すぎるかもしれない。相手を意識したときに、よい文章が生まれるように、よいプログラムも読み手を意識したときに生まれる。読み手の少し上を行くのはよいが、あまり複雑すぎると、相手にされなくなってしまう。(中略)コミュニケーションとシンプルは一体となって働くことが多い。余分な複雑性が減少すると、システムの理解が容易になる。コミュニケーションを重視すれば、どの複雑性を捨てるべきかが明確になる。

コミュニケーションまで含めているのがKent Beckらしいですね。相手あっての読みやすさということでしょうか。読みやすさが重要ということが十分に意識できたので、明日は2章「名前に情報を詰め込む」に入りたいと思います。

2012-06-14(木)

[][]『これでiPhoneアプリが1000万本売れた』

2011年4月の本なので1年以上前ではあるが、読んでみた。この手の書籍は個人開発者がモチベーションを維持するために読むためにあるのかも。App Store の概要やどうやって収益をあげるか、どういうアプリを作ればよいか、どう開発するか、といった話。巻頭に仕様書が付いてくるので、企画などをやる人は目安として参考にするとよいかも。

これでiPhoneアプリが1000万本売れた

これでiPhoneアプリが1000万本売れた

2012-05-08(火)

[][]『達人に学ぶDB設計 徹底指南書 初級者で終わりたくないあなたへ』

GW中の2日間でいっきに読んだ。よくまとまっている。いろいろ触れていない項目もあるけど、論理設計では業種やプロジェクト運営に依存するし、物理設計では、ターゲットのRDBMSを固定しないと詳細に入れない部分もあるから仕方ない。本書の態度として、論理設計と物理設計を明確に境界を持たせずトレードオフを意識することを挙げていて、それなりのシステムを扱う人にはこれが基本的な態度になるだろうなと思う。読みどころとしては、7章「論理設計のバッドノウハウ」8章「論理設計のグレーノウハウ」で、それなりに経験の積んだエンジニアは該当事例に出会ったことがあるはず。で、その中には自分の現場では上手くいったということさえあると思う。なぜそれで上手くいっていたのか、逆にダメだったのか、どうすればよかったのかということを考えながら読むと面白い(にがい記憶が思い出される?)と思う。他、akipii さんによると、8章「一歩進んだ論理設計」で扱われている入れ子集合モデルがRedmineで採用されているらしい。

達人に学ぶDB設計 徹底指南書 初級者で終わりたくないあなたへ

達人に学ぶDB設計 徹底指南書 初級者で終わりたくないあなたへ