アンチパターンとパターン：違いは何ですか？

業界用語はソフトウェア開発業界に浸透しています。ベストプラクティス。アーティファクト。スコープクリープ。これらの用語の多くはあまりにも一般的であり、使い過ぎと呼ばれることもあり、それらが明白に見えるため、私たちはそれらを理解していると思い込むのは簡単です。それでも、私たちはそれらを注意深く検討することで新たな深みを見つけることがあります。この投稿では、「パターン」とそのやや知られていない対になっている「アンチパターン」について考えてみましょう。

デザインパターンとは？

私たちは一般的にパターンが何であるかを知っていますが、ソフトウェア工学におけるその重要性を理解するためには、まずアルゴリズムについて話すことが重要です。アルゴリズムとは、アイテムのリストをソートしたり、データを効率的に保存したり、データセット内のアイテムの出現回数をカウントしたりするなど、一般的なタスクを実行する方法のことです。アルゴリズムはソフトウェア工学における最も古く、基本的な概念の一つです。実際、この著者の机の上には、多くの人々によってこの主題に関する最も重要な作品の一つと見なされている Fundamental Algorithms （ドナルド・クヌース著）のコピーがあります。この小さな本の初版は1968年に著作権が取得され、50年前のことです。現代のプログラマーにはほぼ認識できないテキストであり、主にその解法の微積分に基づく証明を強調し、唯一のコード例はAlgolやMIXアセンブリのような不明瞭で時代遅れの言語で提供されています。それにもかかわらず、カバーされた多くの内容は現在でも使用されています：シングルリンクリストやダブルリンクリスト、ツリー、ガーベジコレクションなど。詳細は便利なライブラリに埋もれていることが多いですが、概念は同じです。これらのアルゴリズムは、一般的なソフトウェア工学の問題に対する有効な解決策として、50年以上も有効であり続けており、今でも力強く存在しています。デザインパターンの議論は、良好なデザイン原則の重要性に触れない限り不完全です。ソリッドデザイン原則についてもっと読む。

パターンの種類

「パターン」は、アルゴリズムのより一般的な形態と考えることができます。アルゴリズムが特定のプログラミングタスクに焦点を当てる場合、パターンはその領域を超え、欠陥率を低下させたり、コードの保守性を向上させたり、大規模なチームがより効果的に協力できるようにすることなどの課題を考慮する場合があります。一般的なパターンには以下が含まれます：

• ファクトリー – オブジェクトの作成者が事前にすべてを知る必要がないようにする初期のオブジェクト指向プログラミング概念の進化。フローチャートアプリケーションは「形状」を作成し、整理することに焦点を当てることで拡張可能なステンシルライブラリをサポートすることができ、ステンシル自体が単純な四角形と複雑なネットワークルーターアイコンの作成の詳細を管理します。
• Pub/Sub – アプリケーションを「デカップリング」するためのメカニズム。送信者が受信者に直接メッセージを送信するのではなく、送信者がトピックやキューにメッセージを「公開」します。一つ以上の受信者はメッセージを受け取るために「サブスクライブ」することができ、メッセージキューは伝送エラーやメッセージの再送信などの詳細を処理します。これにより、送信アプリケーションと受信アプリケーションの両方が簡素化されます。
• 公開鍵暗号 – 二者が安全に通信でき、かつ傍受されることなく、秘密の暗号鍵の交換を事前に取り決める必要がないメカニズム。各当事者はペアの鍵（公開鍵と秘密鍵）を維持し、公開鍵は必要に応じて取得されることが多く、事前に交換されることはありません。
• アジャイル – 顧客満足を重視し、柔軟性と協力の必要性を受け入れ、シンプルで持続可能な開発プラクティスの採用を促進する一連の指針原則を内包する哲学。

これらは業界で一般的な多くのパターンのうちの4つに過ぎず、この中でも、非常に技術的なものから、よりプロセス指向のものまで幅広く存在することがわかります。ファクトリーは非常にコード指向のパターンですが、pub/subはよりアーキテクチャ的性質を持っています。そして、公開鍵暗号は広範な影響を持ちますが、その操作をサポートするライブラリは、現在一般的に使用されているほとんどのプログラミング言語で利用可能であり、一般的には実装が簡単です。

アジャイルパターンの誤解

スペクトルの反対側では、「アジャイル」は依然としてやや捉えどころがなく、開発者、プロジェクトマネージャー、および他の利害関係者の間で、正確に何を意味し、どのように実装されるべきかについての分裂の道具であり続けています。これは使い過ぎられていますが、理解されていない用語の素晴らしい例です。「ウォーターフォール」や「スタンドアップ」と「アジャイル」が同じ文に存在するのは、ほとんど常に誤用の例です。アジャイルは哲学であり、ソフトウェア開発の方法論ではないため、ウォーターフォールと直接比較することはできず、スタンドアップのようなプロセスコンポーネントを直接指摘することもできません。（それらはアジャイル原則を実装する方法論であるScrumのコンポーネントですが、アジャイル自体を表すものではありません。）狭くても広くても、技術的でもプロセス指向でも、これらのパターンの良好な作業知識は技術者のツールボックスの重要なコンポーネントです。

