英語で読む「達人プログラマ#3」
3章のタイトルは「The Basic Tools」。テキストエディタやソースコード管理、そしてコード生成まで話がおよぶ。当時はコンセプトだけだったかもしれないが、このときに提唱されたコンセプトが現在では形になってるなぁ、と思いながら読んでみた。
As long as the data survives, you will have a chance to be able to use it—potentially long after the original application that wrote it is defunct.
3章の最初の節「14. The Power of Plain Text」は文字通りPlain Textの有用性を説明しているが、その中で説得力があると思ったのは、もしアプリケーションが滅んだとしてもself describingなデータであれば生き続けるということ。
GUI environments are normally limited to the capabilities that their designers intended. If you need to go beyond the model the designer provided, you are usually out of luck—and more often than not, you do need to go beyond the model. Pragmatic Programmers don't just cut code, or develop object models, or write documentation, or automate the build process—we do all of these things.
その次の節「15. The Shell Games」は文字通り、Shellの話。GUIは画面をデザインした人が想定した使い方に制限されるが、達人プログラマは、それぞれの作業をするのではなく、全部をやる。shellが好きになれない人は、この前後を読むとマインドが変わるかな。
Beware of myopia when debugging. Resist the urge to fix just the symptoms you see: it is more likely that the actual fault may be several steps removed from what you are observing, and may involve a number of other related things. Always try to discover the root cause of a problem, not just this particular appearance of it.
デバッグでは、まずいと思った箇所を直すのではなく、root causeを見つけるようにしましょう。これを実践するための戦略、可視化の手法、チェックリストなどが続く。1章にも登場したrubber duckも再び登場する。
Perhaps you're developing a database application. Here, you're dealing with two environments—the database and the programming language you are using to access it. You have a schema, and you need to define low-level structures mirroring the layout of certain database tables. You could just code these directly, but this violates the DRY principle: knowledge of the schema would then be expressed in two places.
3章の最後は「3. Code Generators」。例えばデータベースを使うアプリケーションを書くときは、その時点で２つの言語を扱うからDRYに反するので、定義を一箇所にまとめてソースコードを生成しましょうという話。まるでRailsのコンセプトを読んでるかのようだ。
次回は４章。ページ数としては折り返し地点だが、契約プログラミングや例外など、ちょっとハードな内容になる見込み。
この記事が気に入ったらサポートをしてみませんか？