POSTD PRODUCED BY NIJIBOX

POSTD PRODUCED BY NIJIBOX

ニジボックスが運営する
エンジニアに向けた
キュレーションメディア

POSTD PRODUCED BY NIJIBOX

POSTD PRODUCED BY NIJIBOX

ニジボックスが運営する
エンジニアに向けた
キュレーションメディア

FeedlyRSSTwitterFacebook

本記事は、原著者の許諾のもとに翻訳・掲載しております。

バックエンドエンジニアとフロントエンドエンジニアの違いは、前者は1つの環境で仕事をするのに対し、後者は予期せぬことが起こる可能性のある数多くの環境で仕事をするということにあります。

「複雑なJavaScriptで動くWebサイトやWebアプリが動作する環境は、単一的で一枚岩のものである」――この無意識な思い込みこそが、バックエンド中心に開発されたWebベースプロジェクトにおいてフロントエンドエンジニアが目にする問題の根本的な要因であると私は考えています。

さらに悪いことに、バックエンドエンジニアは、フロントエンドエンジニアよりも複雑なアプリケーションを構築するのに長けていると考えています。実際そうなのかもしれないのですが、好ましくないのは、彼らの中にはフロントエンドについて学ぼうという意識に欠けている人がいることです。

アプリケーションの構築において、数多くの困難な環境に対応するフロントエンドの技術を平然と否定し、自分が正しいと主張することは、「典型的なバックエンドエンジニアは傲慢である」という印象を与えることになります。もし、あなたが教える立場になりたいのであれば、まずは学ぶことです。

定義

Angularの記事 で、私はフロントエンドエンジニアとバックエンドエンジニアをはっきりと定義しませんでした。そのことについて、私は批判を受けたのですが、それはもっともな意見です。

ですから、ここでフロントエンドエンジニアとバックエンドエンジニアについてちゃんと定義したいと思います。この重要な点について ツイート してくれたRobson Sobralに感謝します。

  1. バックエンドエンジニア とは、単一の環境、つまりサーバ上で仕事をする人のことを指します。彼らは、新しいソフトウェアをインストールしたり、ハードウェアをアップグレードしたりするなど、環境を変更する権限を持ちます。
  2. フロントエンドエンジニア とは、全く異なる数えきれないほどの環境で仕事をする人のことを指します。最新のデスクトップコンピュータから3年落ちのものだったり、メモリが少なく処理に時間がかかるような古い電話だったりと様々です。彼らは、ユーザのブラウザに対して何もすることができないため、その環境を変更することができません。それでも、すべての環境で動作するコードを作る必要があります。

前置きになりますが、これから記述することは、典型的なフロントエンドエンジニアからやんわりと叱られることのある典型的なバックエンドエンジニアに焦点を当てていきます。どちらのタイプの開発にも長けている人や、ここで述べている落とし穴に対処することができる人にとっては公平ではないかもしれませんが、こうすることで私が何を言おうとしているのかをお分かりいただけると思います。

説明

最初に書いた記事には、この項目は含まれていませんでしたが、フロントエンド環境がいかに不利であるということが、何人かのバックエンドエンジニアには理解してもらえていないようでしたので、新たに追加することにしました。

サーバが不思議な動作をすることについて、 いくつかコメント をもらいました。OSやPHP、MySQLの不具合、おかしなクラウドソフトウエア、ルート証明書の問題、カーネルパニックなどです。これらは簡単なことではありません。しかし私が言いたいのはそういうことではありません。

例を挙げて比べてみましょう。以下のように設計されたサーバサイドのビジネスアプリケーションを想像してみてください。

  1. 5つの最も一般的なJava webサーバ環境で起動する必要があり、そのうち3つの環境では、6週間おきに新しいバージョンがリリースされる。
  2. データは4つのクラウドサーバに保存され、そのうち2つのサーバにはひどいAPIと深刻なダウンタイムの問題がある。そしてどれも独自のカスタムソリューションを必要とする。
  3. 3つのCDNを使用する。そのうち1つのネットワークはまだ公開されていないが、6ヵ月後には多くのユーザが使用すると予想されている。
  4. 証明書の発行者はお互いを快く思っていないので、意図的に互換性をなくしたルート証明書が2つ必要である。
  5. 自分のコンピュータではなく、 ユーザのコンピュータで カーネルパニックが発生する。
  6. 2つのJavaサーバ環境と新しいCDNでのみまともなドキュメンテーションが存在する。その他は、異なる開発者によって作成された大まかなドキュメンテーションである。
  7. これらすべては6ヵ月ごとに変更する。

フロントエンドの世界と比較してみると、バックエンドは非常に静かで安全な環境と言えます。このことを良く覚えておいてください。

(例外として、オープンソースソフトウエアでは、いくつかのサーバ環境で対処する 必要があるかも しれません。確かにそうなのですが、この記事では主にエンタープライズJavaについて話をしています。)

世界で最も悪意のある開発プラットフォーム

私は、フロントエンドのアプローチだけがWebに適していると考えています。ちなみにここで言うWebとは、ほぼ静的なHTMLページから装飾豊かで多数のビューを持つシングルページwebアプリまで、ブラウザ上で動作するあらゆるwebアプリケーションを指します。もし、ブラウザでコードを起動させたいのであれば、Douglas Crockfordが言う、世界で最も悪意のある開発プラットフォームを知っておくべきです。

