チーム制作で失敗しまくった話(設計編)
俺、帰ったらブログ更新するんだ...という豆腐のように柔らかい意志が眠気に勝つことはできず見事に寝落ちをかましもうこんな時間。
というわけで今回は前回触れられなかった
2.設計をしっかりしなかったせいであとから見る時に嫌気がさすような設計を爆誕させてしまう
というところについて書いていこうと思います。ちなみにUnityのC#です
とはいってもプログラマー歴1年でまだ基礎も完璧とは言えないような人間が「こうやって設計しました」とか言っても何言ってんだこいつ、となるだけな上に、まともに考えずにごり押ししながら書いたので、今回はゲームジャムなどの短い制作期間の場合における上手い設計とはそもそもどういう設計なのか、ということを自分なりに調べてみたのでそれについて書いていこうかと。
・相互依存を減らす
今回自分のコードが見る気が失せるような原因になっただいたいの理由はこれ。AのスクリプトがBを参照していて、更にBのスクリプトがAを参照していて更に...という感じに、さすがに設計への理解が浅い自分でも「いやこれアカンやろ」となるような組み方をしてしまった。
言い訳をするならほぼ徹夜で1時間に1回ぐらいの頻度で変な笑いが出るような眠気の中で組んでいたというのもあるのだが、そもそも短い期間の開発なのだから企画の段階から工数的に厳しいものを考えってしまっていたという気もするので、やっぱり企画って大事だな痛感させられた。
そして相互参照が増えればそれに伴って、これいらなくない？みたいな変数や関数が増えるのは必然で結果的にクラスが肥大化してしまっていた。結果、自分で書いたくせに一晩寝て起きて見たら思わず「うわぁ...」と声が出るようなコードになってしまった。
そもそも自分が行き当たりばったりでどうにかなると思っていたことに問題があるのだが、前日に徹夜で進めても次の日進めるときに自分で書いたコードの解読をしていてはまったく意味がないので、まだまだオブジェクト指向のプログラミングに対する理解が甘いなと感じた。
・命名規則を決めておく
これも短い制作だからこそしっかり決めておくべきだなと感じた。自分の担当した部分は命名規則についてはある程度気を付けていたのでぱっと見疑問を覚えるような変数名や関数名を付けた覚えはないのだが...と思って自分のコードを見直していたらなかなかにひどい部分があったので訂正。自分もめちゃくちゃでした。
命名規則を決めておくことのメリットについてあげてみる。
1.バグが減り、保守性が上がる
関数の誤用だったりまったく違う変数にアクセスしたりという事故を防げる
2.開発メンバーにスキルが低い人がいてもある程度見やすいコードになる
自分が言えた義理ではないのですがもしスキルが低い人がいても命名規則を決めておけば、そこまで解読に時間のかかるコードは生まれることは少ないという感じ。
あと今回はUnityで制作したので
・Tagを一番最初に必要な分だけ挙げておく
せっかく便利な機能なので使わせてもらわないと、と思い使っていたですが、Git管理をしていると複数人が自分勝手にTagを作るとSourceTreeの方で競合が起こってしまって、今回なんかは「俺の作ったタグ無いんだが」とか「同じようなタグが2個あるんだが」とか起こったので、Unityで開発する際は真っ先に挙げておくべきです。
主にこの3点かなと。
あと、この記事を書くにあたって色々なブログを参考にさせて頂き、コーディング規約なる更にがっちりしたもの(コーディングスタイルだったり、禁止事項なども決めたもの)も目に入ってきたのですが、今の自分にそこまで制限できる知識もないしメリットも詳しく説明できないので割愛。
今後プログラマ複数人でチーム制作を行う際には、今自分で理解していて明確にメリットを説明できるような制限は設けるべきだなと感じました。
という訳で失敗談(設計編)でした。
次回は、3.メンバーの技術レベルを把握しきっていないためなかなか作業が進まない
について書いていこうかと。
今回はここまで。
チーム制作で失敗しまくった話(Git管理編)
「ブログを書くのです...」という天からの声をいただいたのでそろそろ放置していたこのブログも真面目に書き始めようと思います。
実質第1回である今回はゲームジャムでの失敗談と反省点をつらつらと書いていこうと思います。
まず経緯を書きますと、私の通っている学校で学年での催しとしてゲームジャムが先日7日から11日にかけて行われました。テーマは日本ゲーム大賞2017のテーマにもなっている「はさむ」。
開発環境はUnity5.6.0でソースファイルの共有はSourceTreeを使いGit管理していました。リードプログラマは自分が務め他メンバー3人の合計4人のチームで開発を行いました。
というわけで実質4日間程の制作期間だったわけですが、まあ色々問題大量発生という感じだったのでとりあえず起こった問題のなかでとりわけ深刻だったものをを羅列していきたいと思います。
1.SourTreeへの理解度が浅すぎてエラー解決までに時間がかかりすぎる
2.設計をしっかりしなかったせいであとから見る時に嫌気がさすような設計を爆誕させてしまう
3.メンバーの技術レベルを把握しきっていないためなかなか作業が進まない
という感じでとりわけひどかったのはこの3つです。
1.SourTreeへの理解度が浅すぎてエラー解決までに時間がかかりすぎる
自分は以前から触ったことがあったのですが、他のメンバーがGitによる管理が初めてなこともあってここでかなり時間を取られました。
自分以外のメンバー全員に起こったエラーはプルする際の「コミットされてない変更あるで」というエラー。実は今回学校側がGit管理をするように指定してきたので自分のように以前から触っている人間はなんとかなったのですが、メンバーの2人がほとんど触ったことのない状態だったようで開発初日の大半はコミット、プッシュ、プルによる問題で消えていきました。
もうひとつ学校側のプロキシによるエラーも起こったのですがこちらはターミナルでのプロキシのセット、アンセットを知っていたため割とスムーズに解決したので割愛。
ここまでさも自分がなにもやらかしていないように書いてきましたが懺悔の意もこめて自分の失敗も書いていきます。
・リモートリポジトリ作るのに時間かかりすぎ
先述したように自分がリードプログラマを務めたのですが初めてGit管理を行った制作で自分がリモートリポジトリを作ることになり、「まあできるやろ」とか思ってたら見事に1時間以上潰しました。今までやったことないのに中途半端な知識でできるわけないですね、はい。
まあなんだかんだで無事に作ることができたのですが、自分のGitに対する理解度の低さが顕著すぎる形で分かってしまったのでまた勉強しなおします...
・チームメンバーがエラーを出した際に迅速に対処ができなかった
初めて使った人間がエラーを出すのは仕方のないことなのですが今までで経験があるくせに原因を詳しく理解していないお前はなんのためにおるんやと、自らリードプログラマを引き受けたくせに中途半端な知識で指図されてメンバーにさぞ不信感を与えてしまったことだろうと思います。
というわけで今回のまとめ
・Gitへの理解が笑えないレベルで浅すぎるので自己満足で終わらせないためにも今後は自分が先導していけるレベルまで上げる
今回書いた内容についてはこれに尽きるなあと...
あ、忘れるといけないので覚えたことは今後もしっかり記事にしていこうと思います。
この記事ここまで読んでも解決策とかなにも提示していないし、こんな風な記事を書いていくだけなら続ける意味も薄いので...
あと、今回触れなかった2と3の失敗については明日以降に触れていきます。
それでは今回はこの辺で。
