Webアプリの「将来性がない」という恐怖

私は、小規模なローカルSaaS WebアプリケーションのWeb開発者です。現在、約半数のクライアントがいます。

アプリケーションの設計を続けると、プロジェクトにいつでもコミットするように説得することがますます難しくなります。これは初期段階で行われました。プロジェクトと既に書いたコードに執着して成長したので、ビジネスが成長するにつれてアプリがうまくスケールしないことが判明したときに、コミットするすべての追加作業が近い将来に覆されることを恐れています。

インターンシップに応募する大学生として、面接中にウェブフレームワークを使用しないという選択を雇用者に質問させました。私は単にWebフレームワークを知らず、どのフレームワークを使用するのか分からない。

1月にフルスタックのデベロッパーとしてインターンシップを開始しました。フロントエンドフレームワークの学習を開始しますが、アプリを終了するプレッシャーが高まっているため、アプリを完全に破棄してやり直すことを検討しています。これは私が以前にやったことです。このアプリは現在、PHPとjQuery（AJAX呼び出し用）で構築されており、データベースにMySQLを使用しています。この精神的なブロックをどのように克服し、アプリがスケーラブルになることを保証するための考えはありますか？前もって感謝します。

完璧は善の敵です。

別の言い方をすれば、今日は心配しないでください。アプリが必要なことを行うのであれば、それで問題ありません。それはだではない、さらにラインの下のソフトウェアの一部を書き換えるために悪いこと。その時点までに、1）構築しようとしているものをより明確に把握し、2）実際にボトルネックとなっているビットを把握します。100万人のユーザーに対応できるアプリを書くのに膨大な時間を費やすこともできますが、現在の6人の顧客にとっては、今日のアプリよりも優れているとは言えません。

この精神的なブロックをどのように克服し、アプリがスケーラブルになることを保証するための考えはありますか？

問題の核心はスケーラビリティではありません。問題の核心は、あなたが最初にそれを正しくすると思っていることです。

きれいなコードを書くことに集中する必要があります。クリーンなコードは、将来（必然的に）何かを変更する必要がある場合に利便性を最大化するためです。そして、それがあなたが持つべき本当の目標です。

あなたが今やろうとしているのは、書くのに最適なコードを考えようとすることです。しかし、たとえそれをなんとかして、要件は変わらないと言っているのか、間違った情報や誤解に基づいて決定を下したのでしょうか？

間違いではありませんが、間違いは避けられません。将来変更する必要のないコードを書くのではなく、後で簡単に変更できるコードの作成に焦点を当てます。

プロジェクトと私がすでに書いたコードに執着して成長し、

私はこの感情にまったく同情します。しかし、あなたが書いたコードにアタッチすることは問題です。

定数でなければならない唯一のものは、特定の問題を解決したいというあなたの願望です。その問題をどのように解決するかは、二次的な懸念にすぎません。

明日、コードベースを80％削減する新しいツールがリリースされた場合、コードが使用されなくなったことに怒ってしまうでしょうか。または、コードベースが小さくなり、よりクリーンで管理しやすくなったことに満足しますか？

前者の場合、問題があります。コードの解決策が表示されません。言い換えれば、あなたはコードに焦点を合わせており、より大きな画像（それが提供することを目指しているソリューション）を見ないことです。

私がコミットするすべての追加作業は、近い将来、ビジネスの成長に伴ってアプリがうまくスケールしないことが判明したときに覆されることを恐れています。

それは別の日の別の問題です。

まず、機能するものを構築します。次に、コードを改善して、まだ表示される可能性のある欠陥を修正します。現在あなたがしていることは、2番目のタスクを実行しなければならないという恐怖から最初のタスクを控えることです。

しかし、他にどのようなオプションがありますか？未来を伝えることはできません。将来の可能性を熟考するのに時間を費やすなら、とにかく推測することになります。推測は常に完全に間違っている傾向があります。

代わりに、アプリケーションをビルドし、実際に問題があることを証明します。そして、問題が明確になったら、その問題に対処し始めます。

別の言い方をすれば、ヘンリー・フォードは2018年の標準/期待に適合する車を製造したことはありません。しかし、もし彼が近代的な基準で欠陥のある車であるモデルTを製造していなかったら、誰も車を使い始めなかったでしょうし、自動車産業はなく、誰も改良しようとする車を持っていなかったでしょう。

インタビュー中にウェブフレームワークを使用しないという選択を雇用者に質問させましたが、それは私の以前の仕事をさらに疑わせただけです。

ここで重要なのは、どのフレームワークを使用しているかではありません（そのことを判断する雇用主は仕事を適切に行っていません）。ここで重要なことはあなたが何をしているのか、それをしている理由を知ることです。

