フルスタック-なぜクールなのか、仕事から喜びを得る方法

最近、フルステキによる記事へのコメントで、Habréで深刻な戦いが勃発しました。これらは永遠のMIDLです。 苦しみたくないならこの道をたどらないでください



スタック全体が本当にクールであるという観点と、このパスに沿って進むのが良い理由を表現しようと思います。



おそらく、以下のテキストは、誰かがこの道に着手するのに役立ち、おそらくその逆は、もろい心を彼から守るでしょう。 一般的に、猫へようこそ。



** AHTUNG! 以下はすべて究極の真実ではなく、(この世界の)私の主観的なビジョンです。



最初に、以下で説明する用語を同じ情報フィールドに定義します。 フルスタックの概念はすべての人で異なります(ジュニア/ミドル/シニアおよびその他のランキングテーブルへの分割と同様)。



最も一般的な意見は、fullstackは開発者であり、1人の人間が、プロジェクトの後ろから手前まで完全に作業できるということです。



「まあ、私のチームでは中間缶」と言う人もいるかもしれませんが、ほとんどの場合、これは(穏やかに言えば)間違っています。 フロントエンド開発者がバッキングコードで何かを修正/追加し、データベースクエリをさらに掘り下げることができる場合、これはまだ完全なスタックではありません。

結局のところ、プロジェクトの開発は、単にバックおよびフロントコードであるだけでなく、結果の製品のインフラストラクチャを構築/構成/サポートすることでもあります。 コードを書くだけでは十分ではありませんが、オブジェクト上で動作するようにする必要があります。 また、オブジェクトは、デフォルトでLAMPを備えた5ドルのVPS、AWS / Azureなどのクラウドネットワーク、またはサーバー/ワークステーションからルーターまでの非常に現実的なハードウェアが存在する独自のインフラストラクチャです。



したがって、「fullstack-dev」についてではなく、「fullstack-in general」について説明しています。 交渉の段階から完了の行為に署名する段階まで、プロジェクトを一人で引き込むことができます。



フルスタックのスペシャリストが知っておくべきことと知らないことをリストして、指を曲げません。 これは非常に曖昧なリストです。 最終的には、誰かが「No one with Java with NoSQL」と言う「1つのツールのプロジェクト」を寄付し、宣伝することができますが、今日はこれについては説明しません。



それで、 フルスタック開発者になるには、フルスタックになる必要がありますか、それともその方向に進む方が良いですか?



表面にあるプラスマイナスを簡単に調べます。



短所



おそらく最も明白なマイナス-最も近代的なツールや技術の所有からコードの品質に至るまで、あらゆる点で常に( 常に )高度に専門化された開発者より劣っていることを事実として受け入れてください。 あなたが野心的であれば、常に進歩の最先端にいたい、あなたは指を曲げて、他の人をたわごととして見たいです-フルスタックはあなたの方法ではありません。



フルスタックの仕事を見つけることは、1つのテクノロジーの開発者にとってよりもはるかに簡単です。 しかし、 高給の仕事を見つけるのはまだ難しいです。 パラドックス? それでも、ほとんどの場合、これは事実です(もちろん、「Javaプログラマー」としてではなく、フルスタックとしてフルスタックを使用する場合を除きます)。 仕事の最初の日/月から多くのお金を払う場合、通常は「スイス人と刈り取り機、パイプを演奏する男」の両方は必要ありません。 ティムリッドが言ったように 。 もちろん、例外もありますが、私たちが望むほど多くはありません。



1つのヘルメットで作業することは、リソースの有限性を意味します。 つまり 本当に大きなソフトウェア製品を実装することはできません。 十分な知識があったとしても、十分な時間はありません。 キラーゲーム(小さなインディーの開発は良いが、それについてではない)、オペレーティングシステム、またはMega-Office-XXLをリリースすることはできません。 多くの場合、強さを計算せずに大規模なプロジェクトに取り組むと、人々は燃え尽きます。 ゲームを作りたい、または大規模なプロジェクト(通常は国際的な)に参加したい、または極端な場合、いずれかの分野で大学(2〜3年の現役)の直後に良い給料をもらいます-あなたもここにいません。



常に勉強する必要があります。 常に。 たくさん。 別のものに。 震えでの研究の年月を思い出すと、会議やウェビナーは嫌いです。何時間もの情報ゴミを読む準備ができておらず、役に立つ粒子を探しているなら、あなたが望みや好みに関係なく管理できる技術に悩まされているなら-フルスタックパスは必要ありません。 ここでいくつかのZenが必要であることを理解する(そして受け入れる)必要があります。 あなたは自分自身を何が起こっているのかから引き離す必要があります。



人が実際に1タスクの牛であることを決して忘れないでください。ただし、常にマルチタスクモードをエミュレートする必要があります(異なる言語、異なる開発環境、異なるアプローチですが、「コードの記述」と「インフラストラクチャのデプロイ」の概念は異なります)。 信じてください。最初は非常に難しく、低速で多くのエラーにつながります。



そして最後に、状況によって人質にされるリスクが常にあり、仕事の場所にキャリアの梯子が含まれていない場合、開発を停止します。 そして、何千人もの潜在的に優秀な労働者が悲しいことに小さな机に座っており、10年前に望んでいたことをまったくしていません。 はい、彼らはWindows Server、* nix、多分JavaとPythonでそれを行うことができます、彼らはC#でいくつかのクラフトをサポートします、昔は「企業ポータル」はPHP + JSで書かれていましたが、それ以上のタスクはなく、すべてがオフィスでデバッグされています、すべてが機能します。

