はじめまして。サーバーサイドエンジニア&フロントエンドエンジニアの澤井です。FiNC Developer Advent Calendar 201612日目を担当します。
今年の4月からサーバーサイドエンジニアを始めてちょっと半年ぐらいやった後、フロント側を強化するということで、フロントエンジニアも始めてみまして、まだまだ圧倒的に色々駆け出しなんですが、その中で思ったことを書いてみました。
実装前段階の違い
サーバーもクライアントも実装前に設計について考えます。どちらも設計段階ではインターフェースの境界を設計するので、モデルやデータの実態を定義するレイヤと、その表示の仕方を定義するレイヤを設計します。
サーバーサイドだと
- データベース（Model）
- エンドポイント
- APIレスポンス（Viewに相当）
の設計をするし、
フロントは
- エンティティ（Data, Model）
- UIコンポーネント（View）
- ルーティング
の設計があります。
（明確にどういう設計がクライアントとしてレビューしやすい形かというのは、個人的にすごく模索しています。クリーンアーキテクチャみたいな考え方などもあったりして、結局各プロジェクトのアーキテクチャにもよるんじゃないかと思っています。すごく他の人の意見が聞きたい。）
最近APIの作成でも、リソース指向が強まってきて、ActiveModel Serializerが導入されたりしています。ここはクライアントもサーバーも同じリソースをAPI,Entityとしてやりとりしている部分なのでお互い齟齬なく書けるとすごく便利だなと感じています。
クライアントだとその他にもチームリソースを確保する必要があり、
- デザインリソース
- テキストリソース
の確保も必要です。この辺の記事にも、”Be The Middleman"って書かれていますね。
デザインはSketchを共有するよりも意味を共有したい
デザインを正確に反映するのが、フロントエンジニアとして大事なわけですが、その際にスケッチとかで共有されたデザインをコードに落とし込む際には、デザインの理解が問われる気がします。
デザインをコードに落とし込むときも、マージンが8pxだったとして、それはどういう意味なのかが理解できてる方が、意味のあるコードが書けメンテナンス性もあがるなと感じます。「これはline-heightの半分だから8pxだよね。」とわかってコードを書くのか、とりあえず8pxとハードコードしたのかの差は大きいと思います。
It's all about UI
最終的にユーザーに見せる部分なので、UIが全てだなと感じます。それは、フロント側の責務（非同期処理や、フォームの見せ方などをいかにユーザーが慣れ親しんだ形で見せるか）もあれば、サーバー側（キャッシュしたりサーバー側のパフォーマンスをどうするか）みたいな話もあって、これからもっと勉強していきたいなと感じている部分です。
両方できて良いこと
処理が全部自分で追える。
これに尽きるかなという感じです。だいたいの問題はインターフェイスの境界で起きるとは昔から言われていることですが、インタフェースのどっち側が問題の責務を負っているかを自分で追えるようになります。
問題が起きた際にそれはサーバー側かクライアントなのかを、エラーメッセージやHTTPステータスコードから分析できますし、パラメータがどう処理されているかも自分で読めばわかることもあるので、開発中とかで多少ドキュメントが曖昧でもなんとかなる確率が高いです。
エンジニア初めたばかりのインターン生とかにありがちなのが、APIのレスポンス自体を確認せずにサーバーがおかしいと騒いだりなんてことがあるんですが、そういうことせずに落ち着いて対応できたりします。
また、APIのリソース指向の重要性の理解度が高まった気がします。永続化されているDBからJSONなどのインターフェースを経て、クライアント側にデータが渡り、クライアントはそれをパースしたりしてビューに表示するのですが、それがすごく自分でもイメージしやすくなったなと感じます。
最後に
サーバーもフロントも両方やるといろいろと気付けることも多いです。社内にはiOS, Androidのクライアントメンバーもいて、同じクライアントサイドとして相談できることもあります。今かけることをポエムってっみましたが、3ヶ月後ぐらいにはもう少しレベルの高い文書を書きたいと思っています。