ツールの選択は慎重に – プログラマが知るべき97のこと

Modern applications are very rarely built from scratch.

昨今では、アプリケーションをまったくのゼロから開発することは稀です。

They are assembled using existing tools — components, libraries, and frameworks — for a number of good reasons:

通常は、既存のツール——コンポーネント、ライブラリ、フレームワークなど——を組み合わせて作ります。それは次のような理由からです。

Applications grow in size, complexity, and sophistication, while the time available to develop them grows shorter.

アプリケーションの規模は以前に比べて大きくなり、複雑で高度になってきている。対照的に、開発にかけられる時間は短くなる一方である。

It makes better use of developers’ time and intelligence if they can concentrate on writing more business-domain code and less infrastructure code.

プログラマの時間と能力は、最大限有効に活かす必要がある。つまり、インフラのコードよりも、ビジネスドメインのコードに、時間と能力をできる限り振り向けるべきである。

Widely used components and frameworks are likely to have fewer bugs than the ones developed in-house.

広く使用されているコンポーネントやフレームワークの方が、自前で開発しているものに比べ、バグが少ない傾向にある。

There is a lot of high-quality software available on the web for free, which means lower development costs and greater likelihood of finding developers with the necessary interest and expertise.

多くの高品質のソフトウェアをWebから無料で入手できるようになった。これは、開発コスト削減につながるだけでなく、然るべき知識と技術を備えた技術者と出会う機会を増加させた。

Software production and maintenance is human-intensive work, so buying may be cheaper than building.

ソフトウェアの開発や保守は多くの人手を要し、人件費のかかる仕事である。一般的に言って、新しいものをゼロから作るよりは、すでに存在するものを買った方が安くあがる。

However, choosing the right mix of tools for your application can be a tricky business requiring some thought.

ただ、既存のツールを適切に組み合わせることは、実は容易なことではありません。事前に十分な検討が必要でしょう。

In fact when making a choice, there are a few things you should keep in mind:

その際には、以下のようなことに留意すべきです。

Different tools may rely on different assumptions about their context — e.g., surrounding infrastructure, control model, data model, communication protocols, etc. — which can lead to an architectural mismatch between the application and the tools.

コンテキストに関する前提条件はツールごとに違っている——たとえば、どういうインフラ、制御モデル、データモデル、通信プロトコルなどを前提とするかが、ツールごとに違う。注意しないと、アプリケーションと前提条件が一致しないツールを使ってしまう。

Such a mismatch leads to hacks and workarounds that will make the code more complex than necessary.

そのような不一致があると、対処策、回避策を数多く講じる必要が生じ、コードが必要以上に複雑になってしまう。

Different tools have different lifecycles, and upgrading one of them may become an extremely difficult and time-consuming task since the new functionality, design changes, or even bug fixes may cause incompatibilities with the other tools.

ツールによってそのライフサイクルは異なる。利用しているツールを1つだけアップグレードするというのは、極めて困難で長い時間を要する。機能の追加、設計の変更、あるいはバグ修正などによって、他のツールとの齟齬が生じる恐れがある。

The greater the number tools the worse the problem can become.

利用するツールの数が多くなればなるほど、この問題は深刻になる。

Some tools require quite a bit of configuration, often by means of one or more XML files, which can grow out of control very quickly.

ツールによっては、複雑な設定作業が必要になる場合がある。いくつものXMLファイルを使用した設定が必要なツールも多い。そういうツールは、十分に注意をしなければすぐに制御不能に陥る危険性がある。

The application may end up looking as if it was all written in XML plus a few odd lines of code in some programming language.

多数のXMLファイルで設定を行うツールばかりを組み合わせてアプリケーションを作ると、結果的に大部分がXMLで構成されていて、プログラミング言語で書いたわずかな量のコードを加えただけ、というようなアプリケーションができあがってしまうこともある。

The configurational complexity will make the application difficult to maintain and to extend.

設定作業は極めて煩雑になってしまい、アプリケーションの保守や拡張も困難になる。

Vendor lock-in occurs when code that depends heavily on specific vendor products ends up being constrained by them on several counts: maintainability, performances, ability to evolve, price, etc.

特定のベンダのツールに過度に依存すると、いわゆる「ベンダロックイン」に陥ってしまう。そうなると、保守性、パフォーマンス、拡張性、価格などに制約が生じてしまう。ベンダの動向にどうしても影響されるからだ。

If you plan to use free software, you may discover that it’s not so free after all.

フリーソフトウェアを利用するからといって、全てが無料になるわけではない。

You may need to buy commercial support, which is not necessarily going to be cheap.

商用サポートを受ける場合には、フリーソフトウェアだからと言って、サポート費用が安いとは限らない。

Licensing terms matter, even for free software.

ライセンスに関する条件の確認も重要で、それはフリーソフトウェアを利用する場合でもあてはまる。

For example, in some companies it is not acceptable to use software licensed under the GNU license terms because of its viral nature — i.e., software developed with it must be distributed along with its source code.

企業によっては、GPLソフトウェアの利用が認められないこともある。GPLソフトウェアの派生物は必ずソースコードとともに配布しなければならないという（ウイルスにたとえられる）条項が忌避される。

My personal strategy to mitigate these problems is to start small by using only the tools that are absolutely necessary.

ここまで挙げてきたような問題の発生を防ぐために、私は「まずは最低限のツールだけを導入する」という戦略を採っています。よく検討して、どうしても必要と判断したものだけに絞り込んで導入するのです。

Usually the initial focus is on removing the need to engage in low-level infrastructure programming (and problems), e.g., by using some middleware instead of using raw sockets for distributed applications.

通常、初期の段階で重視するのは、「インフラ関連の低水準プログラミングの手間を省き、問題の発生を防ぐ」ということです。たとえば分散アプリケーションを開発するなら直接ソケットを扱うのではなくミドルウェアを利用する、ということです。

And then add more if needed.

その後も必要になったタイミングで新たなツールを追加していきます。

I also tend to isolate the external tools from my business domain objects by means of interfaces and layering, so that I can change the tool if I have to with just a small amount of pain.

新たにツールを追加する際には、ツールをビジネスドメインオブジェクトから隔離するためのインターフェースやレイヤを導入すれば、ツールの変更が必要になった時の手間が最小限に抑えられるでしょう。

A positive side effect of this approach is that I generally end up with a smaller application that uses fewer external tools than originally forecast.

最後に、ここまで話してきたアプローチには良い副作用があります。当初の予測よりも導入するツールが少なくて済み、アプリケーションも肥大せずに済むのです。