※本文は個人の見解であり、所属する組織の公式見解ではありません。
対象
- サービスを立ち上げ時で本当に猫の手も借りたいぐらいクソ忙しい状態の中でエンジニアリングしている人
- もはや業務範囲がエンジニアリング以外のものも担当しながら開発をしている人
- test(unit test,E2Eテスト)が重要な事は知ってるが、本当に時間がなくやむなく置き去りにしている人
- 期間限定のサービスではなく、ヒットすれば長期間運用するサービス開発をする場合
過去を振り返ると
いろいろとご意見はあると思うが、主に下記の２パターンが多かったのではないかと思っている
過去のパターン1（スピード重視）
はじめはとにかく、テストはあまり考えずにサービスの立ち上げに集中して、ある程度シェアを獲得した段階で一度立ち止まり、リファクタ/リプレイス/テストを書いていくパターン
-
メリット
- とにかく機能のリリースを優先して、先行者メリットで市場のシェアを獲得できる
- ビジネスとしてある程度成り立たせることが優先でき、その後のロードマップがひきやすい
-
デメリット
- 技術的負債はたまり続ける。時には技術的負債で新規機能開発の妨げになる場合もある
- 途中でjoinしたエンジニアは初め苦しむ。。。
過去のパターン2（品質[意図した動作を保証するという意味の品質]重視）
テスト駆動開発的にやはりテストはありきで開発を進めるパターン
-
メリット
- バグの件数や技術的な負債は少なくて済ませられる
- 安定的に新規機能開発が進み、スケールしやすい
-
デメリット
- 立ち上げスピードがどうしても遅くなるので先行者メリットが薄れる
- ビジネス判断としてサービス終了となる可能性が少々高くなる
過去を踏まえつつ、最近っぽく、良い感じ（スイードも重視しつつ、品質も...）にするには
オススメパターン
はじめにエラーログを収集・集計する仕組みだけを導入し、testコードは一度忘れ、サービス立ち上げの開発に集中する
エラーが発生しているパターンが集計され、集計値の多いものから随時バグフィックスしていくことで改善効果が高くなり、品質と新規機能開発がうまく回り始める。
具体的にはこんな感じ
- APサーバにFluentのエージェントをインストールして、フレームワークのログ、Nginxのログ、アプリサーバのログをtailして集約サーバへ送る
- Fluentの集約サーバはそのまま、Elasticsearchに投げてインデックスさせる
- Kibanaからエラーログをいい感じに集計して、グラフ等で見える化する
- DBサーバのスロークエリとかもFluentエージェントでtailしても良い
- fluentやelasticsearch,kibanaというプロダクトが無料で出てきて、且つ低コスト（手間のコスト）で導入することが可能になった今だから出来ることであり 開発者の皆さんには感謝感謝です。
他にも細かい部分を言うと
- 静的型付言語を選択することで無駄なシンタックスエラーが回避できたり
- IDEを大いに活用してケアレスミスを事前に防げたり
まぁでも一番大切な事
サービスの市場におけるなんとなくの立ち位置を客観的に把握する事
リリース優先をしてスタートダッシュしてある程度成功をおさめた後、少し立ち止まりリファクタorリプレイスを繰り返し再度スタートダッシュをする事で成功するすパターンもあれば、逆に少し立ち止まってる間に他者に追い越される場合もある。
また立ち上げスピードが遅く、そもそもビジネスとして成り立たなかったパターンもある。
いずれにしてもビジネスとして成り立たないと全ては無くなるので客観的な立ち位置を常に考えてその時に必要な手立てを行う。
完璧を求めない
test code やE2Eテストを書き始めるとカバレッジを取得しながらやると思います。
数値で定量化されるのでどうしても100％を求めがちなるが、100%でないゴールを設定して保つ目標にすべし。
WEBアプリケーションであれば、サービスの内容にもよるが80%程度が丁度良いと思っている。