たとえば、具体的に既存のフレームワークを回避する場合は、まずフレームワークをハードな方法で実行することでフレームワークが有用である理由を学習する必要があります。または、独自のフレームワークを作成しようとしている可能性があります。

ここでの唯一の悪い答えは、「知らない」ということです。これは、十分な情報に基づいた意思決定ができ​​ないことを示しています。それは雇用主にとっては危険です。

私は単にWebフレームワークを知らず、どのフレームワークを使用するのか分からない。

ここでも同じ問題が発生します。解決策はもっと考えることではなく、行動することです。

• 完璧な答えを考えるのをやめてください。
• フレームワークを選択してください。好みがない限り、ランダムに選んでください。ダーツボードを使用して、ダイスを転がし、コインを投げ、カードを選びます。
• これを使って。
• あなたはそれを使って好きでしたか？迷惑な点はありましたか？
• これらの不良要素を防ぐ方法を調べてください。フレームワークを誤用しましたか、それともフレームワークがどのように機能するのでしょうか？
• フレームワークを把握していると感じたら（気に入ったかどうかに関係なく）、新しいフレームワークを選択して、サイクルを繰り返します。

これについてさらに読むには、「することの考え方」>「思考の考え方」を読んでください。著者は、私ができる以上にそれを説明しています。

しかし、アプリを終了するプレッシャーが高まっているため、アプリを完全に破棄してやり直すことを検討しています

現在のコードベースが完全に維持できない混乱でない限り。あなたは反対の決定をしている。
開発者は、物を捨てることがより良い選択であるとしばしば考えます。とてもありふれた気持ちです。しかし、それはめったに正しい選択ではありません。

コードを捨てて最初からやり直すことは、仕事に行く途中で交通渋滞に巻き込まれ、仕事に遅れる（締め切りに間に合わない）ことを心配し、代わりに家に帰って同じ道をもう一度走ってみるようなものです。意味がありません。あなたは交通渋滞に巻き込まれているかもしれませんが、あなたは家にいたときよりも仕事に近くなっています。

FacebookとGoogleがマーケティングに注ぎ込んで、そうでなければあなたを納得させているにもかかわらず、フロントエンドフレームワークが存在する主な理由は2つあります。

• 最初に、クライアントに状態とロジックを配置することにより、ハードウェア/ネットワークの要求をクライアント側の操作にオフロードします
• 第二に、最初のポイントをサポートするために必要な追加のクライアントロジックに関連して、何も壊さずに他の人のコードをページに詰め込めるように、独立した実行コンテキストを提供します。

アプリケーションが本質的にステートフルである場合、クライアント側で保存しているアプリケーションの状態の量が非常に複雑である場合、ネットワーク遅延（モバイル、またはサーバーから遠い）、または特に高度なCSSまたは動的な要素の作成をサポートする強いビジネスニーズがある場合。

フレームワークマーケティングでは、アーキテクチャの特別な方法により開発速度が向上し、メンテナンスが容易になると信じてほしい。これは、単純なプロジェクトに取り組んでいる小規模なチームにとっては明らかに真実ではありません。コードを分離してインポートを整理すると、大規模なチームが製品をより迅速に市場に投入するのに役立ちます。すでに機能しているプロジェクトに取り組んでいる一人の開発チームにとっては、はるかに少ないものです。

実際に機能を実装するよりも、既存の機能的なコードをフレームワークに適合させる方法を学ぶのにより多くの時間を費やし、誰かが何かを更新する可能性はかなり高く、そのフレームワークで書かれたコードは18ヶ月以内に機能しなくなる誰かが常にそれを維持するためにそこにいます。

Vanilla JS、およびそれよりも少ないが重要な程度のJQueryは、これらの問題に悩まされていません。いくつかの注目すべき例外はありますが、JQuery + AJAXアプリケーションはブラウザー固有の動作に依存せず、適切な場合は外部の依存関係を無視し、元々非常に小さな変更で記述されてから10〜15年動作し続けます。

フレームワークは、進行中の複雑な公開されているWebアプリケーションをサポートする典型的なスタートアップに最適です。大規模なチームをうまく連携させ、ベンダーとうまく統合し、フレームワークを追加し、派手な新しいウィジェットと設計パラダイムをサポートして、競争力を維持できます。

それはあなたが放棄しようとしている固定観客の小さなソフトウェアツールにとっては重要ではありません。フレームワークを採用すると、新しいパラダイムに適応する際の開発速度が遅くなり、不必要な互換性リスクが発生します。クライアント側のコードをシンプルに保つ（理想的には自己ホストする）ことは、互換性リスクの表面積が大幅に低下することを意味します。ブラウザが変更され、CDNのURLが機能しなくなり、依存関係が古くなります-ただし、そのサーバーに触れている人はいません。

