月別アーカイブ: 2017年12月

VR転職して開発の仕方が変わったこと(脱オレオレ開発)

これはOculus Rift Advent Calendar 2017の15日目の記事です。
技術ネタを書こうと思ったけど、今回は以前から自分の開発スタイルがどう変わったかにお話しようと思います。「全然VR関係ねえ!」という感じですが、業務でVRアプリの開発をやっている時の話で、内容的には多人数で開発する場合のノウハウになります。

今年VR転職を果たしました

2017年4月、はるかうどんの国から東京にやってきました。某企業に転職しました。前職から打って変わってエンジニアをやっているわけですが、社内のメンバーと開発をやっていくうち、どれほど自分の開発スタイルが酷かったかを省みる機会を得て、開発スタイルを矯正することになりました。今はなんとか社内のメンバーに追いついて行っているかなぁ・・・。今回は以前のオレオレ開発スタイルからどう変わったかについてお話したいと思います。内容は以下の通り。

  • コーディングスタイルの統一は大事
  • リリースのルールとバージョン管理をしっかりする
  • おわりに

コーディングスタイルの統一は大事

一人で開発していると速度優先で書いちゃうのでコーディング規約を見落としがちで、リリース後でもリファクタリングを入れるのですが、業務でコードを書く場合は、一度リリースしたコードは書き直せる機会はめったにありません。リリース前に必ず他の人によるコードレビューがあり、リファクタリングのためだけにレビューしてもらうのは勿体無いからです。

初っ端自分は、コードレビューの観点を無視して『なんとか読めるレベルのコード』を書いちゃったせいで、レビュアーを困惑させてしまったという経緯があります。コーディングスタイルはどれも一長一短があるのですが、まずは決められたスタイルに統一することが大切だ、ということを学びました。例えば、変数の宣言の仕方ですが、以前だとこういうふうに書いていたり、

class Test {
  private static readonly int myValue = 20;
  private int value1 = 10;
  private int value2 = 30;
  public int Sum() {
    return value1 + value2;
  }
  public int Sum2(int value) {
    return myValue + value;
  }
}

はたまたこういうふうにも書いていた時期がありました。

class Test {
  private static readonly int _myValue = 20;
  private int _value1 = 10;
  private int _value2 = 30;
  public int Sum() {
    return _value1 + _value2;
  }
  public int Sum2(int value) {
    return _myValue + value;
  }
}

今はこういうふうに書いています。

class Test {
  private static readonly int c_MyValue = 20;
  private int m_Value1 = 10;
  private int m_Value2 = 30;
  public int Sum() {
    return m_Value1 + m_Value2;
  }
  public int Sum2(int value) {
    return c_MyValue + value;
  }
}

「べつにどーだっていいじゃん」と言われたらそこでおしまいですが、ここには「自分が担当しなくなった場合でもメンテンナンスしていけるように」という意思が根底にあります。なので、「後のためにコーディングスタイルは統一しよう」という共通のルールがあるわけです。コーディングスタイルはあいさつみたいなものですが、あいさつはしっかりしよう、という心持ちでコーディングスタイルを(なるべく)守るようになりました。

リリースのルールとバージョン管理をしっかりする

リリースのルールに関しては会社によって違うとは思うのですが、大雑把に分類すると以下のような流れになります。短期スケジュールでの機能の追加、BugFixのリリースルールの話です。(大枠の話とは別)

  1. リリースまでの期間を設定する(コーディング、プルリクのレビュー期間を含む)
  2. コーディング
  3. テスト(必要ならアプリ配布やテスト環境のデプロイもする)
  4. Gitホスティングサービスにコードを置く
  5. コードレビューを受ける、マージする
  6. リリース

この中で時間を割く必要があるのが、3になります。できればテストは自分以外の人にも触ってもらうのがベストです。自分がすべてやると漏れが出やすいので、テスト期間は長めに取るのがベストです。

おわりに

今回は内容的にOculusやVRに関連しているか、かなり苦しい感じの内容になってしまいましたが、VR開発に名乗りを上げた大手企業も増えており、将来的には個人プロジェクトから会社のプロジェクトになり、分業化が進んでいくのではないでしょうか。そのタイミングでオレオレ開発から以下に脱却できるかが重要になりそうです。特にVRにおけるサーバーサイド開発はこれから活発になるのは目に見えているので、この機会に多人数での開発のノウハウは身につけて損はないと思います。