効率的な開発環境のための改善方法

アメリカの犯罪学者ジェイムス・ウィルソンとジョン・ケリングは、1982年に割れ窓理論（われまどりろん、英：Broken Windows Theory）を発表しました。この理論のポイントである「建物の窓が壊れているのを放置すると、誰も注意を払っていないという象徴になり、やがて他の窓も全て壊される」との考え方からこの名があります。この理論は開発者の世界でも全く同じように適用されます。ようするに、割れ窓みたいな一部の“悪いコード”により、開発中のコード全体が社会の無秩序よりもっと大変な“コードの無秩序”に陥るためです。

開発者の現実はまさにアイロニーです。開発する時間は足りないし、開発のフローもまだ理解できていない状態で新しい機能を追加しなければなりません。開発者は設計に関して真剣に考えずに作業に入るため、ただ画面上でうまく動いている結果だけに満足して、その結果めちゃくちゃな可能性が高いコードがリリースされてしまいます。

しかし、大変な問題はその後から発生します。再度、新規機能が要求されますが、既存のめちゃくちゃなコードのせいで開発スピードが目に見えるくらい遅くなります。このような状況で開発者にはプレッシャーが与えられて、その結果コードの上に同じコードを入れてしまい二重で実行されるような事態が発生します。また、新しく参加をした開発者の場合は、変数や関数の意味を知らないなどコードの全般的な理解が足りない状況から、また新しい機能を追加しなければならない悪循環に陥ることになります。

これはプログラミングをする開発者にはしばしば発生する例で、この問題を改善するための多様な一般論が提示されており、実際に多くの開発担当者らが自身の作業に適用させてきています。
Flashを開発している私たちのチームも、このような状況にしばしば直面していました。その問題を改善するために、いくつかのサンプルをFlashの環境に合うように変更して実務に適用することで、相当な作業時間の短縮と業務効率の向上を実現できました。

以下は、広く知られた一般論とともに私たちのチームがどうやってその内容を実務に適用させたのかに関する内容です。

(1) 事前設計

開発に入る前に、スケジュールのチェックとフローチャートの作成、コンテンツの主な機能の要約、開発リリースノートなどを制作します。すなわち、コンテンツの全体的な流れのチェックとリリース後に起きるアップデートのための事前準備をするということです。このためにはあらかじめ決まったチーム内のルールを使用するのが大事です。そして、そのルールに合わせて作られた設計書又はリリースノートは、以後に制作されるアップデートの時に確認しても、その流れが分析できるほどにしなければなりません。

私たちのチームの場合、先ずは「Flash Process Form」を作って、Flashのバージョンや外部連動などFlashの基本的な項目や、構成や仕様書の内容を確かに確認したのかの証明として、自己判断結果の記録を残します。

その次は「フローチャート」を作って、コンテンツ全体の流れを分析して視覚化します。この時にスケジュール内に実現できる部分とできない部分、内部クラスで解決できる部分とできない部分を判別して、できない部分に関しては代替手段を考えます。

もし、既存コンテンツの機能追加などの更新作業なら、既存の開発リリースノートを参考にして、今回追加される新しい内容を追記します。

(2) リファクタリング

リファクタリング（refactoring）とは、「コンピュータプログラミングにおいて、プログラムの外部から見た動作を変えずにソースコードの内部構造を整理すること」（Wikipediaより引用）です。可読性が高まるので、維持補修が楽になります。

たとえば、大きいプロジェクトでチームのメンバーが振り分けて作業をしたり、何回かのアップデートを重ねたりすると、コードが汚らしくなる場合があります。

この場合、コードの構造的な差を除いては同じパターンの方式で（変数、関数、クラス名の統一など）修正するリファクタリング作業が必要になります。

私たちのチームでは以下のようないくつかのルールを用意して、できる限りこのルールを守って書くようにしています。

1. 誰が見ても理解しやすいネーミングをしましょう。外部画像をロードする関数名を「im_ldr」にした場合、作った自身は理解できますが、他の制作者が又は半年後の自身がコードを見た場合にも同じように意味が伝わるのかを考えたら、やっぱり、「image_loader」などの名前が分かりやすいと思います。
2. 動作チェックのため作ったコードはコメントアウトか削除して混乱させないようにしましょう。関数のコメントとしてはただの関数名を書くよりはその関数を作った目的を書いた方がもっと分かりやすくなると思います。
3. クラスの中に条件分岐をする部分が多くて、可読性が落ちる場合には下層クラスに分けて内容を見やすくしましょう。
4. よく使うものに関しては、コード作成ルールを内部でデータベース化しましょう。以下はデータベース化にされた内容のうち、処理速度に関するサンプルです。
   例）「Math.ceil」や「Math.floor」よりも「int」は処理が速い
   「Math.ceil(4.5)」より「int(4.5) + 1」（テストの結果、約10倍速い）

もちろん、プロジェクトのコードが簡単だったり、制作期間が足りなかったり、これ以上アップデートがなかったりするなど、効率性を向上させるための方法がむしろ効率性を低下させる時は、こういう過程は省略しています。

(3) デバッグ

このようにリファクタリングまで終わった結果が初期設計段階の予想結果と一貫性（consistency）を維持することが一番重要です。すなわちプロジェクト全体が予想通りにうまく動くのか、正しい結果を見せるのか、一つ一つのモジュールには問題が発生しないのかを確認する必要があります。このためにデバッグが必要です。

デバッグとは「コンピュータプログラムや電気機器中のバグ・欠陥を発見および修正し、動作を仕様通りのものとするための作業」（Wikipediaより引用）です。

もし、会社でデバッグ用のフローが別に用意されたとしても、チーム内には開発者用のデバッグフローを別に作って、パターン毎にまとめてデータベース化（このデータベースはリファクタリングで使用されたコード生成ルールのデータベースと一緒です。すなわち、制作する時に気を付ける部分がデバッグする時も気を付ける部分になります）する必要があります。

会社から用意されたデバッグ用のフローは一つのチームのためではなく、あくまでも一般的な検品のためのフローであるためです。したがって、しばしばあるバグや、基本的なチェック項目をチーム内部に用意しておく必要があります。

私たちのチームも内部デバッグの重要性を感じて、その内容をデータベース化して残しています。

例えば“外部画像との連動”のチェックなら

1. 画像のパスはチェックしているか
2. ロードのプロセスをチェックするか
3. ロード完了をチェックするか
4. 画像のロードが終わってから、次のアクションを実行するようになっているか
5. エラーの処理はあるか
6. 処理後にメモリーが残っている要素は解除しているか

まとめられたデータベースと初期設計段階の記録をベースにしてデバッグを進行し、問題が起きると修正してもう一度チェックする過程を繰り返します。

時々、サーバーサイドスクリプト（ColdFusion、ASP、PHPなど）とFlashを連動させてサーバー上にアップロードし、ウェブでリアルタイムにデバッグをする場合があります。
この場合は、Trace機能を担当するAIRアプリを開発してデバッグができるようにしています。

それから、もう一つの重要なポイントはリファクタリングをしながら同時にコードのレファランスを作成することです。これは、後でこのプロジェクトのアップデートを担当する開発者が参考にできる資料になると思います。

最後に

このような過程を経ることで作られた内容は、事前設計及び再度の内容確認で、開発者とクライアントとの意見の差を減らすことが出来ます。また、リリース後に起こる問題への対応に必要な業務明細としても重要な確認資料となると同時に、コンテンツ更新の時に参考にできる立派なヘルパーになると思います。