現在の特定のアーキテクチャ上の問題を解決するか、すぐに予見できる場合を除き、フレームワークを採用しないでください。

アプリの「将来性を保証」するためにできる最善のことは、システム設計のベストプラクティスに従って、懸念の疎結合と分離を最大限にすることです。廃止されることを安全に防ぐアプリの部分はありませんが、理由Xで廃止されるコードを、必ずしも Xの影響を受ける必要のないコードから分離するためにできることはたくさんあります。

ただし、アプリの成長/拡張性に対する懸念は、あなた自身の経験と能力の成長率よりも小さくあるべきだと主張します。あなたが説明するメンタルブロックは、停滞を学習したり、それらに取り組むための戦略やツールなしで多くの既知の未知のものを認識するかのように聞こえます。

フレームワークは、「MVCのような高レベルのデザインパターンを介して、経験の浅い人に関連する初期ガイダンスを提供することはできますが、「将来を保証する」課題の解決には特に適していません。むしろ、強力な凝集力を提供することで開発を加速する方法として、多くの場合、より緊密な結合を犠牲にして、より有用になる傾向があります。たとえば、フレームワークが提供するオブジェクトリレーショナルマッピングシステムをアプリ全体で使用して、キャッシングシステムの統合が完了したデータベースとやり取りするとします。後で、非リレーショナルデータストアに切り替える必要があり、そのデータストアを使用するすべてが影響を受けます。

あなたが今持っている混乱は、あなたが使ったものからではなく、あなたがそれを使った場所から来たものです（おそらく、バックエンドのほとんどどこでも）。ページをレンダリングするコードがレンダリングするデータをフェッチしない場合、どれだけ良い結果になるでしょう。

適切に動作するために追加のスクリプトとリソースを必要とする小さなウィジェットをページに追加するとします。フレームワークを使用している場合は、「このことのページに依存関係をどのように追加したいのか」と尋ねることができます。そうでない場合、質問はよりオープンエンドです：「私が触れている技術的な懸念はどういうわけか分離すべきですか？」その質問には答えるのにより多くの経験が必要ですが、ここにいくつかのヒントがあります：

• 明日、すべての静的リソース（スクリプト、画像など）を別のサーバー、コンテンツ配信ネットワークなどに移動した場合、またはパフォーマンスを改善するためにすべてをまとめてパッケージ化しようとした場合はどうなりますか？
• このウィジェットを異なるページに配置したり、同じページに複数のインスタンスを配置したりするとどうなりますか？
• ウィジェットのさまざまなバージョンでABテストをどのように開始しますか？

これのいずれかが圧倒的に聞こえるならば、私はあなたがお勧めしたいはずです、あなたのアプリのためしかし、あなた自身の個人的な成長のためにはあまりない、今のフレームワークを使用します。ただし、最初からやり直す必要はありません。代わりに、フレームワークをカリキュラムとして使用して、アプリの進化をガイドします。

学習する方法は2つしかありません。1つは試行錯誤によるもので、もう1つは他者の経験から学ぶことです。試行錯誤をなくすことはできません。ソフトウェア開発は本質的に継続的な学習分野であり、新しいことや異なることを行わないコードは定義上不要です。（代わりに、すでに記述されているコードを使用してください。）

トリックは、開発プロセスのすべてのステップを通して既存の知識（戦略、ベストプラクティス、およびコード/ライブラリ/フレームワーク）を積極的に探し出すことで最小化し、絶えず車輪を再発明しないようにします。

ただし、現在作成しているアプリに関しては、最初の懸念事項は、最小限の平凡な労力（コードの匂いに似ていますが、開発プロセス）でそれを達成することです。人間の学習の性質を考えると、高品質を達成するための最速の方法は、何かから始めることです。すでに持っているものを批判することで目標を形作ることができれば、目標を理解するのははるかに簡単です。

あなたが書いたコードの多くが使い捨ての学習プロセスであり、良いデザインを見つけるために必要であると認めることができれば、それを維持する動機付けになります。結局のところ、それはソフトウェア開発を魅力的なものにする問題解決の挑戦であり、あなたがやっていることが価値があるなら、その挑戦は常に存在している（上記の「継続的な学習」声明を参照）。

何よりも「物を捨ててやり直す」という選択肢は決してありません ...結局のところ、「半ダースのクライアント」を持っているとは言いませんでしたか？彼らがあなたの声明について 考えていることを考えるためにまだ一時停止しましたか？彼らが今（おそらく）「あなたの仕事に完全に満足している！」と仮定して。

私が使用したい類似点は次のとおりです。

