プロトタイプ実装して感じたこと

はじめに

全体、技術置いといて振り返ります。(結果、技術の話も含みますw)

11月に大阪で開催されたオフ会で学習アプリの構想のお話をしていただいて、その1週間後くらいに打ち合わせになりました。

今回はフロントエンドだけとかではなく、設計等すべてやってもらうとのことで、実務課題や実務(フロントエンドのみ)では、DB設計は出来てる状態だったので、個人開発以外はあるもの使うだけで、私にできるのかと不安を感じつつ、まぁレビューしてもらうからヤバいもの作ってしまうということはないかと思いつつ取り組みました。

軽視してるわけじゃないですよ！！頑張ろう、挑戦しようと思う安心材料なだけです。なくても飛びつきますw

多分新卒で入ったのが銀行という堅いOF堅い業界だったので、保守的というかリスク管理をすごく考えるように習慣ついていて大丈夫かなコワイ。。。ってすごく考えてしまうんです。

このあたり安心して取り組めるのはShiftBのいいところというか、ぶべさんの優しいとろこというか・・

でも正直考えます、未経験エンジニア転職活動した経験もなくぬくぬく楽しくコーディングしてるだけで、こんなページ作ってと案件も振っていただけたり贔屓されてるって思われてないかなと・・・

思うんですが、仕方ないですよね、、、

オリアプ完成させた人がそもそも少ない、一期生でまだ私とこうすけさんだけですよね？

そりゃこうなるでしょうよって自分で納得しました。

まぁそれだけShiftBのカリキュラムが難しい、オリアプ作るの難しいってことですよね・・・私、自信持って言える程がんばってますからw

でも今回の学習アプリはオリアプ完成させるまで行かないと実務課題としての参加権ないので、早く誰か！ !完成させて！ってかんじです。

誰かと一緒に開発したい。実際一人でも私はコーディング出来たら楽しいんですけどw

みんな遅いと1人で作っちゃうぞ！！(ボコられながら)

すみません、挑発しました。

感じたこと

プロトタイプむずかしい

どこまで作るかの塩梅の話です。

問題一覧画面、問題詳細画面だけ動作するように作れていればプロトタイプはOKという認識で作っていて(意識すり合わせた上でです)、最初のプルリクで「プロトタイプではこれでOKですが、実際は～～こうなりそうです」といったコメント大量w

OKと言われてはいるけど、なんかホントにいいのか・・？って思いません？w

で、結局やり直しました。

実際サイトマップもAPIリストもない状態で最初作っていたので、ルーティングの変更は結構しました。

そういう構成だったのか～ということ多かったです。

手戻り的になる部分もありましたし、もちろんこれから発生する変更があると思いますが、DB設計は現状想定している最終形態ですでに出来てますw

どこまでやっとくが難しいと思いましたが、完成した後のぶべさんの微修正(?)で遷移先やパンくずは変更多かったので、なんとなくイメージつかめた気がします。

プチ困惑

スキーマの

updatedAt       DateTime        @updatedAt @map("updated_at")

この部分、supabaseで直接データ入力するときにデフォルトで入らないんですよね。

API経由なら入ります。。なんでと思ってわざわざエンドポイント作りましたw

その関係でcouerseIdやlessonIdの値が1スタートにならなくて(保存ボタン押したらエラーでもIDの採番されてて・・💦）couerse一覧ページ、lesson一覧ページも作成しちゃいました。

でもあとからそのページへの導線全部消えてたのでなるほどってなりましたw

別にプロトタイプで使わなくてもそのページのバックエンド、フロントエンド処理や型定義等済んでるので今後楽になると思っています。

レビュー

処理は成立してるけど、これじゃダメなことが多い！！という感じでした。

あと、今まではこの構成で(型定義の場所とか)良かったけど、今回はこうしようみたいなこともあり、臨機応変にというかプロジェクトによるというのはこういうことかと感じました。

このあたりはもう判断していただくでいいのかなと、あまり自分の書いていたやり方が間違ってたとは解釈しなかったです。

今回はやり方が違うんだとそう考えました(はい、ポジティブです。)。

共通の型定義

型はなるべく同じものを使いまわした方が型エラー出にくい、無駄に型アサーションやas constを使う必要がなくなると思って、共通のオブジェクトの型を作って、レスポンスに応じて追加があればベースの型を拡張した方が良いと思っていたのですが、それも覆りました。

型のアサーションや as const仕方ない場合もありますが、型を明示的に指定して済むならバグ産みそうで極力使いたくなくて、拡張して使うが正義だと思っていたんです。

でもエンドポイントごとにレスポンスが細かく変わることが予測されるので、特定のエンドポイントで特定の値を間引くとかなった場合、Omitなど組み合わせて複雑な記述になっていきそうということで、型の定義が複雑になっていくことを避けるために使いまわさずいこうと指摘いただきました。

自分の認識が間違っているわけではないと思いますが、メリットもデメリットもあり、場合によって柔軟に判断する必要があるということが大きな学びでした。

プロジェクトの要件に応じた最適な設計判断の重要性を理解することができました。

重要性がわかっただけです。判断できるとは言ってません。

実際のコード

レビュー前、こうしていました。

import { Question as BaseQuestion } from "@/app/api/_types/Question";
import { StatusType } from "@prisma/client";
type Question = BaseQuestion & { status: StatusType };

色んなところで使っていた型Question

import { StatusType } from "@prisma/client";
export type Question = {
   id: number;
   title: string;
   content: string;
};

レビュー後、こう変えました

import { StatusType } from "@prisma/client";
export type Question = {
  id: number;
  title: string;
  content: string;
  status: StatusType;
};
export type QuestionsResponse = { questions: Question[] };

この修正はstatusの情報をレスポンスに追加することになって生じた変更で発生しました。

待って、「技術置いといて」って最初に言ったのにめちゃくちゃ技術の話してるw

多めに見てくださいw

結論

設計むずかしい！一人じゃ使えるものできない！！

たたき台なら作れますが、普通に漏れがあってまだまだ知識不足です。

一方で、バックエンドも何取得したらいいかなとかその辺は(セキュリティが絡むと弱いとも感じた)割とすぐに判断できるように思いました。

バックエンドはエラーほとんど出さずに作れました。(レビューでは色々ありましたがw)

思わぬ400エラーとかはなかったです。成長。

まず型考えるということも習慣化してきたように思います。

頂いた実務案件のような、エンドポイントはすでに出来てて、リクエストボディはこの型で、レスポンスはこの型で～とか全部決まってるのは本当に優しい世界だなと感じますw

おわりに

とにかく楽しかったです。本実装ではどこをやらせていただけるのかまだわからないですが楽しみです。

わからん！って感じながらも試行錯誤するという経験が、自分を成長させてくれるってわかっているので、前向きにレビューでいただいたコメント振り返ってアウトプットを積極的にしたいと思います。

苦しむの大事！！w頑張ります！