技術検証したり、資格等をここに残していきます。スキーマファーストを目指して手間取ったところのまとめ2019-12-30スキーマファーストを目指して手間取ったところのまとめ技術スキーマファーストがなぜアツいと思っているのか最近、自分のなかでアツいのはスキーマファーストの開発です。発端になった理由としては、前職も含めて会社ではswaggerを使用した自動生成を行っていましたが、個人での開発では使用していなかったので使用してみたかったから。自動生成のメリットだけを考えていたところ、Ginza.js#4でgRPC-WEBを触った話をLTでするために色々調べていたところ、スキーマファーストの考え方に出会いました。登壇時の資料その考えを知る前は、サーバサイドのControllerだけを自動生成するイメージでした。システムのIFを先に定義することで、自システムのサーバサイド、フロントエンドだけでなく、対向システムもすぐにテストに取り掛かれるというのは素晴らしいメリットだと思います。アジャイルジャパンでも、IFだけを先に定義しておいて、実装部分は各チームに任せたら素晴らしい功績を残せたという資料が展開されていました。アジャイルジャパンの30,31Pこじつけかもしれませんが、ソースの使い方を考えて開発をする。いう点を考えたら、インターフェースのTDDと言えるのではないでしょうか?実際にスキーマファーストを意識してopenAPIを使った開発をしたものの、こうしておけばよかった、という点を以下に記載していきます。gatewayを突破してから作りこむのが得策だった。EC2にデプロイするローカルのフロントとEC2のサーバを接続確認するopenAPIの$refを使って、yamlを細分化した。gatewayを採用が、yamlを細分化したために、直接AWSへアップロードできず。結局、yamlを結合するしてからAWSにアップロードする必要があった。学んだことスキーマファーストだろうが、ブランチ一本戦略だろうが、リリースして価値を届けられていることが前提で価値がある。固定値でもいいから、薄く結合してから作りこんだ方が手戻りも少なくて価値が大きい。gatewayの利用は考えていなかったが、遊びではなく仕事で行うのであればこの考え方は必須だと思いました「スキーマファーストを目指して手間取ったところのまとめ」をお読みいただきありがとうございます。役に立った、と思われましたら、ブックマーク・シェア・フォローをしていただければ嬉しいです。Spy)テーブル定義やER図は自動生成できると楽です。12:00問い合わせはこちらから。//List形式の画面で記事を入れる場所。上から2個目と7個目のsectionの後に入れる。//記事内で個別に指定されないときに使うAd挿入場所。//0から始まる値で、2を指定すると3番目のと直前に差し込む。insertAdsense();引用をストックしましたストック一覧を見る閉じる引用するにはまずログインしてくださいログイン閉じる引用をストックできませんでした。再度お試しください閉じる限定公開記事のため引用できません。