学生時代まで一人でしかコードを書いてこなかったひよっこエンジニアが、「企業で、チームで作るってこんな別種の大変さがあるのか！」とビクンビクンした話です。僕がある企業のAPIエンジニアとして1年間学び、そこで得たことを書こうと思います。
目次
- チームで作るということ
- 障害との向き合い方
- 新しい技術の導入に必要なこと
チームで作るということ
優先度と見積もり
「俺が作りたいもの作るぜ！！俺様の気の向くままに気が向いたときに作るんだURYYYYY！！」みたいなノリは当然ダメです。つらいですね。
（社内の立ち位置によっては許されるかもですが）
- やるべきタスクは何か？
- 優先度は？
- それぞれの見積もりは？リリースはいつか？
- タスクの依存関係は？
- 今は進捗遅れてるの？遅れてるとしたらどうするの？
僕らの労働時間はリソースなので、これらをチーム内にもチーム外にも説明できるようにしておかないといけません。
コードの共有
pull-reqでチーム内に修正内容を共有するのが基本かと思います。
- レビュー
- 「これは何のためのpull-reqか
」「どこをレビューしてほしいか」「なんでここでこんな面倒くさいことをやっているか」を説明する - 「空気を読ませない」のが良いpull-reqらしいですよ奥さん
- 「これは何のためのpull-reqか
- 機能ごとにpull-reqを分けて、レビューしやすいように、他人が振り返りやすいようにする
spec
実装と仕様は別のものなので、後に残せるようにしておく。
未知のコードの理解には、specによるトップダウンの理解をした後に、コードによるボトムアップの両側面から攻めるのが早いなーと思っています。
障害との向き合い方
サービスによっては、ちょっとアクセスができなくなっただけで自分の年収くらいの金額が軽く吹き飛んだりします。
デプロイ時にいかに障害を減らすか、起きてしまった障害にどう対処するか。
障害を起こさない
検証とリスクの分散化。以下は一例です
- pull-req運用、チーム内でレビュー
- 開発中はunit test green前提
- jenkinsでpull-req時点で担保したり
- 本番に模したサーバーでテストを流す
- 開発者とテストエンジニアを分ける
- "仕様"と"実装"を明確に分ける効果
- テスト用言語を別にする
- テストと実装で共通で使っているライブラリのバグを踏んで「たまたま通ってましたテヘペロ」状態を避ける
- 2つ以上のコンポーネントをデプロイする必要がある場合は、後方互換やデプロイ順に気をつける
- 物によっては一部のサーバーにだけデプロイして様子見する
- クライアントの場合は、ちゃんと実機検証しようね！！
- 実機でしかわからない罠がたくさんあります
障害を検知する
- 必要なログを出しておく
- nagiosなどによるログ監視、自動アラートシステム
- トレンド監視などなど
- 各種サーバー状態のグラフ化
障害に対処する
- 前提として、すぐに切り戻せるようにしておく
- ログやサーバー状態から起きていることを分析する
- 推測で動かない
- 速やかに暫定対応し、恒久対応は別途考える
新しい技術の導入に必要なこと
これも、一人でノリで作ってた頃とは全く異なります。
以下のことをきちんと説明できないといけません。
- 移行コストとリスクをとってまでその技術を導入するメリットは何なの？
- 本当に大丈夫なの？
- 枯れてるの？
- なんか起きたときお前何とかできるの？ソースは読んだの？
- パフォーマンスは計測したの？
また、現実的にチーム内にその技術を粘り強く説明して布教する必要が出てきます。
例えば、社内全員svnに慣れきっている状況で、本当にgitを広められるかを想像してみてください。僕はちょっと目眩がします。
おまけ
企業の中にいると、何かしら面倒なこと、億劫なことが出てくると思います。
テストが遅い、デプロイが面倒、調整が面倒、などなど……
先輩に言われて印象に残っている言葉に「目の前の問題にソリューションが提供できずに何がエンジニアか」があります。
何かを一歩一歩変えていきたいですね。
終わりに
状況によっては、上記のお固いところが不要なところもあるでしょうし、あるいはもっとお固くならなければならないと思います。
あくまで一例として参考にいただけたらと思います。
プライベートでコードを書くのは楽しいですけど、それとは別種の難しさと楽しさがここにはあるなーと思います。