ランサーズでは、現在、Webエンジニアを募集しています。
詳しくは、募集要項をご覧下さい。
こんにちは。開発ブログ言いだしっぺの satoshi です。リートでは、AddClips と Lancers というサービスが現在の主力サービスですが、AddClips は1人のエンジニアが担当し、Lancers は2-3人 のエンジニアが開発を担当しています。
当たり前ですが、1人と3人では開発スタイルが大きく異なり、気をつけるポイントも全く違います。当たり前の事が多いのですが、リートで特に気をつけていることをご紹介できればと思います。
開発環境
VMware ESXi を使って開発環境は5秒で用意する
通常、VMwareはLinuxやWindows上で動作しますが、VMware ESXi はその上で直接、複数のVmware（仮想化マシン）を立ち上げることができます。
Vmwareを導入するために、Linuxを導入したりする必要はなく、その容量も32MBとコンパクト。しかも無償で利用可能です。
VMware ESXi 導入をしたら、まず最初だけ本番と同様の作業環境を構築します。そうすると、あとはそのコピーをするだけで、Aさん用・Bさん用・Cさん用と簡単に独立した開発環境を作成することが出来ます。新人が入っても、5秒で開発環境を提供できます（笑）
急にロードバランサのテストをしたくなったり、MySQLのレプリケーション環境を作りたくなっても、基本的にコピーするだけなので、サーバースペックが許す限り多数のOSを作られるのが、VMware ESXi の特徴です。
バグ管理redmineとバージョン管理subversionの導入
バージョン管理は複数人開発の基本中の基本です。subversionやgitを使わない開発なんてあり得ません！また、できればredmineやtracといったバグ管理ツールも利用したいところです。
仕様作成や設計まとめ、マニュアル管理には(wiki)を使います。wikiなので複数人の編集や履歴管理にもばっちりです。 タスク管理やTODO管理には(tichet)。コードレビュー、ちょっとしたコード確認には(リポジトリブラウザ)と、バグ管理システムはバグだけではなく、開発全体をNOストレスで進めるための必須アイテムです。
ここまでやる必要はありませんが、弊社では redmine 専用モニタを用意して、モニタアームで人の目線に常時チケットを表示しています。
ルール
コーディング規約は皆で決める
開発環境が整ってくると、すぐにコードを書きたくなりますが、ちょっと待って下さい！1人の開発では、コーディング規約＝オレオレ規約でOKですが、複数人となると、命名規則やコメントルール、インデントのスペースの個数などの基本的なコーディング規約を最初に決めるのは大切です。
ただし、リートで注意しているのは、特定の1名が決めた規約を強要せずに、皆で話し合って規約を決めています。これによって、オレオレ規約の押しつけが無くなりますし、皆で決めたことなので、遵守されやすくなります。ただ、たたき台はあった方が良いので、PHPであれば、Zendコーディング規約 などが参考になります。
1分の朝会で情報共有
毎朝1分の朝会をしていますが、そこでは昨日の実装したコード、今日実装する予定のコード。今はまっているポイントなどを1分程度を発表して情報共有しています。
これを強制的にすることで、各エンジニアの作業状況を全員が共有し、お互いの影響範囲を把握できます。発表の場があることで、翌日の朝会を小さな目標にして、毎日小さな達成感を得られるメリットも。
隣の席でも会話はSkypeやIRC
コードを書いている集中できた状態になると、話しかけられて作業がストップすると、再度、集中できていた状態に戻るのに10分・20分と大きな時間のロスが発生します。
エンジニアそれぞれの集中している時間も違うので、極力、緊急時以外は、エンジニア同士はSkypeやIRCなどで会話するようにしています。ただ、絶対に話しかけたら駄目というのもNG。基本はSkype、適時直接といった感じでバランスが大切です。
コーディング
チケットファースト：依頼はチケット
開発をしていると「ここのテストを通してくれない？」「この関数を初期はtrueで返すようにしてほしい」など大小様々な作業依頼が発生します。言った方は覚えていても、言われた方は忘れてしまったということを防止するためにも、作業依頼は必ずredmineのチケットにして登録しています。チケットの無い仕事はやらないくらいに徹底すると効果的です。
テストファースト：テストから作成する
複数人で開発するからこそ、テストは超大事。テストを作って、そのテストが通るようなコードを作っていくことで、開発の効率化と、テストがないコードを減らします。テストがあることで、レビュアーもコードレビューがしやすいという効果もあります。
コミットhookを活用する
redmineやsubversionには「pre-commit-hook」や「post-commit-hook」といった、コミットをトリガーとして様々な処理が出来る機能があります。
pre-commit-hookを使うと、コミット時のコメントに、関連するチケットを記入しないとコミットできなくなります。「svn commit -m ‘refs #3231’」といったように、関連するチケットを書くとコミットでき、後で見たときに、何のためにコミットしたのかが分かりやすくなります。チケットを強制的に使わないとコミットできないので、どのコミットも何目的のコミットか確実に分かり、無意味なコミットを防止する効果もあります。
post-commit-hookを使うと、コミットと同時にチケットを閉じたりすることができます。「svn commit -m ‘fixes #3239’」などと書くと、該当チケットが閉じて、レビュー待ちステータスになります。これは自由に挙動を設定でき、わざわざブラウザを開いてチケットを閉じてという面倒な作業から解放されます。
redmineのコードレビュープラグインを活用する
redmineにはコードレビュープラグインというものがあり、ブラウザ上でコードのレビューをすることが出来、レビュー時の指摘を自動でチケットにしてくれるという優れものです。バグ管理にredmineを使っている場合は、使わない手はありません！ブラウザがあればレビューができるので、超おすすめです。
開発後
マニュアル化・マニュアル化
ベンチャーで少人数で開発というと、ドキュメントなんて！と思われがちですが、マニュアル化するのもとても大切です。一旦開発が終わったら、マニュアル化に数時間使っています。その数時間が半年後に大きく役立ちます（笑）
「コミット前の注意点」「リリース時の作業手順」といったノウハウ系から、「データベース構成」「各モデルの役割」などなど2度以上使いそうなものは、出来る限りマニュアル（DOC)にしています。
当たり前のことが多くを占め、一人での開発には仰々しく、5名や10名以上といった大規模な開発では適用できる部分も少ないと思いますが、何かお役に立てることがあれば嬉しく思います。リートでも日々、開発についてはツールや方法などトライアンドエラーを繰り返しています。今後も新しい方法などがあれば、随時開発ブログでご紹介していきます！