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
アプリエンジニアがサーバとクライアントサイドのどちらも実装してみた / Application engineer tried to implement both server and client side
Search
Yuta WATANABE
August 13, 2019
Technology
0
450
アプリエンジニアがサーバとクライアントサイドのどちらも実装してみた / 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
エンタープライズ環境下での Active Directory の運用 TIPS
tamaiyutaro
1
1.5k
Algyan イベント振り返り
linyixian
0
180
コンテナセキュリティの基本と脅威への対策
kyohmizu
3
680
Four keys改善の取り組み事例紹介
sansantech
PRO
3
230
Aurora MySQL v3(MySQL8.0互換)の オンラインDDLの罠挙動を全バージョンで検証した
yutakikai
1
150
なぜ NOT A HOTEL が Web3 に取り組むのか - NOT A HOTEL TECH TALK
ynunokawa
0
160
TransitGatewayの基礎
toru_kubota
0
230
強みを伸ばすキャリアデザイン
yug1224
0
200
コンパウンドスタートアップのためのスケーラブルでセキュアなInfrastructure as Codeパイプラインを考える / Scalable and Secure Infrastructure as Code Pipeline for a Compound Startup
yuyatakeyama
3
1.9k
オブザーバビリティの Primary Signals
onk
PRO
0
540
PHPカンファレンス小田原2024
ysknsid25
3
660
マルチアカウント環境への発見的統制の導入
ch1aki
1
1.3k
Featured
See All Featured
[RailsConf 2023] Rails as a piece of cake
palkan
22
3.9k
The Power of CSS Pseudo Elements
geoffreycrofte
59
5k
GraphQLとの向き合い方2022年版
quramy
31
12k
Intergalactic Javascript Robots from Outer Space
tanoku
266
26k
Designing the Hi-DPI Web
ddemaree
276
33k
Optimizing for Happiness
mojombo
370
69k
Six Lessons from altMBA
skipperchong
20
3k
Fontdeck: Realign not Redesign
paulrobertlloyd
76
4.9k
How GitHub (no longer) Works
holman
304
140k
Become a Pro
speakerdeck
PRO
10
4.5k
Product Roadmaps are Hard
iamctodd
43
9.7k
Automating Front-end Workflow
addyosmani
1355
200k
Transcript
アプリエンジニアがサーバとクライアントのどち らも実装してみた @Evitch
今回、新規機能を開発するにあたって うちのチームがやった開発プロセスがすごい綺麗だった と思うから、 Evitchくんのやつ具体例として紹介してよ しょうがないですねえ... (わかりました!やらせてください!) このスライドを作るにあたった経緯
目次 • インターフェース仕様を決めた話 • データベースを設計をした話 • フローチャートを描いた話 • シーケンス図を描いた話 •
サーバサイドを実装した話 • クライアントサイドを実装した話 • 協業先に直接赴いてミーティングしてきた話 • 感想
インターフェース仕様を決めた話 * やったこと • APIのINPUT / OUTPUTをまとめたインターフェース仕様書を書いた • 設計リーダー、開発リーダーにレビューしてもらった *
思ったこと • APIの話をするときは、基本このインターフェース仕様書がベースになる • これだけは常に最新の状態にしておかなければいけない • めっっっちゃ大事
実際のインターフェース仕様書 APIの名前 メソッド エンドポイント APIの詳しい説明 リクエストパ ラメータ レスポンスパ ラメータ
データベース設計をした話 * やったこと • テーブル設計をまとめたデータベース設計書を書いた • 設計リーダー、開発リーダーにレビューしてもらった * 思ったこと •
マイグレーションファイルを作るとき以外はあまり見なかった • ただし、プロジェクトの規模が大きく、リレーションが複雑である場合はちゃんとや らないとダメそう
実際のデータベース設計書 テーブル名 テーブルの 詳しい説明 カラム情報 1
フローチャートを描いた話 * やったこと • 機能が全体としてどう動くのかをまとめたフローチャートを描いた • 開発リーダーにレビューしてもらった * 思ったこと •
条件分岐こうなるんだー • なんとなく機能の全体像が見えた気がした
実際に描いたフローチャートと紛失したフローチャート ・クライアント 属性情報登録時 ・サーバ 紛失
シーケンス図を描いた話 * やったこと • フローチャートを参考にシーケンス図を描いた • 開発リーダーにレビューしてもらった • シーケンス図を描いてると、フローチャートに漏れがあったことに気づきフロー チャートを修正した
* 思ったこと • シーケンス図に条件分岐を含めてはいけない、わけがわからなくなる • 大きい部分から小さい部分という流れがわかりやすくて良い
条件分岐を書いてわけがわからなくなったシーケンス図 開発リーダーから悲鳴が聞こえた気がし たが、おそらく気のせいだろう…
サーバサイドを実装した話 * やったこと • 今まで書いた設計書を元にサーバサイドを実装した • 開発リーダーにレビューしてもらった * 思ったこと •
設計書を書いている段階で、ある程度「こんな風に実装しよう」というのが頭に思 い浮かんでいた • 実際書いてみると「やっぱこっちの方がいいなあ」ということもあった
クライアントサイドを実装した話 * やったこと • 今まで書いた設計書を元にクライアントサイドを実装した • 開発チームメンバーにレビューしてもらった * 思ったこと •
うわっなにこのAPI !? 誰が作った !? • またサーバサイドの実装に戻るのも面倒だし、まあ動くからいいか... • 誰も何も言わないでくれと祈る
この API ってなんで項目名と ID どっちも送 るんですか? どっちかでよくないですか? おっしゃる通りです。修正します。
当時の API 仕様 項目名とIDの両方を送るという意味不明な仕様になっていた...
協業先に直接赴いてミーティングしてきた話 • 協業先のAPIに仕様変更があったことを弊社が把握していなかった • 他にも変更があった部分があるかもしれないので、 確認の意味も込めて一度ミーティングすることに 結果、APIのバージョン変更があった場合は 共有のSlackチャンネルで通知してもらうことに
感想 • 使う側にならないと気づかないことがたくさんあった • サーバサイドを実装しているときは、いかにサーバサイドで楽にするかを考えて いたため、仕様やクライアントサイドの実装にツケが回った • 本来はあり得ない挙動でも、実装時には十分起こり得る挙動があるので(同じ ユーザから属性情報登録APIが複数回叩かれる)、サーバサイドはそれを想定 してエラーメッセージを詳細に出すべきだった