英語で読む「達人プログラマ#2」

週に1章ペースで読んでる達人プログラマ。2章はページ数も一番多い章で大変だった。

We feel that the only way to develop software reliably, and to make our developments easier to understand and maintain, is to follow what we call the DRY principle:

2004年ごろにリリースされたRuby on Railsでも脚光を浴びたDRYは、1999年に出版された「達人プログラマ」で紹介されたコンセプトだ。

Imposed duplication. Developers feel they have no choice—the environment seems to require duplication.
Inadvertent duplication. Developers don't realize that they are duplicating information.
Impatient duplication. Developers get lazy and duplicate because it seems easier.
Interdeveloper duplication. Multiple people on a team (or on different teams) duplicate a piece of information.

重複は、仕様として課されているもの、開発者が無意識で盛り込んだもの、開発者の怠惰で盛り込まれたもの、開発者間で盛り込まれたものの4つがあり、それぞれの背景を解きほぐしながら、いかに重複を排除していくかが2章のポイント。

As the helicopter example illustrates, nonorthogonal systems are inherently more complex to change and control. When components of any system are highly interdependent, there is no such thing as a local fix.

もうひとつ、「直交性(orthogonal)」も丁寧に解説されていた。一方の値を変化させたら、もう一方の値も変わってしまうのは扱いが難しい。本文ではヘリコプターの操縦を、直交性ではない例として上げていた。

This layered approach is a powerful way to design orthogonal systems. Because each layer uses only the abstractions provided by the layers below it, you have great flexibility in changing underlying implementations without affecting code.

レイヤごとに分離させるというのは、直交性を持たせるためによい。

Tracer bullets work because they operate in the same environment and under the same constraints as the real bullets. They get to the target fast, so the gunner gets immediate feedback. And from a practical standpoint they're a relatively cheap solution.

Tracer Bullet(曳光弾)もプログラマ界隈で耳にする言葉かもしれない。普通の弾丸は、どこを飛んでるかわからないが、普通の弾丸に混じって軌跡が光って見える弾丸を混ぜて、ターゲットに向かって弾丸が飛んでいるかを見分けるのに使う。この前後にプロトタイプなど触れているが、Tracer Bulletの役割として、実際の環境で使われることを上げている。

その他、ドメイン言語なども触れられ、sendmail.cfやWindowsのリソースファイルなどが例に出てきたが、このあたりの状況は今は変わってきているだろう。

というわけで、あと3章から8章まで、今年のうちに読み切ろう。

この記事が気に入ったらサポートをしてみませんか?