WonderPlanet DEVELOPER BLOG

ワンダープラネットの開発者ブログです。モバイルゲーム開発情報を発信。

Unity + Daydream開発はじめの一歩(2017.6月最新版)

今回はUnity + Daydreamを使用したVRアプリ開発の第一歩を書きたいと思います。

開発環境

Unity5.6.1f1(Unity5.5.xはDropdownの表示に問題があるため使用不可)

今回の記事を実践するに当たっての前提

  • Unityはインストール済みであること
  • Android SDKはインストール済みであること(APIレベル24以上)
  • UnityのAndroid SDKの設定は完了済みであること

対象者

  • Unityの操作はある程度出来るレベル

スクリーンショットはMacですが、Windowsでも基本的には変わらないはずです。

今回は新規プロジェクトを作成し、イチから作っていきます。 f:id:m_iwahara:20170627124217p:plain

1. Google VR SDKのダウンロード

Google VR SDKのダウンロードを行います。

Downloads and Samples | Google VR | Google Developersページ内の 「Download SDK」をクリックすると、SDKをダウンロードできます。 執筆時点(2017/06/27)でのバージョンは1.60になるかと思います。

f:id:m_iwahara:20170627125724p:plain

2. プロジェクト設定の変更

Unityプロジェクトのビルド設定をAndroid向けに設定します。 このあたりは通常のUnityと変わりません。 手順は以下のとおりです。

  1. [File] -> [Build Settings]を開く。
  2. [Platform]で[Android]を選び、[Switch Platform]をクリックする。

3. Google VR SDKのインポート

Google VR SDKのインポートを行います。 SDKはunitypackage形式で提供されているので、開けばインポートされます。 手順は以下のとおりです。

  1. ダウンロードした「GoogleVRForUnity.unitypackage」を開く
  2. [Demos]のチェックを外す(Demoシーンを利用したい場合はチェックを入れたままにする)
  3. [Import]をクリックする f:id:m_iwahara:20170627141053p:plain

4. Daydream対応にする

Daydream対応のアプリにするため、設定を変更します。 DaydreamはAndroid7.0以上である必要があるため、合わせてAPIレベルも変更します。 手順は以下のとおりです。

  1. [Edit] -> [Project Settings] -> [Player]を開く
  2. [Virtual Reality Supported]にチェックを入れる f:id:m_iwahara:20170627141313p:plain
  3. [Virtual Reality SDKs]のリストでDaydreamを選択する f:id:m_iwahara:20170627141338p:plain
  4. [Minimum API Level]を[Android 7.0]に設定する f:id:m_iwahara:20170627141413p:plain

5. Daydream用オブジェクトの配置

DaydreamアプリをUnityエディタで実行するのに必要なPrefabをゲームに配置します。 これで、実機を通さなくてもある程度の検証が可能になります。 手順は以下のとおりです。

  1. [project]ウィンドウ内の[Assets] -> [GoogleVR] -> [Prefabs] -> [GvrEditorEmulator]をHierarchyのルートに配置する。 f:id:m_iwahara:20170627143012p:plain

6. 確認用オブジェクトの配置とカメラ位置の調整

実際に動いているかチェックするために、Cubeを少し前に置いておきます。 また、カメラ位置はあとで操作しやすいように[0,0,0]に直しておきます。 手順は以下のとおりです。

  1. cubeを[0,0,5]の位置に配置する f:id:m_iwahara:20170627144721p:plain
  2. Main Cameraの位置を[0,0,0]に調整する f:id:m_iwahara:20170627144739p:plain

7. エディタ実行

エディタ実行するとCubeが映し出されるはずです。 この状態でALTキーやControlキーを押しながらマウスカーソルを動かすと、カメラも合わせて動きます。

ALTキーを押しながらマウスカーソルを動かすと、Y軸を中心としてカメラが回転します。 f:id:m_iwahara:20170627150736g:plain

Controlキーを押しながらマウスカーソルを動かすと、Z軸を中心としてカメラが回転します。 f:id:m_iwahara:20170627151205g:plain

8. 実機実行