そういう訳で、私は 他の方の記事 に書かれていた以下のフロントエンドの再定義に同意することができません。それは

フロントエンドとは、Webアプリの構成部分のうち、「ブラウザのJavaScriptエンジン上で動作する部分」というよりも「ユーザーインターフェイスに関連する部分」である

というものです。

私は、ユーザインターフェイスとJavaScriptを意図的に分けて考えることには賛成できません。HTMLやCSS、JavaScriptで書かれた全てのものは、それが動作する多くの環境への理解が必要です。

例えば「何故offsetWidthを参照することは危険になりうるのか」「様々なブラウザにおいて、いつイベントが発火するか(又は発火しないのか)」「あなたのコードがDOM操作を行う際のパフォーマンス」などについて知らなければなりません。

これらの懸念点の対処をフレームワークに任せる場合でも、あなたの好む環境だけではなく、幅広い環境でどのようにフレームワークが機能するのかを知っておかなければなりません。将来的にこの問題はフロントエンドやバックエンドの感度に応じた新世代のフレームワークによって解決されるかもしれませんが、今現在そのようなフレームワークはあまり存在していません(もしくは世に知られていません)。

無意識な思い込み

典型的なバックエンドエンジニアは、ブラウザを「モダンなコンピュータ上で動作する、一枚岩のアプリケーションプラットフォーム」と捉えがちです。しかし、これが正しかったのは3~4年前のことであり、今ではこの認識がが正しいと言えるのはイントラネット上ぐらいのものです。モバイルブラウザの出現は、私たちに制限された環境を検討せざるを得ない状況に追い込みました。例えば複雑なスクリプトを起動させることが難しかったり、ブラウザは良いものなのにネットワークが良くなかったりといった環境です。

同じ動作を行う2~3の異なるやり方を提供するフロントエンドを例にして考えます。このようなフロントエンドが実装される理由は、アプリケーションを正しく構築できていないからではなく、数多くの環境でコードを起動させる必要があり、またいくつかのタイプの環境では異なるアプローチが必要だからです。

その良い例として、アプリケーションのJavaScript無しのバージョンが挙げられます。通常、バックエンド駆動で開発されたシングルページアプリケーションではJavaScript無しのバージョンを提供しません。これが道理に適うケースは、1つの環境のみでコードが起動することを無意識に想定している場合です。私たちの開発環境はXであり、X以外の開発環境を持たず、X上でアプリケーションが動作して、それで済むケース。その状況でJavaScriptを無効にする人は誰もいません。

これらの議論に抜け落ちているのは、JavaScript無しのバージョンという観点です。実際にJavaScriptを無効にするユーザがほとんどいなかったとしても、JavaScript無しのバージョンは「JavaScriptをサポートしているが、実行速度が遅すぎるという理由だけでコードの実行に失敗する」というようなブラウザにも対応しています。この場合、監視スクリプトが「フルバージョンのWebアプリケーションでは動作が遅い」と判断し、ユーザをJavaScriptがないバージョンに切り替えてしまいます。つまり、JavaScriptがないバージョンは、フルバージョンよりも異なる環境に対応しているのです。

「これらのひどいモバイルブラウザは、私たちのサポートブラウザリストにはありません」。こんなことを言われることがあります。その場合、私はこう答えます。「サポートブラウザリストを作成したのは誰ですか? もしあなたが、アプリケーションがXという環境でのみ起動すべきと想定しているのであれば、X以外の環境をサポートリストから外すことはとても魅力的でしょう。そのせいで、X上だけでしか使えないばかりに代替性のないシングルページアプリに、いとも容易くなってしまうでしょうけどね。」

バランスの欠如

典型的なバックエンドエンジニアは、すべてのWebアプリケーションやそれが動作する環境について、それぞれについて異なる対応が必要な多様な環境からなるものと見なしておらず、全て一枚岩のものだと思っている。これが私の結論です。

同時に、彼らはアプリケーション構築において、フロントエンドエンジニアよりも長けていると考えています。私の知る限り、それは確かですし、多くのことを彼らから学びました。

ただし問題は、バランスに欠けているということです。バックエンドエンジニアは、私たちの言っていることを理解しようともせずに自分たちの言い分を理解してもらおうとしています。相手の考えを否定しておきながら、自分の考えに同意しない人を非難することは、傲慢な人という印象を与えてしまいます。

明らかに横柄な態度は、技術的な問題がどうという以前に不愉快な気分にさせられます。私自身、過去15年間このような問題に直面しています。もし誰かに何かを教えるのであれば、まずは自分が学ぶことを覚えましょう。

監修者
監修者_古川陽介
古川陽介
株式会社リクルート プロダクト統括本部 プロダクト開発統括室 グループマネジャー 株式会社ニジボックス デベロップメント室 室長 Node.js 日本ユーザーグループ代表
複合機メーカー、ゲーム会社を経て、2016年に株式会社リクルートテクノロジーズ(現リクルート)入社。 現在はAPソリューショングループのマネジャーとしてアプリ基盤の改善や運用、各種開発支援ツールの開発、またテックリードとしてエンジニアチームの支援や育成までを担う。 2019年より株式会社ニジボックスを兼務し、室長としてエンジニア育成基盤の設計、技術指南も遂行。 Node.js 日本ユーザーグループの代表を務め、Node学園祭などを主宰。