この記事は、yuriacatsアドベントカレンダー5日目の記事です。
最近、個人開発でAPIを作るような機会があったのですが、その時に気づいたこと・意識してみたら学びが多かったこと、失敗したなと思ったことを書き留めておこうと思います。
気づいたこと
- コンテナ化して自動デプロイするより、Lambdaのほうが個人的には楽だなと感じた。
- 自動デプロイを組むのがとてつもなく大変（AWSを利用する場合）
- 特にAIMを振るのが大変…（Lambdaでも大変だが関わるサービスが多い分ECSの方が大変に感じた）
- とにかくデプロイ先の知識がかなりいるのでそれを先に勉強した方が個人開発は楽。
- 他の人からのアドバイスは貴重なのでtechtrainなりTwitterの人なりにアドバイスを定期的にもらうと個人開発のペースメーカーになり良い。
意識してよかったこと
-
ライブラリーの選定の意思決定をギリギリまで粘ったこと
- 当時読んでいた本に「意思決定をギリギリまで遅らせろ」という話が書かれており、試しに実践してみるかという気持ちになった。
- 意思決定を遅らせることでとりあえず動くものを実装するぞということがしやすくなったと思う。
-
APIのモックを作ってフロントに一旦ベタ置きしておく。
- フロントの開発に一旦集中してからバックエンドのAPIを考え…を繰り返すとバックエンドの休憩がフロントエンドで、気づきを生かしてみたいなサイクルを回せ煮詰まってつらいと投げ出すことが少なくなった。
- また、APIのエンドポイント（仮）を作っておくことで、フロント側の視点からエンドポイントの設計のあらを考えることができる。
失敗したなと思ったこと
-
設計は初めにある程度固めておくべきだった。
- 設計の経験がないことも悪さしているように思えるが、APIの元データを作る時にどのような構造で取るかということで結構手が止まってしまいプロジェクトが進まないといったことが私は多くある。というか、プロジェクト止まる時のポイント１位はそれだと思う。
-
予定管理はするべき
- 実装予定がないと触っていても本質的でないところに力を入れて現実逃避をしがちである。
- それはそれとして最初は勢いで書いた方がいいこともある。
- 勢いの間に実装計画を立てて各工程＋８hくらい加えながら予定表を作っていくとよさそう
- それはそれとして
アドベントカレンダーの記事や仕事やで予定が潰れる要因は多いので、その辺も考慮に入れつつ周りの人に「〇〇日『まで』にリリースしたいのでXX日にコードレビューお願いします！！！」くらいのアドバイス予約をしておくと良いと思う。
今回の失敗談から考える必要な準備
- デプロイ方法候補のやり方を一通り予習→仮実装（HelloWorld）
- デプロイ予定日を決めアドバイスしていただく人にアポを取っておく
- 思い立ったらすぐ実装→設計予定を立てる。
あらかじめ、個人開発が思い立った時のために勉強しておくと良いこと
- AWSなどデプロイ方法についての知識
- 設計（DBやクラス設計レベルの設計の知識はあった方が良い）