共有は慎重に – プログラマが知るべき97のこと

It was my first project at the company.

それは私が社会に出て最初にかかわったプロジェクトのことでした。

I’d just finished my degree and was anxious to prove myself, staying late every day going through the existing code.

まだ大学を出たてで、自分の能力を証明したくてしょうがなかった頃です。毎晩夜遅くまで会社に残り、既存のコードを読んで色々なことを学んでいました。

As I worked through my first feature I took extra care to put in place everything I had learned — commenting, logging, pulling out shared code into libraries where possible, the works.

そして私は初めて仕事を任されたとき、担当部分の作業にこれまで自分の学んできたことをどうしても実践してみたくなったのです。それは、コメントを入れること、ログをとること、そして、内容が似通っているコードをできるだけライブラリ化することでした。

The code review that I had felt so ready for came as a rude awakening — reuse was frowned upon!

しかし、意気揚々と臨んだコードレビューで私は思い知らされることになります。コードの再利用を安易に促進すると、かえってひんしゅくを買ってしまうのだ、ということを。

How could this be?
どうしてそういうことになったのでしょうか。

All through college reuse was held up as the epitome of quality software engineering.

大学では「再利用」を優れたソフトウェア開発プロジェクトの象徴として教わってきました。

All the articles I had read, the textbooks, the seasoned software professionals who taught me. Was it all wrong?

どんな論文や教科書を読んでもそう書いてあったし、経験豊かなプロのソフトウェア技術者もそう語っていたのに、それらは全部間違いだった、ということでしょうか。

It turns out that I was missing something critical.

考えた結果わかったのは、私が1つ重要なことを見逃していた、ということです。

Context.

それは 「コンテキスト」です。

The fact that two wildly different parts of the system performed some logic in the same way meant less than I thought.

たとえシステム内に同様の処理を行う部分が2つあったとしても、両者のシステムにおける役割が大きく異なっていれば、再利用によるメリットは小さいのです。

Up until I had pulled out those libraries of shared code, these parts were not dependent on each other.

私がコードをライブラリ化するまで、そのコードを利用する部分間に依存関係はまったくありませんでした。

Each could evolve independently.

元々の成り立ちが全然違うコードだったのです。

Each could change its logic to suit the needs of the system’s changing business environment.

従って、状況やニーズが変われば、その後各部分のロジックにはまったく別の変更が必要になる可能性が高いということです。

Those four lines of similar code were accidental — a temporal anomaly, a coincidence.

たとえコードが4行ほどのもので、行っていることが同じだったとしても、それはたまたま一時的にそうなっていただけのことです。

That is, until I came along.

私が入ってくるより前は、むしろ一致していない方が普通だったのです。

The libraries of shared code I created tied the shoelaces of each foot to each other.

私がコードをライブラリ化してしまったことで、それを利用する部分には依存関係が生じました。まるで、一本の靴ひもを、両足の靴に通したような状態になったのです。

Steps by one business domain could not be made without first synchronizing with the other.

ライブラリのコードを1行変更しただけで、その影響は複数箇所に及びます。

Maintenance costs in those independent functions used to be negligible, but the common library required an order of magnitude more testing.

互いに独立していた時なら、該当部分の保守コストは無視できるほど小さかったのに、ライブラリ化してから、変更のたびに大変な手間をかけてテストをする必要が生じました。

While I’d decreased the absolute number of lines of code in the system, I had increased the number of dependencies.

私は、システムを構成するコードの絶対的な行数は減らしたのですが、依存し合う部分を増やしてしまったわけです。

The context of these dependencies is critical — had they been localized, it may have been justified and had some positive value.

依存関係が生じる場合には、そのコンテキストが重要になります。依存関係が生じても、狭い範囲でのことならば、さほど問題は生じず、共有のメリットの方が大きくなったでしょう。

When these dependencies aren’t held in check, their tendrils entangle the larger concerns of the system even though the code itself looks just fine.

しかし、広範囲での依存関係が生じると、システムの様々な部分がそれに巻き込まれることになり、ライブラリのコード自体は良くできていても、デメリットの方が大きくなります。

These mistakes are insidious in that, at their core, they sound like a good idea.

こういうミスはとても厄介です。「再利用」は一般に良いこととされており、確かに基本的には良いことだからです。

When applied in the right context, these techniques are valuable.

コンテキストさえ適切なら、間違いなく有効です。

In the wrong context, they increase cost rather than value.

しかし、コンテキストが不適切だと、メリットよりもコストの方が大きくなるのです。

When coming into an existing code base with no knowledge of the context where the various parts will be used, I’m much more careful these days about what is shared.

私は今では、システム全体の構造がわからないうちは、コードの共有を安易に進めたりはしません。まずは部分どうしの関係をよく見て、どこをライブラリ化すべきかを慎重に考えます。

Beware the share. Check your context. Only then, proceed.

「共有は慎重に。事前のコンテキスト確認を忘れずに」ということですね。