ゆーとぴあ。ブログ

技術の備忘録や、日記などを投稿します

【雑記】命名規則と開発ルールを統一する重要さ

これまで私は、全員プログラマーのチーム、プランナーとプログラマーの混合チーム、プログラマーとクリエイターの混合チーム、実際の現場での開発など様々な複数人数での開発を経験してきました。

個人で開発している場合は、何も気にせず自由に開発していれば良いですが、

複数人での開発で各々コーディングした場合必ずしも記法や設計のこだわりが一致するわけではないので、どこかで違和感ややりづらさが生じてしまいます。

ほとんどの場合、そのような開発のズレが起こらないようにあらかじめ命名規則や開発ルールを設定しておきますが、開発中にこっちの設計のほうがいいんじゃないか...?みたいなことが起こることもあります。

私の経験を踏まえて、それぞれ統一化を怠った場合どれだけ損をするかをまとめてみました。

 

命名規則の統一化を怠った場合

ja.wikipedia.org

命名規則の分け方として一番上げられるのがCamel・Snake, Upper・Lowerだと思いますが、細かいので言うとメンバ変数に「_」(アンダースコア)をつけるかつけないかなど。ファイル名に指定することもあります。

この命名規則が実はかなり開発効率に響いてくるもので、例えば他のメンバーが作成したクラスを参照したいみたいなことがあったときに、少し書き方が違うと検索にひっかからなかったり、「_」がついてるついてないだけで用途が変わりかねないので最悪の場合バグとなり、原因に気付けないこともあります。

命名規則通りに書いていたとしてもメンバとローカル変数が似ていて書くほうを間違えバグるってこともあるので特に工夫した方がいいかもしれないですね。

 

設計やファイル構成、データ管理方法など開発ルールの統一化を怠った場合

もちろんこちらも開発効率に関わってくるものですが、ゲーム開発において起こりうる最大の壁があります。それは「仕様変更」です。

授業レベルの開発でも仕様変更することはよくあります。

そこで万が一設計のズレがあるととんでもないロスになる上に、スパゲティコードになりかねない事態になります。

e-words.jp

理想の役割分担としては、大まかな基底の部分、基底を継承している関連した中間層、それ以下の細かい部分をそれぞれ一人が担当することです。

その一人が他のメンバーに使い方を共有することで設計のズレなく機能を使用することができます。

 

各タスクや各メンバーの力量を踏まえた工数の見積もりを怠った場合

会社での本格的な開発でない限り忘れがち、または雑にしがちなのがこれです。

リーダーやマネージャとなっている人がメンバーと相談してうまく見積もっていきますが、もし雑に見積もりを行ってしまった場合、特定の誰かに大きな負担がかかってしまったりこのタスクが終わっていないとあのタスクができない!みたいなことになります。

これは結局経験を積み、メンバーとの開発を長い期間行うことでようやく見積れるようになっていくものなのでぜひ早いうちから自分と周りの技術力から工数を見積もっていく意識をしていくと良いと思います。

 

私は卒業制作においてリーダー兼プロジェクトマネージャを勤めましたが、初の経験だったということもあり、多くの反省に加え多くのことを学ぶことができました。

スプレッドシートを使って細かい分担なども行っていましたが、少数での開発でもかなりマネジメントが難しかったです。

これからも上記のことをしっかり意識して成長していきたいと思います。