フレームワークのジレンマ

開発者にとって、物事をスピードアップし、信頼性を維持したいときに最初に手に取るのは、通常フレームワークです。フレームワークは、すべての問題を解決し、開発をより速く、より簡単に、より効率的にする完璧なソリューションであるかのように語られることがよくあります。しかし、ある程度の経験があれば、フレームワークが万能のソリューションではないことはご存知でしょう。適切なものを選択すれば作業を効率化できますが、間違った選択をすると、後々頭を悩ませることになり、迅速に行動する必要があるときに作業が遅くなる可能性があります。

このブログ記事では、フレームワークの選択と使用に伴う実際の課題と戦略について詳しく説明します。潜在的な落とし穴、その回避方法、フレームワークを使用する場合でもコードベースの柔軟性を維持する方法について説明します。

自分が知らない間に関係を築いていた

フレームワークにコミットすることは、長期的な関係を築くことに似ています。そして、それは軽く考えるべきものではありません。単純なライブラリや小さなユーティリティとは異なり、フレームワークには意見が伴います。しかも、その意見は数多くあります。フレームワークは、好むと好まざるとにかかわらず、アプリケーションに構造と方法論を押し付けます。

フレームワークの作成者には、独自の優先事項があることを覚えておくことが重要です。彼らは、あなたの問題ではなく、彼らの問題を解決しています。彼らはあなたに何も負っていません (もちろん、社内のフレームワーク チームに仲間がいる場合は別ですが、その場合は幸運です)。特にプロジェクトの深いところで事態が悪化すると、大変なことになるかもしれません。今、あなたはそれを修正するか、最悪の場合は完全に取り除くしかありません。

楽しくないですよね？

したがって、フレームワークに縛られる前に、それが実際に自分のニーズに合っているかどうかを確認してください。そうでない場合は、運に任せていることになります。

FAANGの問題

作者は、FAANG が MAANG、MANGA になったのか、それとも私たち全員が今はアニメの中にいるだけなのか、まったくわかりません。

ここで経験が本当に重要になります。企業が急速に成長すると、既成のソリューションでは対処できない課題に直面することがよくあります。これらの問題の規模により、企業はカスタム データベース、ETL エンジン、BI ツールなど、独自のツールを作成する必要に迫られます。Google、LinkedIn、Spotify、Netflix などの大手テクノロジー企業が先頭に立って、私たち一般が利用できるツールを構築し、オープンソース化してきました。

しかし、ここで問題なのは、これらのツールは普遍的に適用できるように作られたわけではないということです。ほとんどの企業が遭遇することのない特定の問題を解決するために作られたのです。大企業で働いたエンジニアは、こうした課題への対処に慣れています。彼らは、私たちのほとんどが想像することしかできない規模で機能するソリューションを構築してきました。そのため、彼らが中小企業に移ったとき、フレームワークやツールに関する決定は、これらのテクノロジーの威力と落とし穴の両方に対する深い理解に基づいています。

フレームワークに対する反発

最近、ちょっとした反乱が起こりつつあります。フレームワークに飽き飽きしている人たちがいるのです。特に JavaScript の世界では、開発者は絶え間ない変化にうんざりしています。おそらくあなたも見たことがあるでしょう。メジャー アップデートがリリースされるたびに、最新の状態を保つためにコードベースのかなりの部分を書き直さなければなりません。そして、終わりのない破壊的変更のサイクルについては、話すまでもありません。

このフラストレーションから、よりシンプルで安定したスタックが復活しました。最先端の技術にとどまることよりも、物事を成し遂げることを優先する開発者の間で、バニラ HTML、CSS、jQuery、PHP、SQLite などが復活しています。確かに、少し「古い」ように感じられるかもしれませんが、時代遅れというわけではありません。よりシンプルなスタックであれば、反復を高速化し、さらに迅速に出荷することができます。もちろん、React、Node.js、Flask などの新しいフレームワークにも適所がありますが、すべての凝った機能が必要ない場合もあります。うまくいくものに固執することで、多くの頭痛の種を回避できることもあります。

フレームワーク産業複合体？

フレームワークは... 過大評価されつつあるのでしょうか? 一部のフレームワークは、開発者の実際の問題を解決するためというより、ベンチャーキャピタルの資金を誘い込むために設計されたツールのように感じられることに気づかないわけにはいきません。まるで、開発者をこれらのフレームワークに押し込むエコシステム全体があるようですが、後になって、規模が大きくなると高価なプラットフォームに縛られることに気付くのです。確かに、Databricks などのフレームワークはオープンソースで最初は無料ですが、成長するにつれて、エンタープライズ ソリューションへと誘導されます。そして突然、ホスティングと運用のコストが天井知らずに膨れ上がり、シンプルな VPS で十分だったかもしれません。