アンチパターンとは？

「パターン」が一般的なソフトウェア工学の問題に対する知られている解決策であるならば、「アンチパターン」は単にその反対になるのでしょうか？非アジャイルな開発方法論や、密結合したアプリケーション？実際には、アンチパターンは単に正しいことをしないという概念を取り入れるだけでなく、一見正しいと思われる選択肢のセットも含んでいますが、長期的には問題を引き起こします。ウィキペディアは「アンチパターン」の意味を次のように定義しています：

「アンチパターンは、通常効果がなく、非常に逆効果になるリスクがある繰り返し発生する問題に対する一般的な反応です。」

「一般的な反応」という言及に注意してください。アンチパターンは偶発的な間違いではなく、常に良い意図から始まります。通常のパターンと同様に、アンチパターンは広範囲にわたることも非常に特定的であることもあり、プログラミング言語やフレームワークの領域においては、文字通り何百ものものを考慮することができます。ここでは、この著者のお気に入りの高レベルの個人的なアンチパターンの例をいくつか挙げます。

ソフトウェア面接におけるホワイトボードプログラミングチャレンジ

Ruby on Railsの創始者であり、Basecampの創設者兼CTOであるデビッド・ハンソンはかつてツイートしました。「こんにちは、私の名前はデビッドです。私はホワイトボードでバブルソートを書くことに失敗するでしょう。私は常にインターネットでコードを調べます。私は謎解きはしません。」ここでのアンチパターンは、面接中に誤った指標を評価することです。典型的なタスク割り当ては「登録時に郵便番号検索を追加する」ですが、面接の質問は「この配列を擬似コードを使って関数型プログラミングの概念でソートしてください。」のように聞こえます。アンチパターンの「良い意図」の側面を思い出してください。私たちは候補者が価値のある原則をテストしているかのように見えます：基本的な知識。しかし、プログラミングはしばしば非常に実用的な実践であり、理論的な知識に対する焦点は、私たちが文化的な理想を満たす候補者を選ぶことを引き起こすかもしれませんが、そのポジションで成功するために必要な実際のスキルを欠いている可能性があります。言い換えれば、そのポジションで開発者がStackOverflowを定期的に利用するなら、面接中にもそれが利用可能であるべきです（そして使用されるべきです）。宿題やペアプログラミングのチャレンジも探求する価値があります。すべてのパターンとアンチパターンには有効な例外があります。アルゴリズムのライブラリを作成する仕事をする開発者は、メカニズムの背後にある微積分を知っている必要があるかもしれません。この期待を普遍的に適用することが誤りであり、そうでない開発者にも適用することはできません。

モラルハザード

哲学的な文脈において、モラルハザードは個人が自らの決定の結果から切り離されることを指します。これは避けるべき明らかな行動のように聞こえますが、このアンチパターンは多くのSDLCの非効率の根本原因です。従来のQAプロセスを考えてみてください。「チケット」は開発者によって対処され、その後QAにレビューのために渡されてからデプロイされます。ここには2つの問題があります。まず、人員比はほとんど「1開発者対1QA分析者」ではなく、少数の開発者でもQAチームのキャパシティを簡単に超えてしまうことがあります。第二に、これにより開発者は誤りの結果から隔離され、他の個人がリリースされる前にそれらを見つける責任を負うことになります。これはモラルハザードです。このアンチパターンの影響は微妙であることがあります。QAチームが効果的であれば、必ずしも低品質な出力につながるわけではありません。むしろ、見積もりの正確性や目標の達成に関する苦情など、他の領域に現れる可能性が高いです。品質と見積もりの正確性は、開発者が「QAを通過させること」に本能的に焦点を当てるために悪化します。20-30%の控えめな欠陥率でも（多くの組織では楽観的かもしれない数字ですが）、これがチームの生産性に大きな影響を与えることがあります。問題を解決しようとする中で、追加のアンチパターンが発生することもあります。Scrumでは、スプリントを長くするかオープンに保つことが誘惑されるかもしれません。しかし、スプリントは時間の測定であり、出力の測定ではありません。この行為は、その性質を逆転させ、「速度」メトリックなどの他のツールの価値を破壊します。また、チケットをより深くレビューするために長いスプリント計画や事前計画会議が一般的に見られます。しかし、これは本能的なプロセスを科学的なものに変えようと試みており、Scrumのような方法論を実装する目的が最初にこの不可能性を認めるためであったことを忘れています。この問題を解決するためにしばしば効果的な2つのパターンには以下が含まれます：

• 継続的改善の文化を受け入れる：「それが良くなったときに出荷する、正しいときには出荷しない。」（以下の「キャノンボールを磨く」も参照）。これを奨励され、権限を与えられた開発者は、タスクに取り組む方法についてより良い決定を行うことができ、個人的な達成感をより実感できます。
• 開発者が自分の作業製品に対して責任を持ち、Productionのデプロイまで責任を持つようにします。Facebook、Google、その他の業界の巨人は、このアプローチで成功を報告しています。