ビルドして実機で実行したい場合は、以下の手順を実行します。

  1. シーンを保存します。
  2. [File] -> [Build Settings]を開く
  3. [PackageName]をデフォルト(com.Company.ProductName)から変更する f:id:m_iwahara:20170627152458p:plain

なお、初めて実機で実行する場合は、端末側で初期設定が必要です。 基本的に画面の指示に従えば良いのですが、PlayストアのPINコードが必要になりますので、用意しておくと安心です。

以上、はじめの一歩でした。

長くなってしまったので、Daydreamのコントローラに関しては別の記事に書こうかと思います。

海外展開するにあたって

エンジニアの田島です。

クラッシュフィーバーの海外展開を担当していて、国内版とは違う点を書きたいと思います。

マルチ応募で使うSNSについて

 国内版と繁体字版ではマルチの応募をLINEで行うのですが、グローバル版と韓国版ではLINEから変更しています。

 グローバル版はリリース当初は15言語対応でリリースする事が決まっており、
 国ごとに最適なSNSで募集ができるよう、様々なSNSをサポートするShareSDKに変更しました。

 韓国版については韓国ではKakaoTalkが最も普及しているのでKakaoTalkに変更しました。

タイムゾーンと回線速度

 また、グローバル版は15言語対応ということで、タイムゾーンはUTCで設定しています。
 時差の計算をしてデータ設定するのが大変そうでした。

 その他にも各国で回線スピードが一定ではないので、国内版では実装していない機能の
 分割ダウンロードを追加で実装する必要がありました。

サーバーAPIのリポジトリ管理について

 国内版と繁体字版だけの時はサーバーのAPIコードも別々のブランチで管理されていました。

 国内版で開発した機能を繁体字版にマージして繁体字版を最新に更新するという手間のかかる作業を行なっていましたが、
 コンフリクトが発生した場合にマージ作業が大変になる事が多くありました。

 この辺はグローバル版をリリースする時に統一ブランチを作成してマージ工数の削減は行なっています。

AWSについて

 AWSについてもリージョンによっては使えないサービスがあるので注意が必要です。

 現在は1つのリージョンで運用しているので問題はないのですが、
 国ごとにリージョンを分ける事になった場合は代替サービスを検討したり、
 使えるサービスで置き換えられるかの検証も必要になってきます。

 APIへのアクセスについては、Amazon CloudFrontをキャッシュ無しでアクセスする形式を取っております。
 こうすることで、世界中からのアクセスに対して低レイテンシーを実現しております。

まとめ

 まだまだ、海外展開をする事でやらなければいけない事や注意する点は多いです。

ベクションによる酔いを体感するアプリを実際に作って体感してみた

今回はVRでネックとなる「ベクションとVR酔い」について、実際にアプリを作成して体験してみました。


そもそもベクションとは?

視覚誘導性自己運動感覚(しかくゆうどうせいじこうんどうかんかく、ベクション(英: vection)とも)とは、実際には静止している人間が、視覚情報によって移動しているような感覚が引き起こされてしまう現象である。

視覚誘導性自己運動感覚 - Wikipediaより引用。

VRには欠かせない要素であり、ベクションによって仮想空間内を移動しているように感じることが出来ます。 しかし、実際に身体は移動をしていないため、三半規管との認識に齟齬が発生し、VR酔いに繋がってしまう要素でもあります。 なので、VRでは勝手にカメラを動かすことはご法度とされているわけです。


作ってみた

ということで、実際にVR空間を移動するアプリを作成し、VR酔いを体験してみました。 実行環境はHTCのVIVEを使用し、Unityで開発しました。 仕様は以下のとおりです。

以下、それぞれ体験してみた感想です。


一人称視点(等速移動)

f:id:m_iwahara:20170626112809g:plain

個人的な感想
  • 移動開始時が一番酔う
  • Z軸の移動より、X軸の移動のほうが酔う

一人称視点(加速移動)

f:id:m_iwahara:20170626113237g:plain

個人的な感想
  • 思ったよりは酔わなかった
  • 視界制限を入れてみたが、あんまり効果は感じられず
  • 視界制限を広くするタイミングが早すぎたかも

三人称視点

