フレームワークを学ぶのではなく、アーキテクチャを学ぶ

しばらく前、私は興味深い会話をしました。同僚がAngularを積極的に擁護し、Web開発をスピードアップすると言いました。 複雑なWebサービスを10年以上開発してきました。Microsoft、キプロスのSpotware Systemsで働いていましたが、現在はシリコンバレーからスタートアップアプリケーションを作成しています。 しかし、彼は恐竜のように感じました。なぜなら、彼はその時点までフロントエンドフレームワークを使用する意味がわからなかったからです。しかし、これはすでに主流であることが判明しました。 2014年が来たとき、Angular、Knockout、Backboneの世界に突入しました。これは、最終的にそれらを拒否し、同僚にも同じことを勧める理由です。



Angularには多くの問題があり、主な問題の1つはデバッグであることがわかっています。 文書化されていないエラーが表示されると、stackoverflowのみが保存され、正確に何が発生したか、そして最も重要なのはどの場所であるかを探す必要があります。 BackboneとKnockoutにも欠点がありますが、多くの利点が失われるため、使い続けています。 そして正直に言うと、彼らは代替案を見ていないからです。 そして、代替手段があります、彼らはそれを忘れました。



古いプログラミングの原則を思い出してください-各モジュールは1つの機能を実行する必要があります。 彼が2つ以上を実行する場合-それは断片に分割する必要があります。 なぜそうなのか、なぜこれに従うのか、誰もが膨大な数のオープンソースで自分自身で読むことができるのです。 したがって、既存のすべてのフレームワークはこの原則に違反しています。 さらに言いますが、フレームワークのアプローチ自体はそれに違反しています。 フレームワークはフレームワークに私たちを押し込み、「ベストプラクティス」に従うことを余儀なくされます。ベストプラクティスのみが絶えず進化しており、クリエイターの小さなグループは、どのプラクティスがアニメーションの小さなプロモーションページまたは複雑なロジックの管理パネルに普遍的に適しているかを単に知ることができませんデータ管理、および高いパフォーマンス要件を備えたメディアサイト用。 そこからベストプラクティスを収集できるのは、プログラミングがまったく初めてで、フレームワークの分野に慣れていない場合だけです。 しかし、私はあなたに他のアドバイスをします-ベストプラクティスを取りますが、フレームワークは仕事から離れます。 意味を説明します。



フレームワークは非常に大きく、再現が非常に難しいようです。 これは実際には単なる標準パターンのセットです 。 たとえば、Observerパターンは、バックボーンモデル、AngularおよびKnockoutデータバインディングで使用され、かなり大きな「Wow！」を生成します。 しかし、これは、30行のコードのJavaScriptで実装できる、または数千の既製オプションの1つをダウンロードできる、よく知られたパターンです（ちなみに、これらはすべて同じで、パターンの原則が1つしかないため、メソッドの名前のみが異なります）。 他のフレームワークコンポーネントも同様の方法で構成されます。 多くの場合、原則を理解すると、たとえば、小さなコンポーネントのフレームワーク内でMVPを実装するなど、これらのメソッドがコントローラーであり、これらのプロパティがモデルなどであると精神的に分離するなど、通常はゼロ行のコードのみを記述できます。



ケーススタディ：私はかつてスペインの会社でインタビューを受けました。 ライブコーディングモードで1時間でテストタスクを実行し、できる限り1ページのドキュメントアプリケーションを作成する必要がありました。 JavaScriptでモジュラーライブラリのみで完全に成功しました。 テストを書くのに少し時間がかかりました。 人々は、フレームワークなしでページ切り替え、複雑なインタラクティブ要素などを使用してルーティングを実装することがどのように可能であったかを理解していませんでした。 私と同じように、この業界に10年間勤めている人ですが、原則ではなく特定のソリューションを研究しました。



フレームワークを学習する場合、新しいソリューションに切り替えるときに再学習する必要があり 、それらは常に表示され、 経験のほとんどが消去されます。 原則を勉強しても、それらは残ります。 ライブラリを使用して、5年前に記述されたクラスを作成します。 ほぼ同時期に記述されたモジュールインジェクター、オブザーバー実装。 それぞれが正確に1つの機能を実行し、それを適切に実行します。 「オブザーバー」は「オブザーバー」であり、これはコードではなくパターンであるため、フレームワークで起こるように、あるコンポーネントを別のコンポーネントに変更したいと思ったことはありません。 パターンはタスクに応じて組み合わせることができますが、変更されません。 もう1つの古い原則は、コードを補足することはできますが、変更はできないということです。 その正当性は、グーグルや4人のギャングの本でも簡単に見つけることができます。 このロジックに従って、フレームワークまたはライブラリに2番目、3番目、10番目のバージョンがある場合、一部の機能が削除され、一部が変更されます。これは最初は悪質な製品です。 コードを変更する唯一の正当な理由は、新しいブラウザーに適応することですが、パブリックメソッドは決して変更しないでください。



プログラミングはマーケティングの犠牲者です。 すべての問題を解決する魔法のボタンが約束されています。 多くの人々がその上に座って、穀物をもみ殻から分離するために、複合体を成分に分解することができなくなっているという料金だけです。 フレームワークを使用しますか？ はい、後でメンテナンスする必要のない製品を作成する必要がある場合。 しかし、完全な自殺は、少なくとも1〜2年生きて発展するサービスでそれらを使用します。 この間、フレームワーク全体に含まれるよりもはるかに多くのコードを記述し、その制限に何度も遭遇します。 松葉杖を書いて普遍的なものを自分で修正するのに費やす時間は、不器用なフレームワークの代わりに必要なコンポーネントのみのセットを実装するのに十分すぎるでしょう。 これはサイクリングではなく、ライブラリを使用しますが、状況に応じて、単一の事前定義された方法ではなく、それらを組み合わせます。 フレームワークでは、拡張機能も接続できますが、APIを使用してBackboneモデルを取得する場合はどうなりますか。 またはまったくフェッチしません。 または、localStorageから取得します。 日付とフラグに応じて更新の複雑なロジックがまだある場合。 そして、フェッチ後、同じモデルのプールを別のサーバーに送信する必要があります。 どの機能が発生するかはわかりません。 そして、そのような状況では、バックボーンを使用しますか？ その機能の5％があり、残りは松葉杖とカスタムロジックです。 同時に、アーキテクチャの原則を理解することで、このタスク専用に機能するソリューションを作成することは難しくありません。 また、変化する要件に柔軟に対応できるようにします。



ほとんどの場合、プログラマーは印刷せず、考えます。 また、デザインパターンを使用して考えることは効率性に優れています。 通常、私は興味深い建築的解決策を求めて新しいライブラリのパブリックメソッドを読みました。 何かの実装が明確でない場合、コードを見ることができますが、原則として、アイデア自体が重要です。 たとえば、プロミスは10分で実装されますが、その効果は何ですか。 したがって、フレームワークを学ぶのではなく、アーキテクチャを学ぶ。



PS：この記事は意図的に挑発的であり、フレームワークには良い点がありますが、無知を養います。 人がフレームワークなしでは問題を解決できず、何日も何週間も仕事に追われているのは残念です。 実際、それは簡単です。正しいこと、アーキテクチャの決定に注意を払えば、これはまさに私が伝えたかったアイデアです。 この記事が、特に初心者にとって有用であり、ここで説明するアプローチにより、将来、よりクールな専門家になることを願っています。