Upgrade to Pro
— share decks privately, control downloads, hide ads and more …
Speaker Deck
Features
Speaker Deck
PRO
Sign in
Sign up for free
Search
Search
アプリエンジニアがサーバとクライアントサイドのどちらも実装してみた / Applicatio...
Search
Yuta WATANABE
August 13, 2019
Technology
0
480
アプリエンジニアがサーバとクライアントサイドのどちらも実装してみた / Application engineer tried to implement both server and client side
Yuta WATANABE
August 13, 2019
Tweet
Share
Other Decks in Technology
See All in Technology
Claude Code に プロジェクト管理やらせたみた
unson
6
4.1k
Lufthansa ®️ USA Contact Numbers: Complete 2025 Support Guide
lufthanahelpsupport
0
200
DatabricksにOLTPデータベース『Lakebase』がやってきた!
inoutk
0
110
マネジメントって難しい、けどおもしろい / Management is tough, but fun! #em_findy
ar_tama
7
1.1k
無意味な開発生産性の議論から抜け出すための予兆検知とお金とAI
i35_267
4
13k
成長し続けるアプリのためのテストと設計の関係、そして意思決定の記録。
sansantech
PRO
0
120
さくらのIaaS基盤のモニタリングとOpenTelemetry/OSC Hokkaido 2025
fujiwara3
3
440
LangChain Interrupt & LangChain Ambassadors meetingレポート
os1ma
2
310
DBのスキルで生き残る技術 - AI時代におけるテーブル設計の勘所
soudai
PRO
50
20k
Lazy application authentication with Tailscale
bluehatbrit
0
210
【5分でわかる】セーフィー エンジニア向け会社紹介
safie_recruit
0
27k
AWS Organizations 新機能!マルチパーティ承認の紹介
yhana
1
280
Featured
See All Featured
Building a Scalable Design System with Sketch
lauravandoore
462
33k
Exploring the Power of Turbo Streams & Action Cable | RailsConf2023
kevinliebholz
34
5.9k
GraphQLの誤解/rethinking-graphql
sonatard
71
11k
Templates, Plugins, & Blocks: Oh My! Creating the theme that thinks of everything
marktimemedia
31
2.4k
Thoughts on Productivity
jonyablonski
69
4.7k
A Tale of Four Properties
chriscoyier
160
23k
Large-scale JavaScript Application Architecture
addyosmani
512
110k
"I'm Feeling Lucky" - Building Great Search Experiences for Today's Users (#IAC19)
danielanewman
229
22k
Building a Modern Day E-commerce SEO Strategy
aleyda
42
7.4k
Agile that works and the tools we love
rasmusluckow
329
21k
The Cost Of JavaScript in 2023
addyosmani
51
8.5k
Fantastic passwords and where to find them - at NoRuKo
philnash
51
3.3k
Transcript
アプリエンジニアがサーバとクライアントのどち らも実装してみた @Evitch
今回、新規機能を開発するにあたって うちのチームがやった開発プロセスがすごい綺麗だった と思うから、 Evitchくんのやつ具体例として紹介してよ しょうがないですねえ... (わかりました!やらせてください!) このスライドを作るにあたった経緯
目次 • インターフェース仕様を決めた話 • データベースを設計をした話 • フローチャートを描いた話 • シーケンス図を描いた話 •
サーバサイドを実装した話 • クライアントサイドを実装した話 • 協業先に直接赴いてミーティングしてきた話 • 感想
インターフェース仕様を決めた話 * やったこと • APIのINPUT / OUTPUTをまとめたインターフェース仕様書を書いた • 設計リーダー、開発リーダーにレビューしてもらった *
思ったこと • APIの話をするときは、基本このインターフェース仕様書がベースになる • これだけは常に最新の状態にしておかなければいけない • めっっっちゃ大事
実際のインターフェース仕様書 APIの名前 メソッド エンドポイント APIの詳しい説明 リクエストパ ラメータ レスポンスパ ラメータ
データベース設計をした話 * やったこと • テーブル設計をまとめたデータベース設計書を書いた • 設計リーダー、開発リーダーにレビューしてもらった * 思ったこと •
マイグレーションファイルを作るとき以外はあまり見なかった • ただし、プロジェクトの規模が大きく、リレーションが複雑である場合はちゃんとや らないとダメそう
実際のデータベース設計書 テーブル名 テーブルの 詳しい説明 カラム情報 1
フローチャートを描いた話 * やったこと • 機能が全体としてどう動くのかをまとめたフローチャートを描いた • 開発リーダーにレビューしてもらった * 思ったこと •
条件分岐こうなるんだー • なんとなく機能の全体像が見えた気がした
実際に描いたフローチャートと紛失したフローチャート ・クライアント 属性情報登録時 ・サーバ 紛失
シーケンス図を描いた話 * やったこと • フローチャートを参考にシーケンス図を描いた • 開発リーダーにレビューしてもらった • シーケンス図を描いてると、フローチャートに漏れがあったことに気づきフロー チャートを修正した
* 思ったこと • シーケンス図に条件分岐を含めてはいけない、わけがわからなくなる • 大きい部分から小さい部分という流れがわかりやすくて良い
条件分岐を書いてわけがわからなくなったシーケンス図 開発リーダーから悲鳴が聞こえた気がし たが、おそらく気のせいだろう…
サーバサイドを実装した話 * やったこと • 今まで書いた設計書を元にサーバサイドを実装した • 開発リーダーにレビューしてもらった * 思ったこと •
設計書を書いている段階で、ある程度「こんな風に実装しよう」というのが頭に思 い浮かんでいた • 実際書いてみると「やっぱこっちの方がいいなあ」ということもあった
クライアントサイドを実装した話 * やったこと • 今まで書いた設計書を元にクライアントサイドを実装した • 開発チームメンバーにレビューしてもらった * 思ったこと •
うわっなにこのAPI !? 誰が作った !? • またサーバサイドの実装に戻るのも面倒だし、まあ動くからいいか... • 誰も何も言わないでくれと祈る
この API ってなんで項目名と ID どっちも送 るんですか? どっちかでよくないですか? おっしゃる通りです。修正します。
当時の API 仕様 項目名とIDの両方を送るという意味不明な仕様になっていた...
協業先に直接赴いてミーティングしてきた話 • 協業先のAPIに仕様変更があったことを弊社が把握していなかった • 他にも変更があった部分があるかもしれないので、 確認の意味も込めて一度ミーティングすることに 結果、APIのバージョン変更があった場合は 共有のSlackチャンネルで通知してもらうことに
感想 • 使う側にならないと気づかないことがたくさんあった • サーバサイドを実装しているときは、いかにサーバサイドで楽にするかを考えて いたため、仕様やクライアントサイドの実装にツケが回った • 本来はあり得ない挙動でも、実装時には十分起こり得る挙動があるので(同じ ユーザから属性情報登録APIが複数回叩かれる)、サーバサイドはそれを想定 してエラーメッセージを詳細に出すべきだった