キャノンボールを磨く

時には「ゴールドプレーティング」や「海を沸かす」とも呼ばれ、完璧な製品を出荷しようとすることは、しばしばプロジェクトのタイムラインやコストを大幅に増加させますが、実際には提供される価値を増加させません。密接に関連するアンチパターンは「ゾンビチケット」であり、バックログの動脈壁にある plaque です。ゾンビチケットは決して高い優先順位を持たず、整理されることはありませんが、タスクの文書記録を失うことを恐れて決して閉じられません。両方の習慣には、サポートするメトリックが幻影であるという問題があります。出荷されていない機能は顧客にとってゼロの価値を持ち、十分な痛みを引き起こさないタスクは優先順位を持たないかもしれません。新しい価値のある機能を定期的に提供するために利用可能なリソースを集中させる方が、非常に少数のユーザーに影響を与える小さな問題を常に振り返ることよりもはるかに良いです。ここでの「パターン」に相当するのは、最小限の実用的な製品（MVP）であり、これはしばしば少し幻影のように終わります。（MVPはほぼ計画されているほど小さくなることはありません。）しかし、MVPを出荷しようとする行為自体が、上記の問題に対する解決策であることが多く、いくつかの遅延が発生しても努力する価値があります。反復的な開発プロセスは、実際のエンドユーザーからのフィードバックによって強化された、価値のある増分を定期的かつ予測可能に提供することを強調しています。

アンチパターンを避ける方法

最良の意図があっても、アンチパターンは人々が経験やベストプラクティスへのアクセスを持たないときに発生します。彼らは、時間と予算に追われて短縮しようと誘惑されるかもしれません。チームは内部または外部のパートナーと十分に協力できない場合があり、コミュニケーションの崩壊が状況を悪化させます。作業を開始する急ぎの中で、初期の計画と設計が無視されることがあります。以下は、私たちが議論したアンチパターンの例を避けるためのいくつかのヒントです：

• ホワイトボードプログラミングチャレンジ： 抽象的な問題をホワイトボードで解決するのではなく、実用的で焦点を絞ったシナリオを作成し、コードサンプルを提供して改善を求める。
  • 候補者と面接官が協力して現実的な課題に取り組むことを検討してください。
  • 候補者が問題を考える様子を評価できるような持ち帰り課題を提供してください。
• モラルハザード： インセンティブをパフォーマンスと長期的な結果に結びつけます。役割と責任を明確にし、個々の所有感を持たせます。
  • リスクを明確にし、オープンなコミュニケーションを促進し、懸念を共有する文化を促進するツールを使用します。
  • 許容されるリスクの周りの限界、プロセス、ガードレールを定義します。
  • すべての利害関係者からのフィードバックを取り入れて監視し、測定します。
• キャノンボールを磨く： 小さな詳細の継続的な洗練を避けるために、プロセスの初期段階で具体的なメトリックとともに「十分良い」を最小限の実用的な製品と定義します。
  • 優先順位を定義し、時間と努力に対する価値を比較します。
  • さらなる洗練が投資に見合うかどうかを判断するために利害関係者を巻き込みます。
  • テストと測定を行い、さらなる洗練に関する意思決定のためのデータを得ます。

さらなるリーディング

業界にはパターンとアンチパターンが書籍を満たすほど存在し、実際に多くの書籍がそれについて書かれています。結局のところ、それらを記憶する必要はほとんどありませんが、特定の言語やフレームワークに特化した開発者は、それらの特定の領域にターゲットを絞ったものを調査することが奨励されるべきです。パターンとアンチパターンについてもっと学びたい方は、私が自分の読書の中で価値があったリソースをいくつか見つけました：

• ウィキペディアの「ソフトウェアデザインパターン」および「アンチパターン」のページは、高レベルなトピックの良い例を提供します。
• SourceMakingの「デザインパターン」および「アンチパターン」は、一般的なソフトウェア工学のタスクに関する有用な具体例を含みます。
• Enough Rope to Shoot Yourself in the Foot: Rules for C and C++ Programming、アラン・ホルブ、マグロウヒル、1995年。この本はCとC++に焦点を当てていますが、カバーされているルールのほとんどはほとんどの現代言語に適用されます。
• プログラミングの旅を始めたばかりで、学ぶべき最高のプログラミング言語を探している方に。

さらに、ほぼすべての言語やフレームワークには、「NodeJSパターン」や類似のものを検索エンジンで検索すれば、利用可能なリソースが数十あります。私は、すべての開発者に、これを特定の分野のために行うことをお勧めします。良いプラクティスと悪いプラクティスの区別ができていると思っていても、アンチパターンに従っていることが時々驚くべきことがあるからです。もちろん、常に最良の意図を持って！

これらの投稿は私自身の見解であり、BMCの立場、戦略、意見を必ずしも表すものではありません。