読者です 読者をやめる 読者になる 読者になる

コーディングスキルの話:第一回・コーディングスキルの重要性

皆さん、コーディングスキル高めてますか?なにそれ?まさかプログラムが出来れば良いゲームが作れるなんて思ってる?

もしそんな人がいたら「日本語が出来れば誰もがベストセラー作家になれるわけじゃねぇ」と諭すところから始めねばなりません。

そして実際に多くの人が、なんとかプログラムが出来るようになっただけで、「良いコード」を作る方法を模作しないままになることがあります。(プログラムの入門書以降、ろくにプログラムの本を買ってない、とかないですか?)


最近、大量にプログラマを採用したのですが、コーディングスキルという意味ではまだまだまるでなっちゃいねぇ(口悪くてごめんなさい)と思わざるも得ない人もちらほらいるのですが、それでも採用したのは「頭がそれなりに良くて最後まで組み上げる力が立証できれば(それは課題で立証されてる)フォロー可能」と思ったからなのと、じゃぁ、どうやってフォローしよう?ということがココ最近の悩みでした。


一昔前なら「採用でいいけど、Effective C++の読了必須な」的に入社前の課題をお願いしたものですが、

Effective C++ 【改訂第2版】      アスキーアジソンウェスレイシリーズ―Ascii Addison Wesley programming series

Effective C++ 【改訂第2版】 アスキーアジソンウェスレイシリーズ―Ascii Addison Wesley programming series

今読むと、「イマドキのゆとりにはムリ!!」という程の難解さでとても課題にする気にならないという。。


「イマドキのゆとりにはムリ」とは随分横暴な言葉ですが、ちょっと前のゲームプログラマってC++の文法・挙動の正確な理解が必須で、その知識をもって10万行クラスのミドルウェアを正しく読み解くか、勢い余ってミドルウェア級のライブラリを自作するかとか、司法試験の受験生並みに勉強することを求められてたので、その目線から言えばiOSやUnityの入門書読んで実際にアプリを作れるようになったくらいなんざ、ゆとりもゆとりって思っちゃうもんなんすよ。
(リアルな話、JavaLL系言語の経験のみのプログラマは採用しない、というゲームプログラマの現場はよく聞きます)


っと、ちょい前のゲームの現場のやり方を私は求めてないので、「イマドキのゆとり」という言葉は使いましたが、実のところ、ゆとりとかそんなことは思ってません(話の筋上そう言っただけなので許して下さい)


だって、私がホントに覚えて欲しいことって、C++の難解な裏技大全集よりも、今我々が直面するフレームワーク(UnityやCocoa、cocos2dなど)の勘所なので、正確に言えば、そういう間口から入った人達にコーディングスキルを高めてもらうくらいのことで、C++未経験の人もいるなかで皆にEffective C++を読んで欲しい、とはいささかでかすぎる負担かな、と思ってるのです。


もっと言えば、司法試験の受験生並みに勉強するくらいなら、最低限のプログラムの勉強にフォーカスして、いろんなゲームをプレイしたり、勉強会などの会合に出席したり見聞を広めるのに時間を使って欲しいところ(既に採用が確定した人達はご存じの通り、↑以外の課題はしこたま出させていただいてますしね(^^;


っと、大きく脱線しましたが、要は、UnityやCocoaにフォーカスした人に向けた、最小限の資料が中々ないなぁ、と。


っということで、不定期連載でコーディングスキルの重要性やポイントをブログでぽちぽち書いてこうと、どんだけ出来るか不安ですが、無鉄砲なことを思ったのでした。


本題はこっから、というには前振り長すぎますが、今回はコーディングスキルがどれだけ重要かということだけ。



言わずもがな、プログラムを覚えただけで良いコードを書く方法を知らないことは、軍隊で例えるなら「引き金を引けば弾が出る」程度の知識しかない、一般人に銃を持たせただけの戦闘員みたいなものです。それだけでも銃で相手を威嚇するなどの簡単な仕事は出来るでしょうが、ちょっと大きな戦闘になれば、同士撃ちをしたり、状況の判断がつかず危険な行動をして地雷を踏んだり蜂の巣になったり、人数が多いほど仇となる壊滅的な行動もとりがちです。







一方、良いコードを書くように訓練されたプログラマは、仲間の足をひっぱることはせず、フォローしあう関係を築き、最小限の弾薬でミッションをこなし、さらに負傷兵(バグ)のケアをしつつ定時に帰ります。大きな戦いにも多勢を必要とせず、冷静に必要な武器・物資だけを選び効果的な戦況をこなしていきます。





両者の違いは明白ですが、重要なのは、「良いコードを書く」ことの善と「良いコードを書くことを求めないこと」の悪をちゃんと認識することです。

良いコードを書くということは、状況に合わせ、enumを使うべきかdefineを使うべきか、constを指定すべき(constが使える場所なのか)か、ポインタを渡すべきかを的確に判断し、第三者が理解できる可読性高い関数名、変数名、コードの流れになってるかを自己判断できるということです。


そんな話を不定期で思いついた端から、今のiOS/Unityプログラマに最適な形で紹介したいな、と思ったのですが、いささかデカイ仕事になりそうなので「社長にそんな負担かけちゃいけねぇ」と社員が自主トレして話が終わりましたな流れ希望ですが、とりあえず第二回は「コーディング規約の重要性」を書きたいと思います。


ネタ的にはテストファーストとかアジャイル論法もありますが、いきなり「アジャイル」って言われても?になっちゃうと思うので、出来ることを一歩一歩習得してきましょう(あとは私のボケ防止)
(※アジャイルとかのヨコモジに苦手意識がある人はこちらのマンガの「ゼミ」を「アジャイル」に読み替えるとよいと思います。 http://blog.livedoor.jp/kinisoku/archives/3195922.html


願わくば1週間以内に連載第二回を目指します。