通常、私達は、チームがプログラムに手をつけ始める前に、ソフトウェア設計を決めようとする。それは、簡単なブロック図であったり、 UML であったりするかもしれない。多くのプログラマが迅速な開発のためにあなたのチームに集まり始める。あなたがしなければならないことは、ソフトウェア設計である。それのために、あなたは、ソフトウェアをモジュールに分割する。それは、プログラムのための分割設計である。
しかし、あなたの任務は、各プログラマがプログラミングの一部を担当可能な状態を作り上げることである。あなたの設計は、それを実現し得るか?
プログラムの機構上妥当な分割設計と、プログラマに仕事を分けるために妥当な分割設計の間には、ちょっとした違いがある。もしあなたが自分でソフトウェアを設計してそのプログラムを書く場合は、恐らくあなたはこの事実に気づかない。
プログラム上の妥当性のために多くのモジュールに分割された理想的なソフトウェア設計は、しばしば、専門性のプログラマの仕事を妨害する。それは、生産的な開発を始めることを不可能にする。
多くのプログラムの専門的な要素がある --- makefile、メモリ管理、リソース管理、入力装置、ハードウェア制御、コンテンツパイプライン、並列処理、シェーダ、エフェクト、パーティクル、アニメーション、グラフィック、オーディオ、立体音響、人工知能、物理学、幾何学、プロシージャル技術、スクリプト、ネットワーク、デバッグシステム、サードパーティミドルウェア等など……。
これらの専門的な要素を系統的に組み合わせることでソフトウェアを設計し得るか? ひょっとすれば、それは可能である。しかし、プログラムのために設計した理想的なソフトウェア設計は、プロジェクトに集まるプログラマにとっては悪いニュースである。ゲームシステムは、彼らの知識と彼らのコードの合成物を初期から要求する。そのため、プロジェクトは難航することになるだろう。
sunday-labの日本語訳版です。英語版のXOOPS Cube関連記事を翻訳作業中...
2008年5月12日月曜日
登録:
コメントの投稿 (Atom)
0 件のコメント:
コメントを投稿