私は、小規模でローカルなSaaSウェブアプリケーションのウェブ開発者です。現在、約半ダースのクライアントを持っています。
アプリケーションの設計を続けるうちに、プロジェクトに時間を割くことを納得することが難しくなってきました。このプロジェクトとすでに書いたコードに愛着があるため、近い将来、ビジネスの成長に伴ってアプリがうまく拡張できないことが判明したとき、私がコミットしたすべての追加作業が覆されるのではないかと恐れているのです。
大学生でインターンシップに応募した際、面接で「Webフレームワークを使わない」という選択を疑われ、さらに自分のこれまでの仕事を疑われることになりました。Webフレームワークを知らないし、どれを使えばいいのかわからない。
1月にフルスタック開発者としてのインターンシップが決まり、そこでフロントエンドのフレームワークを学び始める予定ですが、アプリを完成させなければならないというプレッシャーもあり、アプリを完全に破棄してやり直すことも考えています(これは以前にもやったことがあります)。このアプリは現在、PHPとjQuery(AJAX呼び出し用)で構築され、データベースにはMySQLを使用しています。このメンタル ブロックを克服し、アプリのスケーラビリティを確保する方法について、何か考えがありますか?よろしくお願いします。
別の言い方をすれば、今日は気にするなということです。あなたのアプリがやるべきことをやっているなら、それでいいんです。その時点で、あなたは1)何を作ろうとしているのかがより明確にわかり、2)どの部分が実際にボトルネックになっているのかがわかるからです。その時点で、1) 何を作ろうとしているのかがより明確になり、2) どの部分が実際にボトルネックになっているのかがわかるのです。
このメンタルブロックを克服し、アプリのスケーラビリティを確保する方法について、ご意見をお聞かせください。
この問題の核心は、スケーラビリティではありません。問題の核心は、最初からうまくいくと考えていることです。
あなたは、クリーンなコードを書くことに集中すべきです。なぜなら、クリーンなコードは、将来何かを変更しなければならないときに、その利便性を最大限に発揮するからです。そして、それこそがあなたが持つべき真の目標なのです。
今あなたがやろうとしていることは、書くべき完璧なコードを考えようとすることです。しかし、たとえそれができたとしても、要件が変化しないとは限らないし、間違った情報やミスコミュニケーションに基づいて意思決定をしてしまうかもしれないでしょう?
たとえ自分のミスでなくとも、ミスは避けられないのです。将来変更する必要のないコードを書こうとするのではなく、後で変更しやすいコードを書くことに集中しましょう。
(2)プロジェクトや書いたコードに愛着が湧いてしまった。
その気持ちはとてもよくわかります。しかし、書いたコードに愛着を持つのは問題です。
唯一不変であるべきものは、「特定の問題を解決したい」という欲求です。その問題をどう解決するかは、二の次でいいんです。
もし明日、あなたのコードベースを80%削減する新しいツールがリリースされたとして、あなたは自分のコードが使われなくなったことに腹を立てるでしょうか。
もし前者なら、あなたは問題を抱えています: あなたは コードに対する解決策を見ていないのです。言い換えれば、あなたはコードに焦点を当て、より大きな絵(それが提供しようとする解決策)を見ていないのです。
gt; I'I'm scared that all additional work I commit is overturned in the near future, when the app turned out well as the business grows
それはまた別の日の問題です。
まず、機能するものを作る。次に、まだ残っている欠陥を修正するためにコードを改善します。現在あなたが行っていることは、2番目の作業を行うことを恐れて、1番目の作業を控えていることです。
しかし、他にどのような選択肢があるでしょうか?未来を見通すことはできません。未来の可能性について考えることに時間を費やすと、いずれにせよ「推測」で終わることになるのです。推測は常に大外れする傾向があります。
それよりも、アプリケーションを構築し、実際に問題があることを証明することです。そして、問題が明らかになったら、その問題に対処するのです。
別の言い方をすればヘンリー・フォードは、2018年の基準/期待に適合する自動車を作ったことはありません。しかし、もし彼が現代の基準では欠陥のあるT型車を作らなかったら、誰も車を使い始めなかったでしょうし、自動車産業も存在しなかったでしょうし、その後改良を試みることができる車を持つこともできなかったはずです。
また、自動車産業も存在しなかったでしょう。
ここで重要なのは、どのフレームワークを使っているかということではありません(それで判断する雇用主は、自分の仕事を正しく行っていないことになります)。ここで重要なのは、自分が何をしているのか、なぜそうしているのかを知ることです。
たとえば、既存のフレームワークを避けるのは、フレームワークが有用である理由を、まず難しい方法で学びたいからかもしれません。あるいは、自分自身のフレームワークを作ろうとしているのかもしれません。
ここで唯一悪い答えは、「わからない」というもので、情報に基づいた判断ができないことを表しています。これは雇用主にとって赤信号です。
フレームワークを知らないので、どれを使い始めたらいいのかわかりません。
ここでも同じような問題が発生します。解決策は、もっと考えることではなく、むしろ行動することです。
完璧な答えを考えるのをやめる。
FacebookやGoogleが莫大な資金を注ぎ込んでマーケティングを行い、あなたを説得しているにもかかわらず、フロントエンドのフレームワークが存在する理由は主に2つあります。
アプリケーションが本質的にステートフルである場合、クライアント側で保存するアプリケーションの状態が非常に複雑である場合、ネットワーク遅延のひどいクライアントが多数存在する場合(モバイル、サーバーから遠い)、特に高度なCSSや動的要素の作成をサポートするビジネスニーズが強い場合、おそらくこれらの問題を解決するためにフレームワークに手を出す必要があるだけでしょう。
フレームワークのマーケティングでは、その特殊なアーキテクチャの手法によって、開発速度が上がり、メンテナンスが容易になると信じ込ませたいのです。これは、単純なプロジェクトに取り組む小規模なチームにとっては、明らかに真実ではありません。コードを分離し、インポートを整理することは、大規模なチームが製品をより迅速に市場に投入するのに役立つかもしれない。しかし、すでに機能しているプロジェクトに取り組んでいる一人の開発チームにとっては、あまり意味のないことなのです。
実際に機能を実装するよりも、既存の機能的なコードをフレームワークに適合させる方法を学ぶことに多くの時間を費やすことになるでしょうし、誰かがどこかで何かを更新する可能性はかなり高く、そのフレームワークで書かれたコードは、常にそれを維持する人がいなければ18ヶ月で機能しなくなります。
Vanilla JS、そして少ないながらもJQueryは、このような問題に悩まされることはありません。いくつかの顕著な例外を除いて、ブラウザ固有の動作に依存しないJQuery + AJAXアプリケーションは、ごくわずかな変更で、最初に書かれてから10~15年後も動き続けています。
フレームワークは、継続的で複雑な、一般向けのウェブアプリケーションをサポートする典型的な新興企業にとって素晴らしいものです。フレームワークによって、大規模なチームがうまく協調し、ベンダーが追加するフレームワークとうまく統合し、派手な新しいウィジェットとデザインパラダイムをサポートして、競争力を維持することができます。
しかし、固定客を持つ小さなソフトウェアツールには、そんなことは関係ないのです。フレームワークを採用すると、新しいパラダイムに適応するために開発速度が遅くなり、不必要な互換性リスクが発生します。クライアントサイドのコードをシンプルに保ち、理想的にはセルフホストにすることで、互換性リスクの表面積を大幅に減らすことができます。ブラウザが変わったり、CDNのURLが使えなくなったり、依存関係が古くなったりしても、誰もそのサーバーに触れないので、問題なく動き続けることができるのです。
フレームワークは、現在抱えている、あるいは近い将来に予測できる特定のアーキテクチャ上の問題を解決するものでなければ採用してはいけません。