ちょっと罠のような気がしませんか？

枠組み決定の延期

ここで私が信じているアドバイスを一つ。フレームワークの選択を急がないでください。アーキテクチャが完全に具体化されるまでコミットしないでください。

フレームワークは最初に心配するものではなく、最後に心配するものです。

まず、アーキテクチャが堅牢であることを確認します。コア コンポーネントとそれらがどのように相互作用するかを把握します。それがわかれば、フレームワークがどこに適合するか、あるいはそもそも適合するかどうかを明確に理解した上でフレームワークを評価できます。

このアプローチにより、設計が堅牢になり、特定のニーズに適合することが保証されます。フレームワークを検討する段階になると、アーキテクチャを制限することなく、フレームワークによってアーキテクチャを強化できる場所を明確に把握できるようになります。

フレームワークの使用に踏み切る前に、自分自身に問いかけてください。本当にそれが必要なのでしょうか?確かに、フレームワークは自動化と利便性のレイヤーを追加できますが、独自の制限も伴います。アプリケーションに固有の要件がある場合、フレームワークはそれらにうまく対応しない可能性があります。

制限に対する長期的なメリットについてじっくり考えてみましょう。

フレームワークを消耗品にする

フレームワークがリスクに見合う価値があると判断した場合は、簡単に交換できることを確認してください。はい、その通りです。柔軟性を組み込むことで、後でフレームワークを破棄する必要が生じても、大変な作業にはなりません。方法は次のとおりです。

依存関係を抽象化する

フレームワークの汚い手がコア コードに介入しないようにします。インターフェイスを使用してフレームワークの機能を抽象化し、ビジネス ロジックがフレームワークに直接依存しないようにします。

機械学習に TensorFlow を使用するとします。アプリケーション全体に TensorFlow コードを埋め込むのではなく、インターフェースを定義して整理された抽象的な状態を保ちます。

 from abc import ABC, abstractmethod import tensorflow as tf class ModelTrainer(ABC): @abstractmethod def train(self, data): pass class TensorFlowTrainer(ModelTrainer): def train(self, data): # TensorFlow-specific training logic model = tf.keras.models.Sequential([...]) model.compile(optimizer='adam', loss='sparse_categorical_crossentropy') model.fit(data, epochs=5) return model

こうすることで、コアロジックは TensorFlow と密に結合されなくなります。別の機械学習フレームワークに切り替える必要がある場合は、実装を交換するだけで済みます。

依存性注入（DI）はあなたの味方です

次に、依存性注入 (DI) について説明します。この手法を使用すると、インターフェイスの特定の実装をクラスに注入して、コードベースを分離し、モジュール化することができます。

 class TrainingPipeline: def __init__(self, trainer: ModelTrainer): self.trainer = trainer def execute(self, data): return self.trainer.train(data) # Inject the TensorFlowTrainer implementation pipeline = TrainingPipeline(TensorFlowTrainer())

これで、コードは柔軟になり、テストが容易になり、将来何が起こっても対応できるようになります。

制御の反転（IoC）を採用する

究極の柔軟性を実現するには、制御の反転 (IoC) でレベルアップしましょう。このパターンを使用すると、構成ファイルまたはコード内の一元化された場所で実装を指定できます。これは、フレームワークに依存しないアーキテクチャの最高の機能です。

構成ベースのアプローチでこれがどのように機能するかの例を次に示します。

 # config.py class Config: TRAINER = 'my_project.trainers.TensorFlowTrainer' # main.py import importlib class TrainingPipeline: def __init__(self, trainer_class: str): module_name, class_name = trainer_class.rsplit('.', 1) module = importlib.import_module(module_name) trainer_cls = getattr(module, class_name) self.trainer = trainer_cls() def execute(self, data): return self.trainer.train(data) # Inject the trainer specified in the configuration from config import Config pipeline = TrainingPipeline(Config.TRAINER)

これで、TensorFlow を別の機械学習フレームワークに置き換える必要が生じた場合は、構成を更新するだけで続行できます。面倒なこともなく、問題もありません。

結論

フレームワークは、あなたのアーキテクチャーに奉仕するものであり、それを指示するものではないことを忘れないでください。慎重な計画と戦略的な抽象化により、長期的な依存関係に陥ることなくフレームワークのメリットを享受できます。重要なのは、コントロールを維持することです。次にフレームワークに飛び込むときは、一歩下がって、ここで主導権を握るのはあなたであることを思い出してください。

読んでいただきありがとうございます！

ご質問はございますか？以下にコメントを残して、素晴らしいディスカッションを始めましょう！

私のブログをチェックするか、 Twitterで挨拶に来てください👋、または私の Telegram チャンネルに登録してください。最高の計画を立ててください!