フルスタック開発

Nov 25 2022

最近、フルスタック開発者という用語がますます頻繁に使用されています。特に、チーム構造、採用要件、または個人の純粋な素晴らしさを推測するための議論で。

UnsplashのMike Marrahによる写真

履歴書でこの種の声明を見たり、誰かが自分自身をフルスタックであると説明しているのを聞いたりすると、多くの質問が頭に浮かびます。

フルスタック開発とはどういう意味ですか?
どのスタックをマスターしていると主張していますか?
各要素について、あなたの知識はどのくらい広範ですか? どのくらいいっぱいにする必要がありますか？

フルスタックの開発者は実在しますか? 彼らは本当に存在しますか？
それらが存在する場合、なぜそれらは有用ですか?
フルスタックは、すべての取引のジャックと言う別の方法ですか?

バックグラウンド

詳細に入る前に、私たちが何を開発して提供しようとしているのかを定義する価値があります。

ラップトップ上で実行される PoC のフルスタック開発者であると主張することは、そのソリューションのすべての部分を開発する 1 人の人物であるため、ほぼ間違いなく公正な説明です。規模は非常に小さいため、設計や開発の不備による影響は非常に限定的です。基本的に、サービスを提供しない概念を証明しています。CIO への 1 時間のデモで機能する限り、問題ありません。

ソリューションをライブの顧客データを処理し、ビジネス価値の生成を促進する洞察/データを生成する本番システムであると定義すると、状況は異なり、コーディングエラーや不適切なプラクティスの影響ははるかに大きくなります。

この投稿では、大量 (1 日あたり数十 GB) の実際の顧客データ (PII を含む) を処理し、少なくとも 2 9 の可用性で主要なビジネスサービスを提供するシステムを検討します。

フルスタック開発者が価値があるのはなぜですか?

そのような人々の存在を脇に置いても、彼らが提供する利益は自明です。外部サポートなしでソリューションを設計、構築、実行できます。これは、時間がかかり、エラーが発生しやすい設計ワークショップ、コンポーネントの統合、テストサイクル、および運用の引き継ぎが大幅に削減されることを意味します。ソリューションを設計、構築、実行できるため、セキュリティ、プラットフォーム、DB、運用、… SME の間で会議をスケジュールする必要はなく、さらに悪いことに一連の会議を行う必要もありません。これらの少数の神 (小さな g) のような開発者が、大規模なクロスファンクショナルチームの作業を提供できます。ハンドオフのオーバーヘッドが排除されるため、提供もはるかに高速になり、エラーが発生しにくくなります。

では、これらの明らかな利点に基づいて、すべての IT 組織でこれらの人々で構成されるチームが増えないのはなぜでしょうか? これらの忍者チームを構築するために、企業が積極的に採用とトレーニングを行わないのはなぜですか? バットマンやトニー・スタークに相当する開発者が実際には存在しないからですか?

これらの質問に答えるには、(非常に) 単純化されたスタックがどのようなものかを調べる必要があります。

単純化されたスタック

単純化のために、プラットフォームインフラストラクチャは省略しています。

上記の要素を見ると、各レイヤーのエキスパートになるのが難しいことは明らかです。ただし、各レイヤーのすべてを知る必要がないと仮定すると、必要な知識を減らしてもフルスタックと見なすことができますか? フロントエンドアプリをドメインの例として取り上げると、Android と iOS を簡単に削除して Web チャネルのみに集中し、さらに洗練して React に限定することができます。それはどのように役立つでしょうか?

削減された範囲に基づいて、React Web アプリについて何を知る必要がありますか?

最初に、シングルページアプリがどのように機能するか、特に Web アプリのビルド、デバッグ、実行に必要なコア原則と、npm、webpack、コンテンツ管理、react devtools、UX ガイドラインなどの関連ツールを理解する必要があります。

また、マテリアル UI、redux、bootstrap などのサードパーティが提供する機能や、npm などのパッケージ管理ソリューション (セキュリティの脆弱性の管理を含む。通常は DevOps の考慮事項です。後述の注記を参照してください) に精通している必要があります。

最初のコンテンツペイントまでの時間、インタラクティブまでの時間、ブロック時間などのパフォーマンスについてはどうでしょうか。パフォーマンス要因と、React DevTools や Lighthouse などの分析をサポートするツールの利用にさまざまなコアパターンがどのように役立つかを理解する必要があります。

アクセシビリティは、アプリが内部または外部に配信されるかに関係なく、すべてのアプリケーションにとって必須です。WCAG ガイドラインに確実に準拠するにはどうすればよいですか?

要約すると、フロントエンドレイヤーだけで多くのことを知る必要があり、間違いなくこれが軽量化を維持しています。残りのレイヤーも同じで、多くの場合、複雑さが増します。さらに悪いことに、アーキテクチャのパターンと原則、ベストプラクティスとフレームワークは重複しません。

では、各レイヤーのパターン、標準、ベストプラクティス、および実践的なスキルを頭に詰め込むことができたと仮定すると、他に何を知る必要があるでしょうか? 必要なサポート機能はありますか?

サポート機能

