Lock in $30 Savings on PRO—Offer Ends Soon! ⏳
Speaker Deck
Features
Speaker Deck
PRO
Sign in
Sign up for free
Search
Search
アプリエンジニアがサーバとクライアントサイドのどちらも実装してみた / Applicatio...
Search
Yuta WATANABE
August 13, 2019
Technology
0
490
アプリエンジニアがサーバとクライアントサイドのどちらも実装してみた / 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
小さな判断で育つ、大きな意思決定力 / 20251204 Takahiro Kinjo
shift_evolve
PRO
1
580
pmconf2025 - 他社事例を"自社仕様化"する技術_iRAFT法
daichi_yamashita
0
780
Playwrightのソースコードに見る、自動テストを自動で書く技術
yusukeiwaki
13
4.9k
Snowflakeでデータ基盤を もう一度作り直すなら / rebuilding-data-platform-with-snowflake
pei0804
2
640
モバイルゲーム開発におけるエージェント技術活用への試行錯誤 ~開発効率化へのアプローチの紹介と未来に向けた展望~
qualiarts
0
660
AWS Trainium3 をちょっと身近に感じたい
bigmuramura
1
120
意外とあった SQL Server 関連アップデート + Database Savings Plans
stknohg
PRO
0
290
Noを伝える技術2025: 爆速合意形成のためのNICOフレームワーク速習 #pmconf2025
aki_iinuma
2
2.1k
5分で知るMicrosoft Ignite
taiponrock
PRO
0
210
グレートファイアウォールを自宅に建てよう
ctes091x
0
140
Sansanが実践する Platform EngineeringとSREの協創
sansantech
PRO
2
650
ログ管理の新たな可能性?CloudWatchの新機能をご紹介
ikumi_ono
0
490
Featured
See All Featured
Building Flexible Design Systems
yeseniaperezcruz
330
39k
Stop Working from a Prison Cell
hatefulcrawdad
273
21k
Making the Leap to Tech Lead
cromwellryan
135
9.7k
Fight the Zombie Pattern Library - RWD Summit 2016
marcelosomers
234
17k
I Don’t Have Time: Getting Over the Fear to Launch Your Podcast
jcasabona
34
2.5k
Mobile First: as difficult as doing things right
swwweet
225
10k
Code Review Best Practice
trishagee
74
19k
What's in a price? How to price your products and services
michaelherold
246
12k
A Modern Web Designer's Workflow
chriscoyier
698
190k
Agile that works and the tools we love
rasmusluckow
331
21k
What’s in a name? Adding method to the madness
productmarketing
PRO
24
3.8k
Being A Developer After 40
akosma
91
590k
Transcript
アプリエンジニアがサーバとクライアントのどち らも実装してみた @Evitch
今回、新規機能を開発するにあたって うちのチームがやった開発プロセスがすごい綺麗だった と思うから、 Evitchくんのやつ具体例として紹介してよ しょうがないですねえ... (わかりました!やらせてください!) このスライドを作るにあたった経緯
目次 • インターフェース仕様を決めた話 • データベースを設計をした話 • フローチャートを描いた話 • シーケンス図を描いた話 •
サーバサイドを実装した話 • クライアントサイドを実装した話 • 協業先に直接赴いてミーティングしてきた話 • 感想
インターフェース仕様を決めた話 * やったこと • APIのINPUT / OUTPUTをまとめたインターフェース仕様書を書いた • 設計リーダー、開発リーダーにレビューしてもらった *
思ったこと • APIの話をするときは、基本このインターフェース仕様書がベースになる • これだけは常に最新の状態にしておかなければいけない • めっっっちゃ大事
実際のインターフェース仕様書 APIの名前 メソッド エンドポイント APIの詳しい説明 リクエストパ ラメータ レスポンスパ ラメータ
データベース設計をした話 * やったこと • テーブル設計をまとめたデータベース設計書を書いた • 設計リーダー、開発リーダーにレビューしてもらった * 思ったこと •
マイグレーションファイルを作るとき以外はあまり見なかった • ただし、プロジェクトの規模が大きく、リレーションが複雑である場合はちゃんとや らないとダメそう
実際のデータベース設計書 テーブル名 テーブルの 詳しい説明 カラム情報 1
フローチャートを描いた話 * やったこと • 機能が全体としてどう動くのかをまとめたフローチャートを描いた • 開発リーダーにレビューしてもらった * 思ったこと •
条件分岐こうなるんだー • なんとなく機能の全体像が見えた気がした
実際に描いたフローチャートと紛失したフローチャート ・クライアント 属性情報登録時 ・サーバ 紛失
シーケンス図を描いた話 * やったこと • フローチャートを参考にシーケンス図を描いた • 開発リーダーにレビューしてもらった • シーケンス図を描いてると、フローチャートに漏れがあったことに気づきフロー チャートを修正した
* 思ったこと • シーケンス図に条件分岐を含めてはいけない、わけがわからなくなる • 大きい部分から小さい部分という流れがわかりやすくて良い
条件分岐を書いてわけがわからなくなったシーケンス図 開発リーダーから悲鳴が聞こえた気がし たが、おそらく気のせいだろう…
サーバサイドを実装した話 * やったこと • 今まで書いた設計書を元にサーバサイドを実装した • 開発リーダーにレビューしてもらった * 思ったこと •
設計書を書いている段階で、ある程度「こんな風に実装しよう」というのが頭に思 い浮かんでいた • 実際書いてみると「やっぱこっちの方がいいなあ」ということもあった
クライアントサイドを実装した話 * やったこと • 今まで書いた設計書を元にクライアントサイドを実装した • 開発チームメンバーにレビューしてもらった * 思ったこと •
うわっなにこのAPI !? 誰が作った !? • またサーバサイドの実装に戻るのも面倒だし、まあ動くからいいか... • 誰も何も言わないでくれと祈る
この API ってなんで項目名と ID どっちも送 るんですか? どっちかでよくないですか? おっしゃる通りです。修正します。
当時の API 仕様 項目名とIDの両方を送るという意味不明な仕様になっていた...
協業先に直接赴いてミーティングしてきた話 • 協業先のAPIに仕様変更があったことを弊社が把握していなかった • 他にも変更があった部分があるかもしれないので、 確認の意味も込めて一度ミーティングすることに 結果、APIのバージョン変更があった場合は 共有のSlackチャンネルで通知してもらうことに
感想 • 使う側にならないと気づかないことがたくさんあった • サーバサイドを実装しているときは、いかにサーバサイドで楽にするかを考えて いたため、仕様やクライアントサイドの実装にツケが回った • 本来はあり得ない挙動でも、実装時には十分起こり得る挙動があるので(同じ ユーザから属性情報登録APIが複数回叩かれる)、サーバサイドはそれを想定 してエラーメッセージを詳細に出すべきだった