ゆで過ぎたニンジン
2016年6月23日
私は子供の頃、ニンジンが大嫌いでした。その匂いと食感が嫌だったのです。しかし、家を出て自分で料理をするようになってから、ニンジンが好きになりました。ニンジン自体が変わったわけでも、私の味覚が劇的に変わったわけでもありません。違いは調理法にありました。私の母は、同世代の多くのイギリス人と同じように、料理が得意ではありませんでした。特に野菜の調理は苦手でした。母はニンジンを20分以上茹でるという方法をとっていました。その後、私はニンジンを適切に調理すれば、全く違った体験になることを学びました。
このサイトは料理に関するサイトではなく、ソフトウェア開発に関するサイトです。しかし、私はしばしば、テクニックやツールが、かわいそうなニンジンと同じように、間違った方法で使われていることが真の問題であるにもかかわらず、ひどいものだと非難されていることに気づきます。
いくつかの例を挙げてみましょう。私の友人の何人かは、ストアドプロシージャはバージョン管理されていないため(GetCust01、GetCust02、GetCust02Bなどの名前が付けられている)、災難だったとコメントしていました。これはストアドプロシージャの問題ではなく、人々がストアドプロシージャを使って悪い習慣を実践していることが問題なのです。同様に、TDDが脆い設計につながったという批判は、さらに質問していくと、問題のチームがリファクタリングを行っていなかったことが判明しました。そして、リファクタリングはTDDにおける重要なステップです。
これらはどちらもゆで過ぎたニンジンです。つまり、誤用されている便利なツールです。私は、チームがストアドプロシージャとTDDの両方から価値を得ているのを見てきました。使い方を考慮せずに捨ててしまうと、ツールボックスから便利なツールを失ってしまうことになります。
テクニックの失敗がすべてゆで過ぎたニンジンというわけではありません。リスはどんなに調理しても、切羽詰まっていない人には美味しくならないということを、信頼できる筋から聞きました(この春、リスが私たちの庭でしていることを考えると残念です)。バージョン管理もせずに、共有フォルダでコードを作成しているチームに出会ったとしたら、同様にひどい結果にならないような調理法はありません。
ですから、テクニックが失敗したという話を聞いたら、もっと多くの質問をする必要があります。
- 問題があったのはテクニック自体だったのか、それとも何か他の見落としがあったのか。テクニックはこれに影響を与えているのか?(バージョン管理はストアドプロシージャとは別物ですが、ツールの性質上、ストアドプロシージャでバージョン管理を使用するのは難しい場合があります。)
- そのテクニックは、適していない状況で使用されたのか?(テストがない場合は、大規模な手動リファクタリングを使用しないでください。)ソフトウェア開発は非常に人間的な活動であり、文化や性格のために、テクニックが状況に適さないことが多いことを覚えておいてください。
- テクニックの重要な部分が欠落していたのか?
- 人々は、現実とは一致しない外見上の兆候にばかり気を取られていたのか?このようなことは、スティーブ・マコネルが「カーゴカルトソフトウェアエンジニアリング」と呼んだものです。
- そのテクニックはある規模では有効だが、適用範囲外で使用されているのか?パラケルススの原理、つまり薬と毒の違いは用量であることを覚えておく価値があります。UIを通してシステムをテストすることは、少数のシナリオでは有効ですが、主なテスト方法として使用すると、遅くて脆いテストになり、開発速度が低下するか、無視されることになります。
この点で興味深いのは、特定のテクニックが壊れやすいのかどうか、つまり、正しく適用するのが難しいため、誤った適用を起こしやすいのかどうかということです。テクニックを適切に使用するのが難しい場合、それはテクニックの合理的な制限であり、使用できる状況を減らします。繊細な料理は、熟練したシェフに任せる必要があります。だからといって、それが悪いテクニックというわけではありませんが、適用できるチームがより熟練したチームに限られることになります。これが、コンポーネントの統合を遅らせることの基本的な問題だと私は思います。綿密な仕様に基づいてコンポーネントを開発し、後から統合できるチームもありますが、実際には、それをうまくできるチームは少なく、後からの統合はフグのようなものになってしまいます。
ゆで過ぎたニンジンに注意する必要がある一方で、「どんな方法論も失敗したことがない」という状況にも注意する必要があります。どんな失敗でも(失敗とは何かを知ることができるという前提で)、方法論からの逸脱を見つけることができます。そのため、擁護者は、方法論が守られていなかったため、失敗ではなかったと言うでしょう。ここには真の緊張関係があり、テクニックの根底にあるより深い原則を深く理解しなければ解決できません。重要なのは、そのようなテクニックは厳密に記述できるものではないということです。スパゲッティ・カルボナーラに、考えずに従うことができる正確なレシピが1つもないのと同じです。最終的に重要なのは料理であり、その調理法は優れたシェフにインスピレーションと指針を与えることができますが、ある程度のスキルを持たない人には成功を保証するものではありません。
どんな職業でも、お互いの経験から学ぶことで、より早く進歩することができます。テクニックやツールを使用した人の報告は、自分の仕事で何を試すべきかを判断するために重要です。しかし、単純なレッテルだけでは、判断材料としては usually 不十分です。私たちは、テクニックの適切な使用の遵守を測定できないのと同様に、その成功を測定することもできません。重要なのは、テクニックが失敗したという話を聞いたら、必ず深く掘り下げて、ニンジンが鍋に入れっぱなしになっていないかどうかを確認することです。そうでなければ、価値のあるものを見逃してしまう危険性があります。
私は元々このトピックを「欠陥のあるテクニックの二分法」という見出しで書きましたが、今ではゆで過ぎたニンジンの比喩の方が記憶に残ると思っています。
Further Reading(参考文献)
ロン・ジェフリーズの同様の現象に関する寓話「"野球を試してみたが、うまくいかなかった"」が好きです。