そして、人々に組み込まれた保守主義が含まれる35-40年で国境を越える価値があり、この居心地の良い沼が乗算され、最終的に一種の「ハンドルのないスーツケース」につながります。 そして、この悪循環を断ち切ることは毎年難しくなります。 あごひげとセーターは10年間同じものを書いてきた狭い専門家の成長よりもさらに速く成長するため、このような状態には注意してください。



おそらく今日のホラー映画は十分でしょう、プロについて話しましょう



何でもできます。 まあ、またはほぼ。 企業のWebサイトからモバイルアプリケーションまで。 結局のところ、あなたは1〜2の技術に限定されません。 単一のイントラネット上にマイクロ帝国を構築することもできます。



フルスタックで長い間作業している場合(そして最も重要なこと-成功した場合)、開発チームを簡単にリードできます。 建築家になる。 主要なプロジェクトの最前線にいる人々。



陰鬱な内向者なら、車を愛し、人が好きではない-リモートサイトでお金を稼ぎましょう。 いくつかのプロジェクトをゆっくりとリードしているので、チームとコミュニケーションをとるのに神経を使わずに良いお金を稼ぐことができます。



人とのコミュニケーションが好きな人は、中断された(または訓練された)言語を持っています(または、あなたは意志の強いjustな内向者です)-顧客の魂に浸透することで、より多くのお金を稼ぐことができます。



仕事をせずに放置されることは決してないことを理解すべきです。 あなたが正しいフルスタックであるなら、あなたはどんな技術でも真ん中に引っ張るべきです。 また、「シニアミドルハンド」であっても(これは、Googleがストリートからチームリードを奪うことはありませんが、多かれ少なかれ真剣なプロジェクトです-それは簡単です)。



そして最後に、いくつかの簡単で明白な(すべてではなく、必ずしもすべてではない)ヒントを紹介します。 読者を飽きさせないために、インフラストラクチャではなくコードベースに意識的に焦点を当てます。



ヒント1。 あなたのプライドがあなたに勝ってはいけません 。 これは非常に重要です。 あなたより良いことをする人がいることは当然だと思います。 可能であれば、それらから学びます。 「あなたはすべてたわごとですが、私は完全なスタックです、私はすべてを行うことができます」というアプローチは根本的に間違っており、しばしば虚栄心だけでなく財布にも当たります。 自分とお金を愛しているなら、このアドバイスに従ってください。



ヒント2。 数年に1、2回、狭い専門家のチームで働くことは素晴らしいことです。 この技術は静止しているのではなく、機関車の速度で急いでおり、狭い専門家がトレンドになろうとするため、スキルが大幅に向上します。 そのような機会がある場合-それを逃さないで、たくさん学び、古いプロジェクトで多くのボトルネックを見つけ、新しいプロジェクトでそれらを許可しないでください。



ヒント3。 すべてのYaPを学習しようとしないでください。 第一に、それは単に不可能であり、第二に、それは必要ではありません。 あなたのプロジェクトで、あなたが本当に「署名者」である、よく研究された技術で使用してください。 (少なくとも一般的な開発のために)新しい核物質を研究する必要がありますが、それらが実際に明らかになった後にのみ、実際のプロジェクトにそれらを適用すべきです。 JavaからKotlinまたはScalaへの移行から、言語をどのように直接使用し、どのような品質で使用できるか、どのようなメリットを得ることができるか。 メリットを理解していない場合は、言語がまだ成熟していないか、または(おそらく)自分自身です。 「スペックを読むのに2週間を与え、このたわごとに書きます」というアプローチは悪いアプローチです。



ヒント4。 1〜3年前に開発のコードを見て、それを修正したくない場合は、開発者のような(またはあらゆる点で理想的なコードではない)危機に陥っている可能性が高いです。 ヒント#2を試してください。



ヒント5。 パスの最初から、顧客ベースを開発します。 権限を構築します。 あなたとあなたの開発は知っている必要があります。 企業で働くか、リモートサイトでフリーランスで働くかは関係ありません。 人とのコミュニケーションに問題がない場合は、必ず顧客とのコミュニケーションに時間を費やしてください。 そして二重に必要-あなたの製品で作業しなければならない人々と直接通信するために。 そのため、将来のプロジェクトのアーキテクチャをよりよく考えることができます。



ヒント7。 ツールとタスクを測定します。 スズメの大砲から撃ってはいけません。 1ページの「企業サイト」に対する社会的責任の低いブラックジャックと女の子を含むローカルインフラストラクチャを展開する必要はありません。 カスタマイズできること。 また、5MBのJSフレームワークをこのサイトにドラッグする必要もありません(それらを使用できるからです)。



場所が後ろにあるものを後ろから前にドラッグする必要はありません。 逆に、しないでください。 開発中に技術仕様が100,500回変更されていないプロジェクトに突然あまりにも多くの松葉杖がある場合、アーキテクチャの設計が不十分であることを忘れないでください。 可能な場合は修正し、そうでない場合は、次のタスクでこれを考慮してください。



第8回評議会。 優先順位を正しく設定します。 あなたの仕事は、何よりもまず製品を便利信頼できるものにすることです。 肥大した美意識を持っているとしても、美は最後にもたらされるべきです。



ふう おそらくこれで開始できます。



ご清聴ありがとうございました。



ああそう、私はほとんど忘れていました...大騒ぎを始めましょう!



All Articles