• 「私の仕事は、人々が住む家、ビジネスを建てる家などを建てることです。」私の仕事は、「信じられないほど小さく、過剰に光沢のある砂」を作って有用な仕事をすることです。（住宅建設業者が石膏ウォールボード、セラミックタイル、コンクリートブロック、2x4で家を作るように。）

• しかし、「爪が」家ビルダーが使用することを本当に200年であまり変わっていないのに対し（「ラウンド」とその後、空気圧釘打ち、機械に便利作られるまで、「広場」から行くことを除いて）、技術私たちが使用するものは絶えず変化しており、時には非常に大きな変化を経験します。（"だからそうなるのです。"）

• 「それでも、それぞれの家は、一度建てられたら、永遠に住むでしょう。」それらを排除することはできません。それを構築し、鍵を渡したら、「もう「あなたの」家ではありません。」それが今の状態であり、非常に長い間続くでしょう。

最近の私のビジネスの大部分は、10、20、30年以上前に構築されたソフトウェアにクライアントが対応するのを支援することです。当時存在していた「最先端の」技術を使用しています。私は覚えています） -そして、今日まだサービス中です！

何かが将来の証拠であることを保証することはほとんど不可能です。ただし、アプリがスケーラブルであることを確認するのはそれほど難しくありません。アプリのパフォーマンステストを作成し、処理できるクライアントの数を確認するだけです。テストを記述することで、より多くの変更を実装した後のアプリの動作を測定できるため、間違いなくアプリの将来の証明になります。

wrtフレームワークでは、パフォーマンス/スケーラビリティの面であまり心配する必要はありません。これは簡単に確認でき、修正できる可能性が高いものです。大きな問題はセキュリティです。Webフレームワークは、通常、適切な認証コード、Cookie、CSRF保護などの作成に役立ちます。特に、経験が不足している場合は、その領域に重点を置いてください。

フレームワークの学習に関するコメントを書き始めましたが、最終的には回答のように見えるものに変わりました。

フレームワークを知らないことは問題のようです。基本的にすべてのwebdevジョブでは、何らかのフレームワークを使用する必要があります。あなたは1ではない知った後、別のフレームワークを学ぶこと大したことはなく、しばらくかかる場合があります最初のものを学ぶ-雇用者がその気になる理由です。フレームワークを避けることは、ここではシンドロームが発明されていないことを示している可能性があり、これは広く非現実的なアプローチです。

最初のフレームワークを知ることの主なポイントは、共通の言語を学ぶことです。おそらく、仲間の間で人気のある何かを学んでみてください。フレームワークで書かれたいくつかの簡単なプロジェクトを変更してみてください。知らないフレームワークでゼロからプロジェクトを開始することは、非常に効率の悪い学習方法です。

さて、あなたの実際の質問は、特定のプロジェクトとフレームワークへの移植に関するものでした。そのため、答えは次のように思われます。それは状況に依存しており、私たちは本当にあなたに伝えることができません。しかし、あなたが知らないフレームワークに物を移植することは、ほとんど間違いなく悪い考えです。したがって、フレームワークを知って気に入ったら、ある時点でそのままにして、この決定を再検討する必要があるようです。他の回答には、そのような決定を行う際に何を探すべきかについての良い点が含まれています。

この記事は、2.5年前のHacker Newsで多くの注目を集めました。簡単に削除でき、拡張しにくいコードを記述してください。この観点は、現在のコードベースに対処するのに役立つ場合もあれば、そうでない場合もありますが、将来的には、完璧主義/オーバーエンジニアリングに起因するフラストレーションを防ぐのに役立つ可能性があります。

「コード行」を「消費された行」と見なす場合、コード行を削除すると、メンテナンスのコストが削減されます。再利用可能なソフトウェアを構築する代わりに、使い捨てのソフトウェアを構築することを試みるべきです。

コードを削除するほうがコードを書くよりも楽しいと言う必要はありません。

（エンファシス鉱山）

Hacker Newsの記事のスレッドも読む価値があります。

それを将来的に保証し、スケールとフレームワークの原則を適用する限り、自分で取り組むのは難しいタスクです。おそらく心配する必要はありませんが、必要な場合：

コードをクリーンに保ち、SOLID、DRY原則> googleに従ってください。

できるだけ早くロードバランサーを適用してください。

少なくとも2つのWebサーバーを立ち上げ、コードで負荷分散シナリオを処理します。

最後に大事なことを言い忘れていましたが、100万人のユーザーを処理するためのスタックはLAMPよりも優れていますが、完全に実行可能であると確信しています。

ケースとポイント、次を参照してください：https : //stackoverflow.com/questions/1276/how-big-can-a-mysql-database-get-before-performance-starts-to-degradeポイントは有効ですが、10GBは簡単です被験者として。