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
500
アプリエンジニアがサーバとクライアントサイドのどちらも実装してみた / 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
SRE Enabling戦記 - 急成長する組織にSREを浸透させる戦いの歴史
markie1009
0
120
プロダクト成長を支える開発基盤とスケールに伴う課題
yuu26
4
1.3k
モダンUIでフルサーバーレスなAIエージェントをAmplifyとCDKでサクッとデプロイしよう
minorun365
4
210
ブロックテーマでサイトをリニューアルした話 / 2026-01-31 Kansai WordPress Meetup
torounit
0
470
AIエージェントを開発しよう!-AgentCore活用の勘所-
yukiogawa
0
170
顧客との商談議事録をみんなで読んで顧客解像度を上げよう
shibayu36
0
240
Introduction to Sansan for Engineers / エンジニア向け会社紹介
sansan33
PRO
6
68k
Greatest Disaster Hits in Web Performance
guaca
0
250
Amazon Bedrock Knowledge Basesチャンキング解説!
aoinoguchi
0
140
usermode linux without MMU - fosdem2026 kernel devroom
thehajime
0
230
Azure Durable Functions で作った NL2SQL Agent の精度向上に取り組んだ話/jat08
thara0402
0
190
Introduction to Bill One Development Engineer
sansan33
PRO
0
360
Featured
See All Featured
Mind Mapping
helmedeiros
PRO
0
87
The Spectacular Lies of Maps
axbom
PRO
1
520
Discover your Explorer Soul
emna__ayadi
2
1.1k
How to Get Subject Matter Experts Bought In and Actively Contributing to SEO & PR Initiatives.
livdayseo
0
66
Introduction to Domain-Driven Design and Collaborative software design
baasie
1
590
Easily Structure & Communicate Ideas using Wireframe
afnizarnur
194
17k
Mobile First: as difficult as doing things right
swwweet
225
10k
Thoughts on Productivity
jonyablonski
74
5k
Abbi's Birthday
coloredviolet
1
4.7k
New Earth Scene 8
popppiees
1
1.5k
Why Our Code Smells
bkeepers
PRO
340
58k
How Fast Is Fast Enough? [PerfNow 2025]
tammyeverts
3
450
Transcript
アプリエンジニアがサーバとクライアントのどち らも実装してみた @Evitch
今回、新規機能を開発するにあたって うちのチームがやった開発プロセスがすごい綺麗だった と思うから、 Evitchくんのやつ具体例として紹介してよ しょうがないですねえ... (わかりました!やらせてください!) このスライドを作るにあたった経緯
目次 • インターフェース仕様を決めた話 • データベースを設計をした話 • フローチャートを描いた話 • シーケンス図を描いた話 •
サーバサイドを実装した話 • クライアントサイドを実装した話 • 協業先に直接赴いてミーティングしてきた話 • 感想
インターフェース仕様を決めた話 * やったこと • APIのINPUT / OUTPUTをまとめたインターフェース仕様書を書いた • 設計リーダー、開発リーダーにレビューしてもらった *
思ったこと • APIの話をするときは、基本このインターフェース仕様書がベースになる • これだけは常に最新の状態にしておかなければいけない • めっっっちゃ大事
実際のインターフェース仕様書 APIの名前 メソッド エンドポイント APIの詳しい説明 リクエストパ ラメータ レスポンスパ ラメータ
データベース設計をした話 * やったこと • テーブル設計をまとめたデータベース設計書を書いた • 設計リーダー、開発リーダーにレビューしてもらった * 思ったこと •
マイグレーションファイルを作るとき以外はあまり見なかった • ただし、プロジェクトの規模が大きく、リレーションが複雑である場合はちゃんとや らないとダメそう
実際のデータベース設計書 テーブル名 テーブルの 詳しい説明 カラム情報 1
フローチャートを描いた話 * やったこと • 機能が全体としてどう動くのかをまとめたフローチャートを描いた • 開発リーダーにレビューしてもらった * 思ったこと •
条件分岐こうなるんだー • なんとなく機能の全体像が見えた気がした
実際に描いたフローチャートと紛失したフローチャート ・クライアント 属性情報登録時 ・サーバ 紛失
シーケンス図を描いた話 * やったこと • フローチャートを参考にシーケンス図を描いた • 開発リーダーにレビューしてもらった • シーケンス図を描いてると、フローチャートに漏れがあったことに気づきフロー チャートを修正した
* 思ったこと • シーケンス図に条件分岐を含めてはいけない、わけがわからなくなる • 大きい部分から小さい部分という流れがわかりやすくて良い
条件分岐を書いてわけがわからなくなったシーケンス図 開発リーダーから悲鳴が聞こえた気がし たが、おそらく気のせいだろう…
サーバサイドを実装した話 * やったこと • 今まで書いた設計書を元にサーバサイドを実装した • 開発リーダーにレビューしてもらった * 思ったこと •
設計書を書いている段階で、ある程度「こんな風に実装しよう」というのが頭に思 い浮かんでいた • 実際書いてみると「やっぱこっちの方がいいなあ」ということもあった
クライアントサイドを実装した話 * やったこと • 今まで書いた設計書を元にクライアントサイドを実装した • 開発チームメンバーにレビューしてもらった * 思ったこと •
うわっなにこのAPI !? 誰が作った !? • またサーバサイドの実装に戻るのも面倒だし、まあ動くからいいか... • 誰も何も言わないでくれと祈る
この API ってなんで項目名と ID どっちも送 るんですか? どっちかでよくないですか? おっしゃる通りです。修正します。
当時の API 仕様 項目名とIDの両方を送るという意味不明な仕様になっていた...
協業先に直接赴いてミーティングしてきた話 • 協業先のAPIに仕様変更があったことを弊社が把握していなかった • 他にも変更があった部分があるかもしれないので、 確認の意味も込めて一度ミーティングすることに 結果、APIのバージョン変更があった場合は 共有のSlackチャンネルで通知してもらうことに
感想 • 使う側にならないと気づかないことがたくさんあった • サーバサイドを実装しているときは、いかにサーバサイドで楽にするかを考えて いたため、仕様やクライアントサイドの実装にツケが回った • 本来はあり得ない挙動でも、実装時には十分起こり得る挙動があるので(同じ ユーザから属性情報登録APIが複数回叩かれる)、サーバサイドはそれを想定 してエラーメッセージを詳細に出すべきだった