コードシンプリシティ

f:id:Chisei:20131013204125g:plain

読了。良書だった。でも個人的にはリーダブルコードのほうが具体的で読みやすく、より多くの人が理解できるであろう良書だと感じた。

リーダブルコードは具体的なソースコードの書き方、例えば状況に応じた変数名の付け方などを解説しているため初学者でも読める。だがコードシンプリシティは良いコードと悪いコードの差はなにか?良いコードの利点と良いコードを書くための心構えはどうあるべきか?といった内容になっており具体的なソースコードはほとんど出てこない。ソフトウェアデザイン経験者であれば理解できる範囲は広そうだがそうでない人にとってはやや理解し難そうであると感じた。

ともあれ人に勧めたい良書ではある。

以下良いと感じた文章の引用。ちなみにコードシンプリシティ内でのデザインという単語はソフトウェアデザインのことのみを指している。

  • 駄目な結果というものを、本書ではいっさい許容しない。コードの改善に焦点を当てるのは、結果をより良くするためには、まずコードを改善することが最優先であるからに過ぎない。

  • システムを扱う際、我々にできるのは、個別のパーツを完結にし、それぞれのパーツを見たときにそれがどんなものかをすぐに理解できるようにしておくことだ。プログラミングとはつまり、複雑性をそぎ落として簡潔性に導く作業でなければならない。

  • 良い開発者はその能力の及ぶ限りコードを簡潔に書き、他の開発者が使いやすく理解しやすいようにしなければならない。

  • ソフトウェアを書く人は、誰でもデザイナーだ。

  • すべての開発者が、自分の受け持つ部分に対してデザインをより良くするための判断を独自にできるようにすべきだ。悪い判断や凡庸な判断がなされた場合には、開発リーダーやシニアプログラマーなど、部下の判断に拒否権を出せる上司が、それを取り消すようにすればよい。

  • ソフトウェアは人を助けるためにある。

  • ソフトウェアの管理が難しくなると(ソフトウェアデザインの目的の一つである)人を助けることを続けるのが困難になる。

  • 総じて、デザインによって、物事が単純化される代わりに複雑化していたら、オーバーエンジニアリングが行われている。

  • コードに他のコードを「使わせ」て情報を集中させるように知恵を絞れば絞るほど、デザインは良くなる。これもまた、プログラミングで知性が本当に問われる場面の一つだ。

  • どのようなソフトウェアも、その管理のしやすさは個々の部分の簡潔性に比例する。つまり、部分それぞれを簡潔にできていれば、将来の変更がさらに容易になる。管理を完全に簡単にすることは不可能だが、それを目指して努力しなければならない。全体を変更するか、困難を取り除いた無限に新しいコードか、の選択だ。

  • 平均的な規模のコンピュータプログラムも、また、どのような人間も、そのすべてを一度に把握することなどはできないほど複雑だ。人間は部分ごとに理解していくことしか出来ない。

  • プログラム全体は常に、巨大で複雑な構造をしている。そのため、それを見直す際には部分ごとに理解できるものであることが大事になってくる。部分が簡潔であればあるだけ、誰が見てもそれを理解できる可能性は高い。これは、コードを他の人間に託す場合や、しばらく離れていたコードを他の人間に託す場合や、しばらく離れていたコードの前に何年かぶりに戻ってきたとき、以前自分が何をしたのかを見直す場合に、特に重要となる。

  • 長い目で見て効率的だと言えるのは、複雑なものではなく簡潔性を備えたものなのだ。

  • コードをシンプルにすることだ。これなら未来を予測しなくても可能だ。

  • 事前に少々の時間を費やして簡潔にしておくことで、後で多くの時間が節約できる。

  • これ以上はないほど、アホでもわかるほど簡潔にすること。

  • 簡潔性の大部分を占めるのは、一貫性だ。ある箇所で一つのやり方を採ったのであれば、そのやり方をコードのすべてに適用する。 もちろん一貫性と簡潔性があるに越したことはないが、完全に簡潔だとは言えないから、せめて一貫性は保つべきだ。

  • 良いコメントをコードに入れるのは、読みやすさに大きく貢献する。しかし、一般的には、コードのある部分が何をしているかをコメントに入れる必要はない。それは、コードを読めば明白のはずだからだ。コードを読んでも明白でない場合、コードをより簡潔にすべきだ。コードを簡潔にできない場合にかぎり、コメントで動作を説明すればよい。

  • コメントを挿入する本当の目的は、なぜそのようなことをしたのかを、理由が明白でない場合に説明することだ。
  • 素人の開発者をたくさん集めるより、ベテランの開発者の小さなグループのほうが成功する可能性が高い。

  • 自分の仕事を完全には理解していない開発者は、得てして複雑なシステムを開発しがちだ。

  • 劣悪なデザインでは新機能を追加するごとに、コードの複雑性がその分だけ追加されるのでなく、倍加される

  • 根本的な問題は、コードが散らかってしまっていることだ。だからそれを整理して既存のコードを簡潔にすれば、新機能の追加も同じくらい簡潔にできるようになるだろう。

  • 実装にかかる作業量よりも管理にかかる作業量を減らすほうが重要だ

  • 不具合発生率の法則:プログラムに不具合を作ってしまう確率は、そのプログラムに加える変更の大きさに比例する。

  • 未来についての予言はまったくせずに、いますぐにわかる現在の情報を元にすべてのデザイン上の決定を行うのが最も安全だ。