技術スタックと並んで、ソリューションのすべてのコンポーネントを設計、構築、提供、実行するために必要なサポート機能が多数あります。

アーキテクチャとソフトウェアエンジニアリング

あらゆる言語/フレームワークで優れた実装を作成するレイヤー全体でアーキテクチャ設計をサポートするためのコアスキルセット

SOLID (単一責任、オープン/クローズ、置換、インターフェース分離、依存関係逆転)
「illities」の再利用性、保守性、移植性、拡張性、…
水平および垂直スケーリング
コーディング構造
ロギング
コードレビュー
…

上記の単純化されたスタックの各レイヤーと各レイヤー内のコンポーネント (Web チャネルの観点からは、フロントエンドはブラウザーによって実装されているか、通常はクライアント側であるため制御できないため無視されます) は、セキュリティの観点から慎重に検討する必要があります。例えば

API : TLS、DDoS、認証と認可、COR、コンテンツセキュリティポリシーなど
マイクロサービス : TLS (MA を含む)、アクセス制御、シークレット管理、ユーザー入力の検証など
データ: アクセス制御、保存時の暗号化、キー管理、ネットワークセキュリティグループとサブネットなど
プラットフォーム (追加) : ネットワークセキュリティ、固定コンポーネント構成 (ChefInspec など)

すべての開発者はコアテストスキルを必要とします。独自の機能をテストできないことについて言い訳はできません。そして、上の図のすべてのコンポーネントを意味するフルスタック環境で。

テストのさまざまな種類とフェーズを理解し、適用できるようになる (自分の宿題には印をつけないでください):

機能的および非機能的
ブラックボックス vs ホワイトボックス
ユニット、統合、システム、ユーザー受け入れ、回帰、スモーク、…

継続的インテグレーションと継続的デプロイパイプラインの開発と維持

多くの場合、CICD のコアイネーブラーは集中化された専用チームによって作成されますが、少なくとも全員がパイプラインを更新および維持できる必要があります。(はい、知っています。DevOps チームがある場合、DevOps を行っているわけではありませんが、多くの組織は行っています)

次のようなツールを使用します。

ジェンキンス、TravisCI、スピンネーカー
GitHub、ビットバケット
ソナークベ
ザプロキシ
ベラコード、Snyk
ドッカー、アンカー、ハーバー
…

「ビルドして実行する」アプローチを無視すると、フルスタック開発者の操作に関する要件が大幅に簡素化されます。

アプリケーションを操作可能に構築することに焦点を当てる必要があります。必要なすべての診断フック、イベントログ、実行ブックを含めて、実行チームが開発チームの助けを借りなくても問題をトリアージして潜在的に解決できるようにする

もちろん、上記の機能に対する説明責任は、組織の管理方法に基づいている可能性があります。開発は厳密に単体テストのみである場合もあれば、セキュリティテストを除いてすべてのテストがスクラムチーム内で行われる場合もあります。しかし、他の人からのサポートを必要とせずに API 開発と CICD パイプライン管理を引き受けることができれば、多くの時間を節約できます。

技術スタックのレイヤーと同様に、フルスタックステータスを主張するために必要なサポート機能の範囲は広大です。

結論

真のフルスタック開発者は (大部分) 神話であり、1980 年代にスタックが 6502 でアセンブラーを実行することを超えて以来ずっとそうでした。K8 ノードで実行されている Node で記述されたいくつかの API と通信するフロントエンドを取得して実行することは、フルスタックの開発者であることを意味すると思い込まないでください。

これらの個人は、さまざまな技術分野で必要とされる深い知識と経験のためだけでなく、この範囲が拡大し続けているため、神話的な存在です。これまでのところ、非常に困難です。

また、これらの個人は一般に、ほとんどの IT 組織が支払う余裕があるよりも多くのお金を要求しますが、広告が示すように、彼らが本当にフルスタックである場合、それだけの価値があります。

あなたが達成したいと望むことができる最善のことは、選択したドメイン (そのレイヤー内の限られた技術スタックを持つ特定のレイヤー) の習得であり、せいぜい能力と、他の分野での知識の欠如の認識であることを提案します.

チームが成功するためのより良い方法は、フルスタックの開発者を募集したり訓練したりするのではなく、フロントエンド、バックエンド、データベースなどのドメインを作成し、特定のドメイン内で忍者レベルの知識を得るために努力することです (再び高品質の開発をサポートするための非常に明確なインターフェース、標準、ベストプラクティス、およびフレームワークを使用して、他のドメインへの重複/クロスオーバー知識を使用します。個人が専門家レベルで複数のドメインにまたがることができればそれは素晴らしいことですが、私の経験では、これは本当に例外です。

おまけコメント：

データサイエンスの開発者として「より多くの」成功を収めるために、何を知る必要がありますか (データサイエンティストという用語ではなく、開発者という言葉を使用していることに注意してください。あなたはすでに優れたデータサイエンティストだと思いますか? そうでない場合は、私はそこであなたを助けることはできません!)。この開発者を、これらの各領域にわたって開発できるが、データサイエンスの部分*の専門家であると定義すると、より広範なスタックの産業化は機械学習エンジニアが行うことになりますが、その議論は別の機会に。