完全なスタックが必要ではない 、 完全なスタックが存在しない 、 完全なスタックが悪い 、という事実に関する多数の記事や資料の背景に対して、 完全なスタックが専門の専門家より優れている点 、および完全なスタックが必要な理由について意見があります 。
記事の最初にフルスタックに関する他の記事へのリンクのリストを残したかったのですが、あまりにも多すぎたので、すみません。 完全なスタックが良い理由と完全なスタックが悪い理由について十分な資料があると言いたいだけです。 そして、それぞれが少なくとも50％真実です。
おそらく最後の手段とは言えない個人的な感情や考えがあります。
私が言ったように、私の名前はPavelで、プログラミングのためのお金を得てからまもなく7年になります。 そして、このすべての期間、履歴書、インタビュー、およびその他の場所で自分自身を呼び出しました： FrontendとDevOpsの知識とスキルを持つバックエンド開発者 。 いずれにせよ、彼のプロとしての経歴では、彼はしばしばプロジェクトのバックエンドとして働いていましたが、彼はフロントやオペレーションを恐れることはありませんでした。 したがって、彼は誇らしげにこれらの2つの領域を説明に追加しました。 確かに、Mad Devsが到着し、MadOpsチームとプロジェクトの1つに取り組んでいたので、DevOpsを説明から削除しました。 あなたが知っているように、比較のすべてが知られています。 私はいつか、フロントエンドのポストスクリプトを削除するように私を「説得」する同じフロントエンドの専門家と協力したいと思っています。 主なことは、バックエンダーに会わないことです。これにより、履歴書からバックエンドを強制的に削除します。そうしないと、何も残りません。
フルスタックは次のような悪い音であると信じる専門家の最も頻繁な議論です。 どの分野にも没頭して いない 、 あなたはシニア フルスタック 開発者になることはできません 。 そして、あなたは知っています、私は彼らに同意します。
過去数か月にわたって、バックエンドでRuby、フロントでVueJS、Goを使用してテキストジェネレーターを実装するPeklo Toolプロジェクトに取り組んでいます。
そして、私は問題を感じます：
- Goのこのコードはより適切に記述でき、より速く動作するか、使用するシステムリソースが少なくなると思います。
- 私のwebpack設定はもっと良く設定できると感じています。今はたくさんのゴミがあります。
- このレイアウトは、最新のCSS、SCSS機能を使用して実行できる、またはPostCSSや他の拡張機能を使用できると感じています。
- たとえば、レール上のコードを最適化して、データベース内のクエリを少なくすることができると思います。
- データベースでインデックスを人間で設定する必要があると感じています。
- このDockerfileは、より少ない（またはより多い）レイヤーになるように書き換える必要があると感じています。
- などなど...
私はそれをすべて感じることができます。 さらに、私は本当にそれをすべてやりたいです。 そして、空き時間が表示されたら、これらの問題の少なくとも1つを部分的に解決します。
あなたは私に尋ねます： なぜあなたはそのような問題がないようにこの場所で物Nをすぐに使わないのですか？
そして、私は答えます： Nがわからないので、特定のケースのプロジェクトにすばやく適用するのに適しています。 私は開発から時間をかけています -問題を読んでください： 完全な没入はありません 。
私が取り組んでいるプロジェクトには機能が必要だからです。 PekloToolは、コンテキスト広告キャンペーンを生成するためのプロフェッショナルツールです。 このツールは若く、開発は1年以上前から進行中ですが、ほんの数か月前に完全に運用されました。 その結果、現在、このような製品に役立つすべての機能を実行しています。
機能が必要であり、その機能が有用であることをどのようにして知ることができますか？ 私はフルスタックだから非常に簡単です 。 プロジェクト全体が見えます。 私はプロジェクトの目標を見て、それがどのように機能するのかを見て、私が上で書いた技術的なものだけでなく、ユーザーが見るであろう側面も見ます。
そして、ここでこの記事の要点を説明します。最新のフルスタックは、バックエンド、フロントエンドなどを実行できる単なるエンコーダーではないはずだと思います。 Fullstackは、プロジェクトの開発に関与している人です。 バックエンド、フロントエンドなどの能力に加えて 完全なスタックには、プロジェクトの主題分野、UX / UIの知識、さらにはマーケティングの知識が必要です。 Fulstackは、プロジェクトがその主要なタスクをどのように達成するかを知っている必要があります。それが、お金を稼ぐか、世界を救うかです。 Fulstackは、プロジェクトの「顧客」との短い関係にあるべきです。 すべてのプロジェクトには「顧客」がいます。アウトソーシング会社の場合は顧客であり、製品会社の場合は利害関係者または製品です。 「顧客」は、プロジェクトに関するすべての問題について相談できる専門家をフルスタックで確認する必要があります。
新参者Mad Devsのハンドブック（会社の初日に読むために与えられる同じドキュメント）には、「Customer Affinity」（ Eng。- 「Customer proximity」）という項目があります。 前項でこの用語の本質を説明しました。 フルスタックは常に顧客の帽子をかぶる必要があります。理想的なオプションは、「カスタマー」がフルスタックと一緒にスプリントタスクを行う場合です。 つまり、完全なスタックは、与えられたタスクを解決するだけでなく、各タスクの外観の履歴を理解します。 バックエンド、フロントエンド、携帯電話などを実行する場合でも、人が単にタスクを実行し、その作業がそこで終了する場合、これは完全なスタックではないと思います。 これは、フロントエンドを実行できる単なるバックエンド、またはその逆です。
したがって、私はこれをすべて書きます、そして、読者は2つの考えを持っているかもしれません：
- なんてナンセンスだ 。 ここにそれぞれ自分の。 あなたがそう思うなら、おそらくあなたは狭い専門家です、そしてあなたの意見は明らかです。 しかし、あなたがフルスタックの場合、私は「あなたを幸せにします」。 プロジェクトに役立つ膨大な有用な活動の層を失い、キャリアのさらなる発展を決定できる重要な能力を獲得する機会も失います。
- これは、製品の所有者にとってフルスタックのように見えるはずですか？ はい、あなたは正しいです。 いくつかの点を除いて、製品所有者は多くの場合、プロジェクト全体のチームリーダーです。 私はリーダーシップの資質をフルスタックに帰するつもりはありません。 これは何か他のものです。 さて、製品開発者はプロジェクトの開発コストを計算できるはずです。開発に関連する財務について考えるために、完全なスタックは必要ありません。 彼の立場からは、すでに開発のためのお金があります。 もちろん、彼は開発コストを削減するオプションを提供できますが、量的条件ではなく、パーセンテージまたは質的条件でのみ可能です。 多分いくつかの点で、この製品でできるはずのいくつかが足りませんが、フルスタックです。
私が説明したいコインのもう一つの側面があります。 これは悲しいです。 フルスタックの問題は、スタックが過負荷になることです。 これは明らかです。 原則として、非常に膨大なタスク、複雑な機能を実行します。 上記で書いた機能やタスクを思いつくために、まだお客様とコミュニケーションを取っています。 さらに、プロジェクト全体を技術的な観点から見ると、多くの場合、インフラストラクチャ、アーキテクチャなどに取り組んでいます。 情報が多いほど、アイデアが多く、アイデアが多いほど、それらが実現する可能性が高くなります。 その結果、多くの場合、NoSQLデータベース、GraphQL、または他の何かと考えられます。 ここでは、雇用自体も現れます。 私はすぐにすべてを条件付きGraphQLに転送するということを言っているわけではありませんが、小さなアイデアを自分で受け入れて実装することもあります。 要するに、とても忙しい。
何が欲しい？ 私は新しいライブラリを試して、Gitlab CIの設定をもっと勉強し、Loguxのように、自分にとって興味深く比較的新しいものを吸いたいと思っています。 しかし、時間がありません、あなたはプロジェクトに責任があります。 私はこの悲しみ 、ただ悲しい悲しみとは言いません。 これとは対照的に、私は大きな話題を得ました。肯定的なユーザーレビューを見るときから。 彼らがあなたが数日間寝なかった機能について喜んで書いたとき; ユーザーの数が増えたとき。
結論として、私は、狭い専門家と広い専門家がプロジェクトに対して独自の利点、キャリア、環境、およびデメリットを持っているという考えを表明します。 私の意見では、もちろんこれが暖かく受け入れられない限り、次の資料のいずれかで特定の専門的な利点と欠点を説明します。
これは私が好きな仕事であり、週末をやっても大丈夫だし、喜んでやるからです。