f:id:m_iwahara:20170626113505g:plain

個人的な感想
  • カメラをY軸を中心にグリグリ回転させればもちろん酔う
  • それ以外は、思ったより酔わなかった

おまけ(実際に走る動作)

コントローラを激しく上下することで、走っている動作を模し、認識の齟齬を減らす試みです。

f:id:m_iwahara:20170626113907g:plain

個人的な感想
  • 走るためにコントローラを動かすので、正直酔ってる場合ではない!
  • 酔うのは移動にしか集中していないから?
  • 移動以外に注意を向けられればVR酔い対策になるかも

結論

酔うものは酔う。慣れるしか無い!

…というのも身も蓋もありませんので、GoogleのDaydream Labsが紹介しているVRにおける移動システムの知見を紹介します。 Daydream Labs: Locomotion in VR


等速移動

緩やかな加減速はせず、移動は一定速で固定する移動方法です。 ローラーコースターのように加減速を繰り返していても、実際には移動していないのでVR酔いにつながるようです。


トンネリング

VR酔い体験アプリでも実装した、移動中は視界制限をして移動する方法です。 視野の大部分を静止した空間が占めることによって、VR酔いを起きづらくするようです。


テレポーテーション

f:id:m_iwahara:20170626114321g:plain

画像はDaydream Labs: Locomotion in VRより引用

加速も減速も無いので、非常に酔いづらい移動システムです。 ただし、プレイヤーの空間把握に混乱が生じるので、何かしらの方法で移動したことを伝える必要があります。 また、ゲーム内に組み込むべき理由付けが出来ないと、没入感を損ねたりします。


立つか、回転する椅子に座る

ハードウェアの制限などにより、360°回転させることは出来ないため、 立つか回転する椅子に座ってプレイすることを想定して設計することは非常に魅力的です。 プレイヤーがVR空間でどこに行きたいのかを確認させるために、VR空間内で自身を回転できるようにすると良いそうです。


最後に

VRの制限をゲームデザインに取り入れるという考え方もありますが、 どちらにせよ、ゲームに合わないのであれば、ユーザーは離れていってしまうので難しいところです。


ライセンス表記

f:id:m_iwahara:20170626122231p:plain

キャラクターに込められたコンセプトやテーマについて

こんにちわ!

デザイナーの渡辺です。 

 

主にキャラクター指示書やゲーム内背景の指示書の作成及び

赤入れの制作などを行っております。

 

今回は指示書作成において超重要な部分である

「コンセプト」「テーマ」について、

実際にどのような内容で指示書を作成したかを

具体例やちょっとした裏話も兼ねてお話ししたいと思います!

 

キャラクターの指示書が出来上がる過程につきましては、

同じくデザイナー伊藤さんの記事

クラッシュフィーバーのキャラクター指示書ができるまでをぜひご覧ください!

 

コンセプトとテーマとは

伊藤さんの記事で触れていた「ユーザー様に届けたい価値・個性」にあたる部分です。

 

少し前までの指示書では、指示書の説明文にキャラの個性や価値を文言で

説明していましたが、よりクリエイター様に完成系のイメージが伝わるように

コンセプトに加えてキャラクターごとに「テーマとなる文言」をそれぞれ用意し

指示書に記載するようになりました。

 

今回は実際に私が指示書を担当した中から

「ギルガメッシュ」「ガンバンテイン」「ストレングス」

3キャラのテーマやコンセプトなどご紹介致します!

 

 

・・・「ギルガメッシュ」の場合

■R6ギルガメッシュ

f:id:wp-watanabe:20170609155634p:plain

テーマ「チェスの兵士・残虐・少年」

 

史実では神格化されたりした人物ですが、

同時にとてもわがままな暴君であったという話から

「頭が切れるが、ワガママで、子供の残虐性を持った少年」キャラクターとしました。

 

自らは武器を振るわず、チェスで戦術を練りつつ徹底して部下に攻撃を行わせる姿で

余裕のある感じを狙っています。

 

実は頭に浮かんでいる王冠は、ALICE内で相当な金額のかかるアイテムのイメージで付けてもらいました。

