🤖

スタートアップの開発で意識したこと

3 min read

概要

2021年6月ぐらいから友達がやっている会社のお手伝いで、iOS・バックエンド開発を一からやっていました。
この記事では、開発周りで意識したことを忘れないようにまとめておこうと思います。
技術面以外で学んだことは note にまとめているので、もし良かったらこちらも見てください。

開発に関する状況

  • 平日の夜、土日に開発
  • 開発するのは自分だけ
    • 後からどういう技術スタックの人がジョインするかは未定
  • iOS とバックエンドを3ヶ月で終わらせる予定

技術スタックについて

今回使った技術は以下の通りになります。

iOS 開発で意識したこと

技術スタック

iOS 開発には Swift(SwiftUI) を選びました。開発人数が少ない状態で、将来的な Android 対応を考えたら ReactNative や Flutter も選択肢あるのですが、以下の理由で Swift(SwiftUI) に決めました。

  • 自分が ReactNative や Flutter が未経験なので時間がかかってしまう
    • 限られた開発時間の中で、学習 + 実装をできる自信がなかった
  • Android 対応を見据えて ReactNative や Flutter を採用しても、プロダクト観点で Android に避けるリソースがなさそう
    • iOS と Android で UI の思想が違うので、どちらもデザインする必要があるがリソース確保が難しい
    • それならロジックはバックエンドで持って、Android 対応するときは UI 周りだけに注力すればいい環境にしておこうと判断

Storyboard ではなく SwiftUI にした理由は、開発の修正・確認のサイクルが圧倒的に早くて、コードのコンフリクトも簡単に解消できるからです。
学習コストも低くて、Storyboard しか触ったことがない人でもすぐにキャッチアップできると思っています。
iOS13 と iOS14 で挙動が異なり大変な部分がありますが、今回作ったアプリでは対応バージョンを iOS14 以降にしているので今のところ困ってはいないです。

設計

ロジックと UI を分離する設計には、MVVM を採用しました。 SwiftUI と相性が良く、参考になる記事もたくさんあるのでキャッチアップコストもかからないと思っています。
API とのインタフェースには openapi-generator を自動生成しています。
openapi-generator は Swagger ファイルから様々な言語の API クライアントを自動生成するものです。
Swift は静的型付け言語なので、API とのやり取りも型がある状態で開発した方が不具合を少なくできるので採用しました。
また、採用の面でいうとアプリもバックエンドも触れる人がジョインするとは限らないので、スキーマ駆動でインタフェースを決めたらバックエンドを待たずにアプリの開発ができるようになります。

バックエンド開発で意識したこと

インフラ関連もこのセクションで紹介します。

技術スタック

以前だとスタートアップの場合 Ruby や PHP などの動的型付け言語で書かれるイメージがありますが、今は静的型付け言語で書かれる事例も増えていると感じています。
うちも例に漏れず、 バックエンドには Golang(echo) を採用しました。Golang を採用した大きな理由は、一番自分がスピードを持って開発できる + 採用を考えた時に母数が多い(イメージ) + キャッチアップコストが低いからです。
自分の技術スタック的には Laravel もこれらに当てはまったのですが、型がありコンパイルする言語だと、最低限の自信を持ってリファクタリングができるので Golang に決めました。
Golang の Web フレームワークは echo を使いましたが、一番使い慣れているのが主な採用理由です。
また、公式ドキュメントだけではなく日本語の記事も多く参考にできる事が多いというのもあります。

他に使っているツールを紹介します。

  • go-task
    • go-task は make コマンドをシンプルにしたようなツールです。yaml ファイルを設定を書くことで、よく使うコマンドを簡単に実行できて開発効率が上がります。(下のコードを参照)
  • air
    • ホットリロードのためのライブラリです。toml ファイルを書くことで、ファイルを修正したときに自動で build&run をしてくれます。
version: '3'
docs:
    cmds:
      - swag init -g cmd/main.go -o api/

build:
  deps: [docs]
  cmds:
    - go build  -o build/main cmd/main.go

run:
  deps: [docs, build]
  cmds:
    - ./build/main
$ task run

インフラは AWS の ECS Fargate を使っていて、IaC で Terraform を使って構築しました。
インフラ周りはあまり得意ではないので、自分ができる範囲 + 再現性があるようにしたいと思い Terraform を使いました。
IAM や S3 などの一部のリソースが IaaC で書く前に作ったので管理されていないので、ゆくゆくは整理したいと思っています。

設計

初期の段階では重いかなと思いましたが、 Clean Architecture + DDD を採用しました。
シンプルに MVC でも良いかなと考えたのですが、設計が開発スピードを決める一つの要因になると思っているので、最初は冗長に思えても将来性を考えて上記の設計にしました。
ただそうは言っても初期はスピード感も大事なので、キャッチアップできるようにドキュメントを残そうと思っています。

バックエンドの設計には、以下の二つを参考にしました。大変分かりやすく、実際にすぐに使えたので助かりました。

ディレクトリ構成は ここ を参考にしています。
公式ではないみたいですが、多くのプロジェクトで使われているディレクトリレイアウトのなので、そのまま使っています。

これから

開発スピードを意識したために、早めに入れておいた方が良いけど重要度が高くないものを後回しにしてしまいました。
特に CI や Monitoring は、開発効率・ユーザーさんに安定してサービスを提供する上で非常に重要なのでコードが大きくなる前に入れていきたいです。

Discussion

ログインするとコメントできます