Webアプリが「将来を見据えた」ものではないという恐怖
私は小さなローカルSaaS= WebアプリケーションのWeb開発者です。現在、約6のクライアントを持っています。
アプリケーションの設計を続けると、プロジェクトにいつでもコミットするように自分を説得することがますます難しくなります。これは、最初のフェーズで発生しました。プロジェクトと私が既に書いたコードに結びついたので、ビジネスの成長に伴ってアプリがうまくスケーリングしないことが判明したときに、コミットするすべての追加作業が近い将来に覆されるのではないかと怖いです。
私はインターンシップを申請する大学生として、面接時にWebフレームワークを使用しないという私の選択に雇用主に質問してきました。私は単にどのWebフレームワークも知らず、どのフレームワークを使い始めるかわかりません。
1月にフルスタックデベロッパーとしてインターンシップを開始しました。そこではフロントエンドフレームワークについて学び始めますが、アプリを完成させるプレッシャーが高まっているため、アプリを完全に解体してやり直すことを検討しています。これは私が以前にやったことです。アプリは現在PHPおよびjQuery（AJAX呼び出し用）に組み込まれており、データベースにMySQLを使用しています。このメンタルブロックを克服する方法についての考えは、アプリのスケーラビリティを確保するにはどうすればよいですか？.
または別の言い方をすれば、今日は心配しないでください。アプリが必要なことを行う場合、問題ありません。ソフトウェアの一部をさらに書き換えるのは悪いことですではありません。その時点で、1）ビルドしようとしているものをより明確に把握し、2）実際にどのビットがボトルネックになっているのかを把握します。 100万人規模のユーザーに対応するアプリを作成するのに膨大な時間を費やす可能性がありますが、現在の6人の顧客にとって、今日得ているものよりも優れているとは言えません。
このメンタルブロックを克服する方法、およびアプリをスケーラブルにするための考えはありますか？
問題の核心はスケーラビリティではありません。問題の核心はあなたが最初にそれを正しく理解するだろうと考えています。
クリーンなコードを書くことに集中する必要があります。クリーンなコードは、（必然的に）将来何かを変更する必要がある場合に、利便性を最大化するためです。そして、それはあなたが持っているべき真の目標です。
あなたが今やろうとしているのは、書くのに最適なコードを考えることです。しかし、たとえそれができたとしても、要件は変わらないと誰が言ったのでしょうか。あるいは、間違った情報や誤解に基づいて決定を下したのでしょうか。
たとえそれがあなたのせいではなくても、間違いを犯すことは避けられません。将来変更する必要のないコードを書くのではなく、後で簡単に変更できるコードを書くことに集中してください。
プロジェクトと私がすでに書いたコードに結びついて、
私はこの感情に絶対に共感しています。しかし、あなたが書いたコードに執着するのは問題です。
定数であるべき唯一のものは特定の問題を解決したいです。その問題をどのように解決するかは、二次的な問題にすぎません。
明日、コードベースを80％削減する新しいツールがリリースされた場合、コードが使用されなくなったことに不満を感じるでしょうか。それとも、コードベースがより小さくなり、よりクリーンで管理しやすくなったことに満足しますか？
前者の場合、問題があります：あなたは コードの解決策が表示されていません です。つまり、コードに焦点を合わせており、全体像（コードが提供しようとしているソリューション）を見ていません。
ビジネスの成長に伴ってアプリが適切にスケーリングされないことが判明したときに、私がコミットするすべての追加作業が近い将来に覆されることを私は怖いです。
それは別の日の別の問題です。
まず、機能するものを構築します。 次に、コードを改善して、まだ表示されている可能性のある欠陥を修正します。あなたが現在行っているのは、2番目のタスクを実行する必要があることを恐れて、最初のタスクを保留することです。
しかし、他にどのような選択肢がありますか？ 未来は言えません。将来の可能性を考えて時間を費やすなら、結局は推測となるでしょう。推測は常に完全に間違っている傾向があります。
代わりに、アプリケーションをビルドし、実際に問題があることを証明します。そして問題が明確になったら、それに対処し始めます。
別の言い方をすれば、ヘンリーフォードは2018年の基準/期待に適合する車を製造したことはありません。しかし、もし彼が現代の基準で欠陥のある車であるモデルTを製造していなかったら、誰も車を使い始めなかったでしょうし、自動車産業もないし、誰も彼らが改良しようとする車を持っていなかったでしょう。
面接時にWebフレームワークを使用しないという私の選択について雇用主に質問してきたため、以前の仕事にさらに疑問を抱くだけでした。
ここで重要なのは、使用しているフレームワークではありません（それについてあなたを判断する雇用主が適切に仕事をしていません）。ここで重要な部分は、何をしているのか、なぜそれをしているのかを知ることです。
たとえば、学習したいために既存のフレームワークを回避している可能性がありますなぜ最初に難しい方法でそれを行うことにより、フレームワークが役立ちます。または、独自のフレームワークを作成しようとしている可能性があります。
ここでの唯一の悪い答えは、「私は知らない」です。それはis雇用主の赤い旗です。
私は単にどのWebフレームワークも知らず、どのフレームワークを使い始めるかわかりません。
ここでも同じ問題が発生します。解決策は、もっと考えることではなく、行動することです。
- 完璧な答えを熟考するのをやめてください。
- フレームワークを選択してください。好みがない限り、ランダムに選んでください。ダーツボードを使用し、サイコロを転がし、コインを裏返し、カードを選びます。
- これを使って。
- 使ってみましたか？気になることがありましたか？
- これらの悪い要素を防ぐ方法を調べてください。フレームワークを誤用しましたか、それともフレームワークが機能するはずの方法ですか？
- フレームワークを把握できたら（気に入ったかどうかに関係なく）、新しいフレームワークを選択してサイクルを繰り返します。
これについてもっと読むには、 実行する考え方>思考する考え方 を読んでください。著者はそれを私よりよく説明しています。
アプリを完成させるプレッシャーが高まっているので、アプリを完全に破棄して最初からやり直すことを検討しています
現在のコードベースが完全に保守不可能な混乱でない限り。あなたは反対の決定をしています。
開発者は、物を捨てることがより良い選択であるとしばしば考えます。それは非常に一般的な感じです。しかし、それが正しい選択であることはめったにありません。
コードを捨ててゼロから始めるのは、通勤途中で渋滞に巻き込まれ、仕事に遅れる（締め切りに間に合わない）と心配して、代わりに家に帰って同じ道をもう一度走ってみるようなものです。それは意味がありません。渋滞に巻き込まれる可能性がありますが、自宅にいたときよりも職場に近くなります。
FacebookとGoogleがあなたを説得するためにマーケティングに注ぎ込んだ莫大な金額にもかかわらず、フロントエンドフレームワークは主に2つの理由で存在します。
- まず、クライアントに状態とロジックを置くことにより、ハードウェア/ネットワークの要求をクライアント側の操作にオフロードします。
- 次に、最初のポイントをサポートするために必要な追加のクライアントロジックに関連して、それらは分離された実行コンテキストを提供するため、何も壊すことなく他の人のコードをページに詰め込むことができます。
アプリケーションが本質的にステートフルである場合、クライアント側で保存するアプリケーションの状態の量が非常に複雑な場合、ネットワークレイテンシが悪い非常に多くのクライアントが予想される場合（モバイル、またはサーバーから離れている）、または特に高度なCSSまたは動的要素の作成をサポートする強いビジネスニーズがある場合。
フレームワークマーケティングでは、特別なアーキテクチャ方式により開発速度が向上し、メンテナンスが容易になると信じてもらいたいと考えています。これは、単純なプロジェクトに取り組んでいる小規模なチームにとっては明らかに誤りです。コードを分離してインポートを整理すると、大規模なチームが製品をより早く市場に投入するのに役立つ場合があります。これは、すでに機能しているプロジェクトに取り組んでいる一人の開発チームにはるかに少ないものを提供します。
実際に機能を実装するよりも、既存の機能的なコードをフレームワークに組み込む方法を学習することに多くの時間を費やします。誰かがどこかで何かを更新し、そのフレームワークで記述されたコードが18か月以内に機能しなくなる可能性はかなりあります。誰かがそれを常に維持するためにそこにいます。
バニラJS、そしてそれでもかなりの程度のJQueryは、これらの問題に悩まされることはありません。いくつかの注目すべき例外を除いて、JQuery + AJAXアプリケーションはブラウザー固有の動作に依存せず、賢明な外部依存関係を放棄しますが、ごくわずかな変更を加えて作成されてから10〜15年経過しても動作し続けます。
フレームワークは、継続的で複雑な、一般に公開されているWebアプリケーションをサポートする一般的な新興企業に最適です。大規模なチームがうまく連携し、ベンダー追加フレームワークとうまく統合し、派手な新しいウィジェットと設計パラダイムをサポートして、競争力を維持できるようにします。
あなたがこれからやめようとしている、聴衆が固定されている小さなソフトウェアツールにとっては、それは重要ではありません。フレームワークを採用すると、新しいパラダイムに適応するにつれて開発速度が低下し、不要な互換性リスクが発生します。クライアント側のコードをシンプルに（理想的には自己ホスト型に）保つことは、互換性リスクの表面領域が大幅に減少することを意味します。ブラウザーが変更され、CDNのURLが機能しなくなり、依存関係が古くなる-しかし、誰もそのサーバーに触れておらず、正常に機能し続ける。
現在のアーキテクチャの問題を解決するか、まもなく予測できるフレームワークでない限り、フレームワークを採用しないでください。その可能性がある場合は、代わりに別の方法でその懸念に対処することを強く検討してください。
アプリの「将来性」を実現するためにできる最善のことは、システム設計のベストプラクティスに従って、疎結合と懸念の分離を最大化することです。古くなっても安全なアプリの部分はありませんが、理由Xのために古くなったコードを、Xの影響を受けない必要に応じてのコードから分離するためにできることはたくさんあります。
ただし、あなたの懸念はあなた自身の経験と機能の成長率よりもあなたのアプリの成長/スケーラビリティに対するものではないはずだと私は主張します。あなたが説明する精神的なブロックは、それらに取り組むための戦略やツールなしで、多くの既知の未知のものの停滞や気づきを学ぶように聞こえます。
フレームワークは、「MVCのような高レベルの設計パターンを介して、経験の浅い人に関連するinitialガイダンスを提供できますが、「将来を見据えた」課題の解決には特に適していません。むしろ、それらは強い凝集力を提供することにより開発を加速する方法として、そしてしばしばより緊密な結合の費用でより有用になる傾向があります。たとえば、アプリ全体でフレームワークが提供するオブジェクトリレーショナルマッピングシステムを使用してデータベースとやり取りし、キャッシュシステムの統合を完了したとします。おそらく後で非リレーショナルデータストアに切り替える必要があり、それを使用するeverythingが影響を受けます。
あなたが今持っている混乱はwhatからのものではありませんが、-whereはそれを使用しました（おそらくバックエンドのほぼどこでも）。ページをレンダリングするコードが、ページがレンダリングするデータをフェッチしない場合は、どれほど良いことになるでしょう。
正しく動作するために追加のスクリプトとリソースを必要とするページに小さなウィジェットを追加したいとします。フレームワークを使用している場合は、「このために、依存関係をページに追加するにはどうすればよいですか？」そうでない場合、質問はよりオープンエンドです：「私が触れている技術的な懸念は、どういうわけか分離する必要がありますか？」その質問に答えるには経験が必要ですが、ここにいくつかのヒントがあります：
- 明日、すべての静的リソース（スクリプト、画像など）を別のサーバー、コンテンツ配信ネットワークなどに移動したり、それらをすべてパッケージ化してパフォーマンスを向上させたりした場合はどうなりますか？
- このウィジェットを別のページに配置したり、同じページに複数のインスタンスを配置したりするとどうなりますか？
- ウィジェットの異なるバージョンでA-Bテストをどのように開始しますか？
これらのいずれかが圧倒的に聞こえる場合は、私はあなたに提案することをお勧めしますすべき今のところフレームワークを使用してください。アプリのためではなく、個人の成長のために。ただし、最初からやり直す必要はありません。代わりに、フレームワークをカリキュラムとして使用して、アプリの進化を導きます。
学ぶ方法は2つしかありません。 1つは試行錯誤によるもので、もう1つは他の人の経験から学ぶことによるものです。試行錯誤は排除できません。ソフトウェア開発は本質的に継続的な学習分野であり、何か新しいことや異なることを行わないコードは定義上不要です。 （代わりに、すでに記述されているコードを使用してください。）
その秘訣は、開発プロセスのすべてのステップを通じて既存の知識（戦略、ベストプラクティス、コード/ライブラリ/フレームワーク）を積極的に探してそれを最小限に抑えることです。
ただし、現在作成しているアプリについては、最低限のmundane労力（コードの匂いのようなものですが、開発プロセスのため）でそれを実行することを最初に検討する必要があります。人間の学習の性質を考えると、高品質を達成する最も早い方法はsomethingから始めることです。すでに持っているものを批評することによって目標を形作ることができるとき、目標を理解することははるかに簡単です。
作成したコードの多くが使い捨ての学習プロセスであり、優れたデザインであるfindに必要であると受け入れることができれば、それを維持する動機付けになります。結局のところ、ソフトウェア開発を魅力的なものにするのは問題解決の課題であり、その課題は、実行していることが価値がある場合には常に存在します（上記の「継続的な学習」の説明を参照）。
何よりも、「ものを廃棄してやり直す」はneverオプションです...結局のところ、しませんでしたあなたが持っていると言います "半ダースクライアント？"あなたはまだtheyは、（おそらく）「あなたの仕事に完全に満足していますか？！」
これが私が使いたい類推です：
「私の仕事は、人々が住む家、ビジネスを建てる家などを建てることです。」私の仕事は、「あり得ないほど小さな、美化されすぎた砂のビット」を作成して、有用な作業を行うことです。 （住宅建設業者が石膏ボード、セラミックタイル、コンクリートブロック、2x4から家を作るように）
ただし、ハウスビルダーが使用する「ネイル」は実際には200年あまり変化していません（「正方形」から「ラウンド」に移動して、その後有用になることを除いて）空気圧釘打ち機を使用して）、私たちが使用する技術は常に変化し、時には非常に大きな変化を経験します。 （ "そうです。"）
「それにもかかわらず、各家は、一度建てられると、永遠にbe lived in。」になります。それらを立ち退かせることはできません。それを構築して鍵を渡すと、「もう「あなたの」家ではありません」。それが今の状態であり、非常に長い間存在します。
最近の私のビジネスの大部分は、10、20、30年以上前に、当時存在していた「最先端の」テクノロジーを使用して構築されたソフトウェアにクライアントが対応できるようにすることです–（そして、どっちか、覚えてる）–そしてどっちが今日もサービス中！.
何かが将来の証拠であることを保証することはほとんど不可能です。ただし、アプリがスケーラブルであることを確認することはそれほど難しくありません。アプリのパフォーマンステストを記述して、アプリが処理できるクライアントの数を確認するだけです。より多くの変更を実装した後のアプリの動作を測定できるため、テストを作成することは間違いなくアプリの将来性を証明します。
フレームワークについては、パフォーマンス/スケーラビリティに関してはそれほど心配する必要はありません。これは簡単に確認でき、おそらく修正できるものです。より大きな問題はセキュリティです。通常、Webフレームワークは、適切な認証コード、Cookie、CSRF保護などを作成するのに役立ちます。特に、経験が不足している場合は、その領域に重点を置きます。
私は学習フレームワークについてコメントを書き始めましたが、最終的には回答のように見えるものに変わったので、ここにあります。
フレームワークを知らないことが問題のようです。基本的に、どのwebdevジョブでも、someフレームワークを使用する必要があります。別のフレームワークを学習することは、それがそれの大事ではないことを知ってからではありますが、最初のフレームワークの学習には時間がかかる場合があります。フレームワークを回避することは ここでは発明されていない症候群 を示している可能性があり、これは広く非実用的なアプローチです。
最初のフレームワークを知ることの主要なポイントは共通言語を学ぶことであるので、おそらく仲間の間で人気のあるものを学んでみてください。フレームワークで書かれた簡単なプロジェクトを変更してみてください。知らないフレームワークでプロジェクトをゼロから開始することは、非常に効果的な学習方法ではありません。
さて、あなたの実際の質問は、特定のプロジェクトとそれをフレームワークに移植することについてでした。そのため、答えは次のように思われます。それは状況に応じて異なります。ただし、意味があるかどうかさえわからないので、知らないフレームワークにコンテンツを移植することはほぼ間違いなく悪い考えです。したがって、フレームワークを理解して気に入ったら、現状のままにして、いつかこの決定を再検討する必要があるようです。他の回答には、そのような決定をするときに探す必要があるものについての良い点が含まれています。
この記事は、2.5年前のHacker Newsで多くの注目を集めました： 削除が簡単で、拡張が簡単ではないコードを記述します。 このパースペクティブは、現在のコードベースの処理に役立つ場合とそうでない場合がありますが、将来的には、完全主義/オーバーエンジニアリングに起因するフラストレーションを防ぐのに役立つ可能性があります。
「コード行」を「費やした行数」と見なす場合、コード行を削除すると、メンテナンスのコストが削減されます。 再利用可能なソフトウェアを構築する代わりに、使い捨てのソフトウェアを構築するようにしてください。
コードを削除することは、コードを書くことよりも楽しいことを伝える必要はありません。
（強調鉱山）
Hacker Newsの 記事のスレッド も読む価値があるかもしれません。