スタートアップで働いて得られた開発tips

スタートアップに入り、日々目まぐるしく環境が変化していく中でやってしまった失敗。
どんな失敗に遭遇し、`どう対応したか`を簡単にまとめてみました！

ぜひ、参考になれば幸いです！
(もし、需要がありそうな項目があれば深掘りして再投稿してみます)

# 【フロント・サーバーサイド】

## ページのレスポンス速度向上

当初とにかく指摘されたのはサイトのレスポンス速度でした。
そこで、レスポンス速度向上に取り組み、
結果的にPCのトップページの評価が`40点台`→`MAX96点`にまで向上させることができました。
ちなみにモバイルは70点付近です(笑)
測定ツールは[PageSpeed Insights](https://developers.google.com/speed/pagespeed/insights/?hl=JA)(ページの読み込み時間の測定・改善策の提案をしてくれるサイト)です。

【PCでは96点】
<img width="1421" alt="スクリーンショット 2019-07-28 21.22.07.png" src="https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/410824/264c1141-3699-e81b-f5ed-981dbae1b4a4.png">

行った対策は以下です。

- [N+1対策](https://qiita.com/free_man/items/857d8af72a0711908f20)
- [キャッシュの導入(一旦memocacheで対応)](http://yamakichi.hatenablog.com/entry/2017/03/09/000951)
- 画像の最適化
  - [pcとspの画像使い分け(jpmobile)](https://github.com/jpmobile/jpmobile)
  - [画像の圧縮](https://compressjpeg.com/ja/)
- [JavaScriptとCSSにasync / defer](https://qiita.com/phanect/items/82c85ea4b8f9c373d684)
- クエリの修正(テーブルやカラムの追加)
  - ページを開いた際に大量のデータを計算するなどの処理はレスポンスを遅くします！！



#【インフラ系】

## ElasticBeanstalkのインスタンスタイプはElasticBeanstalkから変更する

ElasticBeanstalkで環境を作成している場合、**EC2**からインスタンスタイプの変更しないようにしましょう。
依存関係などを崩してしまうため、うまく行きません。(僕はこれでサーバーを半日落しました(泣))
僕はこの時、環境の再構築をすることでサーバーの復活を果たすことができました。

**Elastic Beanstalk** > **ダッシュボード** > **アクション** > **環境の再構築**

## エラーページは設定しておく

こちらはサーバーを落としてしまった際、またはメンテナンスの際に`503画面`が表示されてしまうとユーザーの不信感につながりかねません。404や500はrails側で設定できますが503はサーバーが落ちてしまっているのでインフラの方で設定して置かなければなりません。

[CloudFrontのCustom Error Responseを利用して、S3上にあるSorryページを表示する](https://dev.classmethod.jp/cloud/aws/cloudfront_customerrorresponse_s3/)

## スロークエリの設定

クエリの重さは、目に見えているページだけでなくサーバーにも大きな負担をかけてしまいます。
その結果、バックグラウンドでも影響が出てしまうことがあります。(メールが大量に届くor届かなくなる、またはjobなど)常にチェックできるように設定しておきましょう！

[Amazon RDS for MySQLでスロークエリーログを出力させる手順](http://blog.serverworks.co.jp/tech/2016/05/09/rds-for-mysql-slow-query-log/)
## ヘルスが変化した際の通知

様々な要因がありますが、ヘルスが`Severe`になって気づいたら数時間サーバーが止まってしまっていた。なんてことにならないようにヘルス変化は常に通知しておきましょう。Elastic Beanstalkで環境を構築している際は

**Elastic Beanstalk** > **設定** >　**通知** > **通知したい先のアドレス設定** > **適用**

で設定できます！ 

#【その他】

## ドキュメント管理で効率的に時間を活用する

僕の独自の共有に時間がかかるランキングは

**1位 開発フローの把握**
**2位 システムの環境構築**
**3位 ユーザーからのお問い合わせ対応**

特に上位2つは出入りの激しい(笑)スタートアップの開発リソースを減らしてしまう深刻な問題だと思います。
一番対応の簡単な方法としてドキュメント管理に力を入れています。
`もし、こんな質問がきたらこのマニュアルを渡す`のようなパターンができていればいいドキュメント管理ができているなと思うようになりました。
(ドキュメントはGithubのwikiにまとめています)


## Githubのタグを使い、新加入のエンジニアのキャッチアップ迅速に

`ドキュメント管理`関連でもう一つ。
途中から参加したエンジニアさんは`システムの把握`に時間がかかると思います。
システムの把握に時間をかけすぎてしまうのはもったいないのですが、かけなさすぎると思いがけないバグを生んでしまいます。これがデータ保存系・更新系だと対応が大変です。。

そこで僕がよく使うのはGithubの`アサイン`と`タグ付け`です。
心がけていることは

```
①自分が担当するissue・pullrequestには必ずself assignする
②ある程度シリーズ化したorしそうなissue・pullrequestにはタグづけをする
```

この2つを徹底すると以下のことがおきます。
→タグ一つ検索するだけで誰がどのタスクを担当し。どんなコードを書いたかがわかる
→上記がわかるとトラブルやバグ仕様の把握をしたいときに`誰とコミュニケーションをとればいいかがすぐわかる`

この流れが出来上がると、間に常勤のエンジニアが入ってコミュニケーションの橋渡しをせずに済み、`コミュニケーションコストが大幅に下がります！`

【イメージ】
[rails](https://github.com/rails/rails/pulls?page=5&q=is%3Apr+is%3Aclosed)本家のコードを使わせていただきました。本当はこんな開発者おりません。
<img width="1127" alt="スクリーンショット 2019-07-28 22.50.33.png" src="https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/410824/db2d4273-f5d5-b7d1-cb6d-8022e2f6afcf.png">

【タグでソート】
<img width="1149" alt="スクリーンショット 2019-07-28 22.55.11.png" src="https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/410824/640536e2-e33c-0b9b-6a5a-7b4d4d1277a0.png">

【アサイン者でソート】
<img width="1144" alt="スクリーンショット 2019-07-28 22.57.07.png" src="https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/410824/098264b1-5d44-074e-7d1a-5de8cfd8e5f5.png">