こんにちはwatomonです。いやぁ〜時の流れは速いもので、もう１２月終盤ですよほんと。2017も終わりですよ、まぁ季節意識せず生きてるもんだから特にこれといったことはないんですけどね。
というわけで、後期の授業が一度終わりました。その中でもプロジェクト演習という６人でチームを組み、コンテンツ・プログラマ・マネージャーと役職を決めてJavaのフレームワークを用いてゲームを製作するというグループワーク型の授業もひと段落しました。個人的にこの授業にかなり熱中というか、今までに類を見ないくらい真剣になり、色々と僕自身が気づかされることが多かったので、ブログで書き留めることにしました。
他人と開発するということ
それまでの自分は、個人でプログラムを書くことしかしませんでした。コメントも必要最低限に留めていて、他人が読むのは少しかったるいと思います。ですが、複数人で開発する上では、同一のコードに変更を加えることだってあります。よって、プログラムの解読に費やす時間を減らし、作業の効率化を図る必要がありました。
”他人のプログラムを読むほどストレスのあるものはない”
というのは的を得ているなぁと思いました。なので、自分が担当する機能の実装は、こまめにコメントで情報を記載し、他人が自分のコードを読むときの負担を減らすようにする必要があったのです。
実際、フレームワークを使う上でも、記述されたクラスとメソッドを理解し、何が継承されているかを覗いてやる必要があります。ぶっちゃけこれが一番しんどかった。今回は、うちの大学の研究室が自作した、３Dを扱うRadishというフレームワークを用いました。いくつかテンプレートのゲームが用意されており、他のチームはそれを参考に少しいじってオリジナリティを加える様子でした。
ですが、これは僕のしょうもないプライドのせいか、”書き換えただけのプログラムは嫌だ”という気持ちがありました。どうせなら、いくつかのテンプレを利用して、全く新しいコードを書きたかったのです。実際、僕たちのチームはタワーディフェンスゲームを作ることになりました。テンプレートにもそういうゲームがなかったので、作ろうという気持ちが湧いてきたのです。
”わからない”を乗り越えるために
ただやはり、僕自身も含めて設計や要件定義の経験もありませんでした。僕はプログラム担当だったため、設計に携わることになります。マネージャーはプログラミングは得意でないものの、ゲームをかなりこなす人で、「もしかしたらこれ使えるんじゃね」といったアドバイスをくれました。実際僕は、彼の的確なアドバイスに救われることになります。
設計はできても、やはりどう実装するかがいまいちピンとこない。僕はまず、フレームワークのコード全てを目を通すことにしました。クラスの親子関係はどうなっているか・使えそうなクラスやメソッドが無いかを徹底的に分析しました。僕はこれがかなり大事だと自負していて、というのも、フレームワークを使うなら誰でもできると思っていたからです。だって、ほとんど書き換えなくても動くんだし。だが、何かしら問題が発生したとき、中身をある程度理解していたら、もしかしたら対処できるかもしれない。僕はこれを確信していましたし、現に大いに役に立ちました。
わからないものは徹底的に調べ上げる。どうしてもわからない時だけ、教員に聞く。基本的にこのサイクルを回していたように感じています。ですが、この意識を他人と共有することは実は難易度的に別問題だったりします。
お互いにコミュニケーションを促す
作成する上で、今回はGitHubを利用しました。自分はGitHubは個人で使っていましたが、他人と一緒に管理するのは初めてだったのです。当然、ブランチに関しては無知でした。その結果、私のチームを含めるほとんどのチームで何が起こったか、
コンフリクトの嵐でした。
いつプッシュするか、今プルしていいか、いつマージを承認するか。これを口頭で言わずに行うことで、情報共有が乱れることになりました。当然masterが荒れているので作業ができずに無駄な時間を過ごしてしまうことが初回で何度かありました。当然納期は迫ってきます。我々のチームではこのようなことを今後再発させないために、ルールを決めました。
- 何かしら、Gitのアクションを行う際は、マネージャーに報告する。
- マネージャーは全員に確認を取り、アクションをして良いかの意思決定をする。
- 悩んだら必ず二人以上に相談する。
たった、これだけのことを守るだけで、リモートの競合を防ぐことができたのです。些細なことですが、重要なことです。
まだまだ書き足りないことばかりですが、また次の記事で書こうと思います。
流石に徹夜２連続は死ぬ....
ではでは。