ギルガメッシュががんばって手に入れて、自分が偉い王様だと見せびらかすために

いつも装備しているような・・頭は切れるけど、ちょっと年相応なかわいい子供っぽい部分も覗かせているイメージです。

 

 

 

・・・「ガンバンテイン」の場合

■R5のガンバンテイン

f:id:wp-watanabe:20170609155615p:plain

テーマ「癒し・魔法少女・たまご」

 

癒し担当の女の子で、

ライトノベルに出ていそうな妹系のロリロリな魔法少女がコンセプトです。

 

ガンバンテインは、あらゆる魔法を無効化する杖という元ネタから

補助を得意とする回復系のキャラクターとし、

また、補助・防御に優れている・無効化するというイメージから

杖には綺麗なたまご(母性や保護の象徴)のモチーフを使用していただきました。

たまごは、「魔法少女のたまご」という意味合いも兼ねています。

 

R6の姿に覚醒した際、アニメの魔法少女のようにガラッと姿が変わっているのは

実はこのテーマに沿っていたからなんですね。

 

■R6でのガンバンテイン

f:id:wp-watanabe:20170609155838p:plain

ユーザー様の中でもこの「魔法少女」のテーマに気づいている方がおり、

気持ちが伝わったようでうれしくなりました。

 

 

 

・・・「ストレングス」の場合

■R6ストレングス

f:id:wp-watanabe:20170609160307p:plain

 テーマ「ゴシックビーストテイマー・ライオン・不気味な少女」

 

ストレングスはタロットカードの「剛力」が元ネタです。

タロットカードでは白いワンピースを着た女性がライオンの口を押さえて

服従させているという、どこか神秘的で謎めいた内容だったので、クラフィでは

「何を考えているのかよくわからない、ちょっと不気味な女の子ビーストテイマー」

というコンセプトで行くことにしました。

ビーストテイマーというと、大抵毛皮の獣っぽい衣装やサーカス等を思わせる

服装を思い浮かべると思いますが、クラフィではあえて世界観にあった

現代的でゴシック風のセクシーなデザインとすることで個性的な女の子になるよう

狙ってみました。

 

他にもリボン風のゴシックなアイパッチや、女の子自身にもライオンっぽい部分を

入れてもらうなど、個人的なフェチズムが全開の内容となっています・・・(笑)

 

ーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーー

 

 

今回は「ギルガメッシュ」「ガンバンテイン」「ストレングス」をご紹介させていただきましたが、いかがでしたでしょうか?

 

クラッシュフィーバーでは、キャラクターのデザインに

「クラッシュフィーバーらしさ」を求められており、

できるだけありきたりだったり、見ていて退屈にならないように

デザイナー班やスタッフ一同で奮闘しております。

 

今後新しいキャラクターが出てきた時に、

何のテーマで作ったのか考えてみると面白いかもしれませんね。

 

それではお読みいただき、ありがとうございました!

 

 

シルエット素材を作ってみよう

こんにちは。

グラフィックデザイナーの大鹿です。

私の主業務はクラッシュフィーバーのアプリ内外で使われる

「バナー」制作ですが次いで頻繁に作るモノがあります。

それは「シルエット素材」です。

 

シルエット素材は文字通りキャラクターイラストをシルエット化したものです。

最高難易度クエストのバナーやお知らせ記事内でよく使用されます。

今回はそのシルエット素材を作る行程をご紹介したいと思います

 

1.シルエット化するイラストpsdを用意

f:id:ooshika:20170606193028p:plain

今回、解説用にシルエット化するのは最高難易度ボスの一人「織田信長」です。

デザイン、性能ともにユーザー人気の高いキャラクターです。

 

2.光彩エフェクトを取り除く

 

f:id:ooshika:20170606193136p:plain

クラッシュフィーバーのキャラクターイラストは

すべてのフチに「光彩エフェクト」が施されています。

これらはシルエット化にあたり輪郭がボケてしまうので取り除きます。

上図はキャラクターやエフェクトの周囲にあった「光彩エフェクト」を

取り払ったものです。

 

3.余分なエフェクトイラストを取り除く

f:id:ooshika:20170606193150p:plain

