(CJP) 私はかつて、社内フレームワークを作成して維持する会社で働いていました。 10 年間で、おそらく約 250 の Web サイトとアプリケーションを作成しました。 多くの欠点にもかかわらず、同社は単純な理由でフレームワークを使用し続けました。
その制御のおかげで、オーバーヘッドなしでフレームワークを独自のニーズに合わせることができました。 また、コミュニティが支援する人気のあるフレームワークを使用することは、ほとんどの場合、独自の を作成するよりも優れた選択肢であると私は主張しますが、その理由のいくつかは理解できます。
ただし、最終的に、彼らは最初にやろうとしていたことを作成することに完全に失敗しました. フレームワークのコア開発者は、ニーズに合わせて特別に作成されたツールではなく、柔軟性を求めることがよくありました。フレームワークをオープンソース化し、人気が高まることを夢見ていたため、できるだけ多くのケースを処理して、できるだけ多くのユーザーにリーチする必要がありました。 そのため、柔軟性と構成が優先されることがよくありましたが、それらが会社のプロジェクトに大きな価値をもたらすことはめったにありませんでした。 コア開発者は、それほど技術的でないマネージャーを常に説得することができました。 しかし実際には、このフレームワークの設計と柔軟性は、私と同僚にとって負担になるだけでした。
残念ながら、この「高度な構成可能性と柔軟性」という考え方は、ソフトウェア設計では一般的です。 理由はわかりませんが、どういうわけかプログラマー (私も含めて) は、考えられるすべての結果を説明する必要があると考えることがよくあります。 私たちの多くは、書いているコードが特定のエッジ ケースの中で最も特殊なケースを処理できない場合、聴衆を失うのではないかというある種の恐怖に対処しています。 非常に非生産的な考えです。
最近、ソフトウェア設計に対する意見主導のアプローチを高く評価するようになりました。 特にオープンソースの世界では、他の人が使用するコードを書いています。 私は以前、「このパッケージの人気を高めたいのであれば」、より柔軟にコードを書く必要があると自分に言い聞かせていました。
もう信じられません。
最近では、複数の選択肢を提示するよりも、問題を解決する 1 つの方法を好みます。 オープンソースのメンテナーとして、私が思いついたソリューションを誰もが私ほど気に入っているわけではないことを認識しています。 しかし最終的に、仕事が完了した場合、私のコードが信頼性が高く、明確で有用である場合。 苦情はほとんどありません。 そのため、柔軟性には多くの場合支払う価値のない代償が伴うことに気付いたとき、私は意見主導のデザインを好むようになりました。
ところで、恩恵を受けているのは私だけではありません。 私のオープン ソース コードのユーザーが何かを行う方法が 1 つしかない場合、最終結果に影響を与えない細かい決定について心配する必要はありません。 そして、それは私にとって優れたソフトウェア設計です。プログラマーが本当に重要な決定に集中し、プロジェクトやクライアントに価値を提供できるようにします。 不必要な詳細に時間を無駄にする代わりに。
読んでくれてありがとう！ この投稿は、開発者としての私自身および個人的な経験について書いている「開発日記」シリーズの一部です。 もう少し読みたいですか？
このブログの最新情報を知りたい場合は、私をフォローしてください。
Twitter上で または私のニュースレターを購読してください：