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
社内お問い合わせBotの仕組みと学び
nish01
1
530
スタートアップにおけるこれからの「データ整備」
shomaekawa
2
340
Simplifying Cloud Native app testing across environments with Dapr and Microcks
salaboy
0
120
Azure Well-Architected Framework入門
tomokusaba
1
350
ガバメントクラウドの概要と自治体事例(名古屋市)
techniczna
2
210
The Cake Is a Lie... And So Is Your Login’s Accessibility
leichteckig
0
100
SwiftUIのGeometryReaderとScrollViewを基礎から応用まで学び直す:設計と活用事例
fumiyasac0921
0
150
英語は話せません!それでも海外チームと信頼関係を作るため、対話を重ねた2ヶ月間のまなび
niioka_97
0
130
許しとアジャイル
jnuank
1
140
[Keynote] What do you need to know about DevEx in 2025
salaboy
0
150
研究開発部メンバーの働き⽅ / Sansan R&D Profile
sansan33
PRO
3
20k
AI時代こそ求められる設計力- AWSクラウドデザインパターン3選で信頼性と拡張性を高める-
kenichirokimura
3
220
Featured
See All Featured
Chrome DevTools: State of the Union 2024 - Debugging React & Beyond
addyosmani
7
900
Helping Users Find Their Own Way: Creating Modern Search Experiences
danielanewman
30
2.9k
Navigating Team Friction
lara
189
15k
Performance Is Good for Brains [We Love Speed 2024]
tammyeverts
12
1.2k
Writing Fast Ruby
sferik
629
62k
Stop Working from a Prison Cell
hatefulcrawdad
271
21k
How To Stay Up To Date on Web Technology
chriscoyier
791
250k
RailsConf 2023
tenderlove
30
1.2k
The Myth of the Modular Monolith - Day 2 Keynote - Rails World 2024
eileencodes
26
3.1k
10 Git Anti Patterns You Should be Aware of
lemiorhan
PRO
657
61k
Understanding Cognitive Biases in Performance Measurement
bluesmoon
29
2.7k
JavaScript: Past, Present, and Future - NDC Porto 2020
reverentgeek
52
5.6k
Transcript
アプリエンジニアがサーバとクライアントのどち らも実装してみた @Evitch
今回、新規機能を開発するにあたって うちのチームがやった開発プロセスがすごい綺麗だった と思うから、 Evitchくんのやつ具体例として紹介してよ しょうがないですねえ... (わかりました!やらせてください!) このスライドを作るにあたった経緯
目次 • インターフェース仕様を決めた話 • データベースを設計をした話 • フローチャートを描いた話 • シーケンス図を描いた話 •
サーバサイドを実装した話 • クライアントサイドを実装した話 • 協業先に直接赴いてミーティングしてきた話 • 感想
インターフェース仕様を決めた話 * やったこと • APIのINPUT / OUTPUTをまとめたインターフェース仕様書を書いた • 設計リーダー、開発リーダーにレビューしてもらった *
思ったこと • APIの話をするときは、基本このインターフェース仕様書がベースになる • これだけは常に最新の状態にしておかなければいけない • めっっっちゃ大事
実際のインターフェース仕様書 APIの名前 メソッド エンドポイント APIの詳しい説明 リクエストパ ラメータ レスポンスパ ラメータ
データベース設計をした話 * やったこと • テーブル設計をまとめたデータベース設計書を書いた • 設計リーダー、開発リーダーにレビューしてもらった * 思ったこと •
マイグレーションファイルを作るとき以外はあまり見なかった • ただし、プロジェクトの規模が大きく、リレーションが複雑である場合はちゃんとや らないとダメそう
実際のデータベース設計書 テーブル名 テーブルの 詳しい説明 カラム情報 1
フローチャートを描いた話 * やったこと • 機能が全体としてどう動くのかをまとめたフローチャートを描いた • 開発リーダーにレビューしてもらった * 思ったこと •
条件分岐こうなるんだー • なんとなく機能の全体像が見えた気がした
実際に描いたフローチャートと紛失したフローチャート ・クライアント 属性情報登録時 ・サーバ 紛失
シーケンス図を描いた話 * やったこと • フローチャートを参考にシーケンス図を描いた • 開発リーダーにレビューしてもらった • シーケンス図を描いてると、フローチャートに漏れがあったことに気づきフロー チャートを修正した
* 思ったこと • シーケンス図に条件分岐を含めてはいけない、わけがわからなくなる • 大きい部分から小さい部分という流れがわかりやすくて良い
条件分岐を書いてわけがわからなくなったシーケンス図 開発リーダーから悲鳴が聞こえた気がし たが、おそらく気のせいだろう…
サーバサイドを実装した話 * やったこと • 今まで書いた設計書を元にサーバサイドを実装した • 開発リーダーにレビューしてもらった * 思ったこと •
設計書を書いている段階で、ある程度「こんな風に実装しよう」というのが頭に思 い浮かんでいた • 実際書いてみると「やっぱこっちの方がいいなあ」ということもあった
クライアントサイドを実装した話 * やったこと • 今まで書いた設計書を元にクライアントサイドを実装した • 開発チームメンバーにレビューしてもらった * 思ったこと •
うわっなにこのAPI !? 誰が作った !? • またサーバサイドの実装に戻るのも面倒だし、まあ動くからいいか... • 誰も何も言わないでくれと祈る
この API ってなんで項目名と ID どっちも送 るんですか? どっちかでよくないですか? おっしゃる通りです。修正します。
当時の API 仕様 項目名とIDの両方を送るという意味不明な仕様になっていた...
協業先に直接赴いてミーティングしてきた話 • 協業先のAPIに仕様変更があったことを弊社が把握していなかった • 他にも変更があった部分があるかもしれないので、 確認の意味も込めて一度ミーティングすることに 結果、APIのバージョン変更があった場合は 共有のSlackチャンネルで通知してもらうことに
感想 • 使う側にならないと気づかないことがたくさんあった • サーバサイドを実装しているときは、いかにサーバサイドで楽にするかを考えて いたため、仕様やクライアントサイドの実装にツケが回った • 本来はあり得ない挙動でも、実装時には十分起こり得る挙動があるので(同じ ユーザから属性情報登録APIが複数回叩かれる)、サーバサイドはそれを想定 してエラーメッセージを詳細に出すべきだった