キャラクターの周りに張り巡らされるエフェクトイラストは

動作感や空気感を表現する大事な部分です。

とはいえ、シルエット化するとキャラクターの輪郭が隠れてしまうため

一部を残して取り除きます。

 

4.シルエットのベースカラーを配置する

f:id:ooshika:20170606193219p:plain

キャラクターのレイヤーを統合し、上からグラデーションレイヤーを重ねます。

クリッピングマスクでグラデーションレイヤーを切り抜いたら

乗算もしくは不透明度90%程度に設定して少し元絵が見えるようにします。

ついでに横線パターンを追加して「走査線」っぽく見せたりします。

また、キャラクターのシルエットをより目立たせたり

全体のバランスが崩れないようにエフェクトの一部はシルエット化せずに残します。

 

4.顔部分に濃い色を配置して隠す

f:id:ooshika:20170606193318p:plain

ベースカラーの上に新規レイヤーを作成します。

円形グラデーションツールでキャラクターの顔を中心に

不透明度100%のグラデーションを配置します。

色は黒だったり、ベースカラーをより濃くした色を使用します。

これで明度を上げられたりしてもキャラクターの顔だけは隠し通すことができます。

さらに奥行き感も演出できます。

 

6.目を光らせる

f:id:ooshika:20170606193345p:plain

シルエット化させるキャラクターは大半が最高難易度ボス。

強敵感を演出するためにも、目を光らせます。

場合によっては口も光らせたり、目の残像を描き入れたりもします。

 

7.隙間を塗りつぶす

線画と塗りの間など、キャラクターイラストには

拡大しないと見えないような隙間がたくさんあります。

普段は光彩エフェクトやサイズ感のおかげで目立たないのですが

色を載せてシルエット化すると、隙間が白い筋となって見え始めます。

 

f:id:ooshika:20170606193513p:plain

↑隙間どころか穴が開いているケースも...

f:id:ooshika:20170606193524p:plain

↑よく見ると武器周辺にも隙間がたくさん...

 

f:id:ooshika:20170606193410p:plain

手間ですが、下側に新規レイヤーを作成して塗りつぶします。

隙間を全部埋めれば、シルエット素材の完成です。

 

最後に...

シルエット素材はクラッシュフィーバーがスタートしてから

小さく地味な改修を重ねて今に至ります。

「元絵を少し見せたほうが、顔が気になって期待感が上がるかもしれない」

「走査線っぽいエフェクトがあったほうが世界観にあっている」

「エフェクトを少し残したほうがシルエットがもっと目立つ」

ただのベタ塗りでも良かったのかもしれません。

しかし、クラッシュフィーバーのデザイン感とマッチするように

ユーザーの目にもっと留まるように、面白そうと思ってもらえるように。

なんてことのない素材の一つですが、キチンとこだわって作ることが

大事なのだと信じて、作成しています。

 

もし気が向いたらお知らせ欄にいるシルエットを眺めて

どんなキャラクターなのかを妄想していただけると幸いです。

図を継続的に管理するためのベストプラクティス

こんにちは。サーバエンジニアの桐島です。

今回は、図(フローチャート、シーケンス図など)をチームで継続的に管理するための個人的なベストプラクティスを紹介したいと思います。

図の有用性と、継続的な管理の必要性

図って便利ですよね。

以下の様な図があると、チーム内での認識合わせを正確に素早く行うことができます。

  • サーバ構成図
  • アプリ-サーバ間処理のシーケンス図
  • APIプログラムの複雑なロジックのフロー図
  • ER図

ただ、プロジェクトのドキュメントに含まれる図がすべてメンテナンスされ、最新の仕様と図がマッチし続けているケースは少ないのではないでしょうか。

図は有用なのですが、管理し続けなければその有用性を失い、いずれ削除される運命にあります。

図の継続的管理への課題

