チーム制作で失敗しまくった話(設計編)

俺、帰ったらブログ更新するんだ...という豆腐のように柔らかい意志が眠気に勝つことはできず見事に寝落ちをかましもうこんな時間。

というわけで今回は前回触れられなかった

2.設計をしっかりしなかったせいであとから見る時に嫌気がさすような設計を爆誕させてしまう

というところについて書いていこうと思います。ちなみにUnityのC#です

とはいってもプログラマー歴1年でまだ基礎も完璧とは言えないような人間が「こうやって設計しました」とか言っても何言ってんだこいつ、となるだけな上に、まともに考えずにごり押ししながら書いたので、今回はゲームジャムなどの短い制作期間の場合における上手い設計とはそもそもどういう設計なのか、ということを自分なりに調べてみたのでそれについて書いていこうかと。

・相互依存を減らす

今回自分のコードが見る気が失せるような原因になっただいたいの理由はこれ。AのスクリプトがBを参照していて、更にBのスクリプトがAを参照していて更に...という感じに、さすがに設計への理解が浅い自分でも「いやこれアカンやろ」となるような組み方をしてしまった。

言い訳をするならほぼ徹夜で1時間に1回ぐらいの頻度で変な笑いが出るような眠気の中で組んでいたというのもあるのだが、そもそも短い期間の開発なのだから企画の段階から工数的に厳しいものを考えってしまっていたという気もするので、やっぱり企画って大事だな痛感させられた。

そして相互参照が増えればそれに伴って、これいらなくない？みたいな変数や関数が増えるのは必然で結果的にクラスが肥大化してしまっていた。結果、自分で書いたくせに一晩寝て起きて見たら思わず「うわぁ...」と声が出るようなコードになってしまった。

そもそも自分が行き当たりばったりでどうにかなると思っていたことに問題があるのだが、前日に徹夜で進めても次の日進めるときに自分で書いたコードの解読をしていてはまったく意味がないので、まだまだオブジェクト指向のプログラミングに対する理解が甘いなと感じた。

・命名規則を決めておく

これも短い制作だからこそしっかり決めておくべきだなと感じた。自分の担当した部分は命名規則についてはある程度気を付けていたのでぱっと見疑問を覚えるような変数名や関数名を付けた覚えはないのだが...と思って自分のコードを見直していたらなかなかにひどい部分があったので訂正。自分もめちゃくちゃでした。

命名規則を決めておくことのメリットについてあげてみる。

1.バグが減り、保守性が上がる

関数の誤用だったりまったく違う変数にアクセスしたりという事故を防げる

2.開発メンバーにスキルが低い人がいてもある程度見やすいコードになる

自分が言えた義理ではないのですがもしスキルが低い人がいても命名規則を決めておけば、そこまで解読に時間のかかるコードは生まれることは少ないという感じ。

あと今回はUnityで制作したので

・Tagを一番最初に必要な分だけ挙げておく

せっかく便利な機能なので使わせてもらわないと、と思い使っていたですが、Git管理をしていると複数人が自分勝手にTagを作るとSourceTreeの方で競合が起こってしまって、今回なんかは「俺の作ったタグ無いんだが」とか「同じようなタグが2個あるんだが」とか起こったので、Unityで開発する際は真っ先に挙げておくべきです。

主にこの3点かなと。

あと、この記事を書くにあたって色々なブログを参考にさせて頂き、コーディング規約なる更にがっちりしたもの(コーディングスタイルだったり、禁止事項なども決めたもの)も目に入ってきたのですが、今の自分にそこまで制限できる知識もないしメリットも詳しく説明できないので割愛。

今後プログラマ複数人でチーム制作を行う際には、今自分で理解していて明確にメリットを説明できるような制限は設けるべきだなと感じました。

という訳で失敗談(設計編)でした。

次回は、3.メンバーの技術レベルを把握しきっていないためなかなか作業が進まない

について書いていこうかと。

今回はここまで。