私が自分で書いたフレームワークを使用する必要がある理由 (そしてあなたもそうすべきです)

写真: Anton Repponen

注: この記事の内容は広く適用可能ですが、この記事は主に経験豊富な開発者を対象としています。自分が何をしているのかを理解していない限り、誰もが独自のフレームワークを作成して維持することはお勧めしません。

私たちの PHP コミュニティでは、開発者のアイデンティティは、使用する言語やフレームワークと密接に結びついていることがよくあります。良くも悪くも、私たちのキャリアはテクノロジー プラットフォームに結びついており、そのプラットフォーム、その文化、そしてそれをサポートするツールに多大なエネルギーを投資しています。

ただし、ツールのライフサイクルはプログラミング言語自体よりもはるかに短いです。 PHP コミュニティでは、数え切れないほどのフレームワークが誕生しては消えていき、今後もさらに多くのフレームワークが誕生し、人気を博し、最終的には消え去っていきます。これは物事の自然な順序です。

フレームワーク自体は重要ではないため、これは実際には大したことではありません。重要なのは、フレームワークに含まれる一連の原則と、開発実践において私たちが何を信じているかであるからです。

フレームワークはソフトウェア開発に対する独自のアプローチを表しており、フレームワークの管理者がソフトウェアがどうあるべきかの例を提供します。ユーザーは、義務からか認識からかにかかわらず、フレームワーク保守者の開発哲学を信じて採用します。

しかし、現在私たちが受け入れているパラダイムは将来新しいパラダイムに置き換わる可能性があり、フレームワークは常に変化しています。

最適なフレームワークを見つけるために何年も努力して失敗しましたが、私にとって本当に重要なのは正しいパラダイムではなく、正しい実践であることに気付きました。このため、私は自分自身のフレームワークを開発、維持、使用する必要があることに気づきました。それは、その瞬間に役立つパラダイムの種類ではなく、私が信じている一連の原則を表すフレームワークです。

正直に言うと、私が使用しているスケルトンコードをフレームワークと呼ぶのは少し恥ずかしいです。コアとなる機能のほとんどは自分で実装していないためです。実際、私は他にも多くのパッケージを採用しており、それらのパッケージが表すベスト プラクティスは非常に役に立ちます。私自身のフレームワークは、これらのパッケージをまとめる「接着剤」コードとして機能します。

これが現代のプログラミングの美しさです。異なるパッケージを統合して新しいものを作成するのが簡単です。どのフレームワークやライブラリでも、すべてを受け入れる必要はありません。ここから少しだけ、またはそこから少しだけ取り入れて、役立つと思われる部分だけを使用することができます。これは、私が初めて PHP を使い始めたとき、Composer を手に入れるまでは想像するのが難しいことでした。

私は、特定のフレームワークや例ではなく、自分にとって重要な原則と実践を受け入れることに重点を置きました。このトリックは私にとってはうまくいきます。

忙しい一日の終わりに最も重要なことは、コードが読みやすく、保守しやすく、正確であることです。現在人気のあるパラダイムはいつか置き換えられるでしょうが、コードの品質を測定する基準は存続します。

したがって、いわゆる完璧なフレームワークを探すのをやめ、ベスト プラクティスとそれを自分の用途に適応させる方法に焦点を当てる時期が来ました。

私は独自のフレームワークを作成、保守、使用することに誇りを持っています。