では、図が管理されない原因は何でしょうか。 具体的なケースを幾つか挙げてみます。

  • 再編集できないフォーマットで図が作られている
    • ホワイトボードに書いた図を撮影した写真を共有する
    • 再編集できない画像ファイルとして共有する
  • 再編集できるフォーマットで作られているが、閲覧・編集するために特殊なツールが必要となる
    • 専用ツールのインストールが必要となる
    • インストールに手間が掛かる
    • Mac と Windowsでツールの動作が異なる
    • ツールの学習コストが高い
  • 図の存在が知られていない(図が散在している)
  • 知らない間に図の内容が古くなっている

これらケースから考えると、大きな原因は以下の2点にありそうです。

  1. 図の閲覧、作成、編集がハイコスト(特に編集)
  2. 図を作成するタイミングが決まっていない

この課題をクリアし、図を継続的に管理するための方法を考えたいと思います。

継続的画像管理のアイデア

先に結論を書くと、以下方法が良いと考えています。

  • SVG形式で図を扱う
  • draw.io と GitHub で図を作成、編集する
  • 図の変更をPullRequestに含める

f:id:s-krsm:20170529121549p:plain

この方法のメリットは以下となり、上述の課題を解決できそうです。

  • チームメンバ全員が簡単に同じ方法で図を閲覧、作成、編集することが可能
    • 図の閲覧、作成、編集のローコスト化
  • プログラムと図を紐付けてバージョン管理することが可能
    • 図の作成、更新タイミングの明確化

次に、具体的な手順を見ていきたいと思います。

具体的手順1(図の作成)

1. draw.ioで作図

draw.io で図を作ります。

f:id:s-krsm:20170529121446p:plain

2. SVGとしてexport

SVGファイルとして保存することで、draw.ioで再編集可能となります。

f:id:s-krsm:20170529121718p:plain

export実行します。

f:id:s-krsm:20170529121801p:plain

3. export先として GitHubを選択

f:id:s-krsm:20170529121834p:plain

draw.ioとGitHubを連携するためには認証が必要です。

連携したGitHubアカウントがアクセス可能なリポジトリ一覧が表示されます。

f:id:s-krsm:20170529121911p:plain

4. export先のリポジトリ・ブランチ・ディレクトリを選択

f:id:s-krsm:20170529121944p:plain

commit メッセージを書き、OKボタンを押すとcommit完了です。

(SVGファイルが指定リポジトリに追加されます)

f:id:s-krsm:20170529122019p:plain

具体的手順2(図の編集)

1. GitHub上のファイルを開く

f:id:s-krsm:20170529122151p:plain

作成時と同様の手順でGitHub上のsvgファイルを選択します。

(リポジトリ・ブランチを選択可能です)

2. 変更をcommit

GitHub上のファイルを編集した場合、編集後に「Unsaved changes. Click here ti save.」というボタンが表示されます。

f:id:s-krsm:20170529122232p:plain

これをクリックすると、commitメッセージを書いてcommitすることができます。

(commit先は、ファイルを開く時に指定したブランチとなります)

f:id:s-krsm:20170529122307p:plain

具体的手順3(図の差分確認)

PRのレビュー時に画像の差分を確認しますが、GitHubのrich diffツールが素晴らしいです。

SVGファイルの文字列差分では変更箇所は分かりませんが、rich diffツールを使うと画像の変更箇所を素早く把握することができます。

2-up で差分確認した場合

f:id:s-krsm:20170529122354p:plain

Onion Skin で差分確認した場合。

f:id:s-krsm:20170529122404p:plain

具体的手順の紹介は以上となります。

ブラウザだけで図の作成、git commit/push、レビューまで完結できていることは驚きですね。

まとめ

図を継続的に管理するための個人的なベストプラクティスを紹介しました。

ただ、図の扱いはチーム(規模、構成、状況等)により、メリットもデメリットも異なると思います。

例えば、リモートワーカーが居るチームでは図を作成し共有することによるメリットが大きいですが、小さなチームの開発初期段階では、作図コストのデメリットが大きいかもしれません。

また、必要となる図の対象・粒度もチームにより異なると思います。

今回の記事が、チームに最適な図の共有方法を考える参考になれば幸いです。

バグを生まないために気をつけたいコードの書き方

こんにちは。アプリエンジニアの大橋です。

今はそれほどではないのですが、少し前まで仕事の大半をコードレビューに費やしていた時期がありました。
どちらかというと自分で実装する方が断然好きですが、
それはさておき、いろんなコードを見るなかで、
「このコードの書き方だと、正常に動作してはいるけど、後々不具合を生みやすそうだなぁ」
と感じることがあったりするので、
そういうコードのパターンをいくつか取り上げさせてもらおうかなと思います。
自分自身も気を付けたいという意味も多分に含んで。

というわけで、さっそくひとつめ。

変数名や関数名が処理内容と違う

基本的なことではありますが、たまにやってしまいます。

コードを読むとき、変数名を見て「こういうことに使ってる変数かな?」と想像して読んだりしますが、
実際は違った使われ方がされてると、コードの理解の妨げになりますし、
誤解したまま別の人がその変数を使ったりすると不具合の原因になってしまいます。

関数名やクラス名もまた然り。
ちゃんと処理内容にあった変数名や関数名を付けましょう!!

あと余談ですが、自分が実装するとき、変数名や関数名の名前に結構悩みます。
的確な名前を付けたいと思うのですが、英語が得意というわけでもないので、
なかなかこれだっていう名前が付けられないときがたまにあって、
そういうときは大抵、辞書を引いてニュアンスとかを考えだしたりして、深みにハマります……
英語が得意じゃないプログラマーは、英語圏のプログラマーより生産性がかなり落ちるんじゃないかと 常々思うところです……

あと、これに関連してですが、
耳慣れない単語を使うと後々困ります……

単語の意味が合っているからといって耳慣れない単語を使うと、

  • 他の人がコードを把握しようとしたとき単語の意味が分からないので辞書を引かなければいけない
  • 読み方を忘れるので会話するとき困る

ので、わかりやすい名前を付けましょう!!

そしてふたつめです。

public関数に暗黙の使用条件がある

ついついやってしまうのですが、気をつけたいなと思うことです。

例えば
「ある関数Aを実行するときは、その前に別の関数Bを実行しておく必要がある」
といったことがあると思います。

もし前提条件の関数Bを実行せずに関数Aを実行してしまった場合の
エラーハンドリングがちゃんとできていれば大丈夫かとは思うのですが、
エラーハンドリングもされず、その関数やクラスのコメントにも関数Bをあらかじめ実行しておく必要があることが 書かれていない(=暗黙の条件)状態だと、
後から別の人がその関数を使ったり修正したときに不具合が発生する危険が増しますし、
コードを把握するための時間もかかってしまいます。
実装した本人でも忘れてしまいますし。

あまり関数を使うための前提条件をつくらない方がベストな気がしますが、
やむおえない場合はきちんとコメントに書いておきたいところです。

ということでみっつめ。

関係なさそうなところで影響し合っている

「ある関数の処理内容を変更したら、実は他の場所でその関数の処理内容に依存した実装があり、不具合が発生した」
というようなことがよくあるような気がします。

特に、あまり関係なさそうな処理同士が依存していると、
後から関連処理を修正するときに見逃しやすく、処理を把握するのも大変。
処理の依存関係はできるだけ小さい範囲でまとめたいところです。

まぁ、テストを書け、ということかもしれませんが、
依存関係が散らかってないコードを書ける人は尊敬します。

そしてラスト。

難解すぎて何をやってるかわからない

凝ったコードでも他の人が理解しやすいコードはいいのですが、
なにをやっているか理解しづらい難解なコードは避けたいところです。

他の人が読み解くのに時間がかかりますし、
完全に把握できていない状態で変更を加えられたり、コピペして使われたりすると危険です。

コードを短くするために凝ったコードを書くより、
ある程度長くなっても理解しやすいコードのほうが良いんじゃないかなと自分は思います。
ムダに冗長なコードは避けたいですが。

最後に

この記事を書いていて思いましたが、
不具合を生みにくいコードを書くことで、「不具合を生まない」ということだけでなく、
後々の生産性の向上にもなるような気がしました。

自分自身も、
ついついめんどくさがって、あまり後々のことを考えずに簡単に実装できるコードを書いてしまいますが、
後々のことを考えて、できるだけ不具合が生まれにくいコードを書いていきたいものです。