タグ

設計に関するn_isamのブックマーク (5)

  • オンラインゲームを「オカンでも説明無しで楽しめる」ように作るためにすべきこと

    最大のゲーム開発者向けカンファレンス「CEDEC2011」でDropwaveの城氏によって「ネットワークゲーム時代に求められる、ゲームプランナーの基礎知識」と題した講演が行われました。 「まずは自ら課金して廃人になるまでやりこむべし!」ということで、顧客生涯価値(LTV)の最大化を目的としたオンラインゲームの設計、開発および運用法について、城氏自身の制作経験を踏まえて、講演というレベルを超えて微に入り細に入り赤裸々に経営哲学や制作理念が語られました。 城: 公演の趣旨を説明させていただきます。コンシューマゲームの開発者の視点から、オンラインゲームの開発、運営について話したいと思っております。 公演の対象者ですが、何年も家庭用ゲームソフトを作ってきてゲーム作りには自信があるのに、会社の命令で無料ゲームを作れといきなり言われて非常に困っていて、いやいやながら作らなくてはならない方

    オンラインゲームを「オカンでも説明無しで楽しめる」ように作るためにすべきこと
  • SEとPG vs プログラマ2人 - ITコンサルの日常

    階段状になってるスケジュールをぼーっと見てたら、このネタを思い付いた。 前提 SE: 設計はするが、コードは書かない人。 PG: コード(だけ)を書く人。 プログラマ: 設計も実装もする人 既に稼働中のシステムがあり、変更案件やバグが課題として一覧管理されている。 あるリリース(xxリリースとする)では、変更Aと、バグBの課題を改修し、リリースしようとしている。 各課題に対しては、設計/実装/テストの作業が必要である。(レビューとか、リリース作業とかは省略) 各作業に対しては、1週間かかるという見積りが出ているとする。 お題 このときのスケジュールを書け。 SEとPGが1人ずついる場合 工程ごとに分担するので、中項目は工程になる。(垂直分割) PGは、SEの設計が終わらないと何も出来ないので、1週間アイドル状態になる。 SEは、PGが誤解しないよう、細心の注意を払って設計書を書く必要がある

    SEとPG vs プログラマ2人 - ITコンサルの日常
  • staticおじさん達に伝えたい、手続き指向とオブジェクト指向の再利用の考え方の違いについて - 達人プログラマーを目指して

    何が良いプログラムかという点はもちろん人やコンテキストによって異なりますが、少なくともプログラマーとしての私の信念としては、 機能拡張や変更が容易なプログラム 単体試験によって正しく動作することの検証が容易なプログラム どういった内容が記述されているか理解しやすいプログラム といったものこそ、「品質の高い」プログラムが持つべき性質として、まず真っ先に挙げるべき事項であると考えています。もちろん、前提として顧客の要件に従うということは大切なことです。しかし、一般に要件は長期にわたって変更されるものですし、使い捨てのプログラムを除けば、プログラムを長期にわたって保守するコストという点も見過ごすべきではありません。したがって、ユーザーの目には触れない上記の性質をもっと重視すべきだと思うのです。 DRYの原理 上記のような性質を満たすプログラムを作る上で大切になってくる原理として、DRYの原理とい

    staticおじさん達に伝えたい、手続き指向とオブジェクト指向の再利用の考え方の違いについて - 達人プログラマーを目指して
  • 人間のために分かりやすい実用的なURLを設計する方法

    URL Design [ad#ad-2] 下記は各ポイントを意訳したものです。 はじめに URLを設計する理由 トップレベルのセクションは重要 URL構造を増強する方法 クエリの文字列 URLにはASCIIを URLは検索エンジンのためにではない URLは合意 全てがURLを持っているべき リンクはリンクらしく 再利用できないURL 素晴らしいURLの例 おわりに はじめに あなたは、URLの構造を設計するのに時間をかけるべきです。この記事を読んだ後で、あなたに一つだけ覚えておいてほしいことは、URLの構造を設計するのに時間をかける、ということです。 URLデザインは簡単ではなく、正しい解決方法があると言うことはできません。しかしそれは、他のデザインと同じです。良いURLデザインがあり、良くないURLデザインがあり、そしてその中間もあります。 しかし、それは素晴らしいURLデザインを作るこ

  • プログラミングと設計は本来切り離せないものなのでは - 達人プログラマーを目指して

    最近はアーキテクトという役割で客先に常駐し、フレームワークの選定をしたり、事前に共通部品を設計したりする役割を担う仕事を引き受けることが結構あります。そこで運よくお客様のマネージャーがオブジェクト指向開発の経験が十分にある方だと、IDEなどの開発環境やインターネット接続環境を当然のように用意してくれるので最初から仕事がスムーズにできるのですが、そうでないとMS Officeしか入っていないロースペックのノートPCを渡されて、要件定義フェーズの期間中、フレームワークの設計をお願いしますとか、私としてはちょっと首をかしげてしまうような困ったことを言われてしまう場合があります。開発フェーズが始まる半年後まではコーディングは基的に不要という考え方です。アプリケーションのアーキテクトという役割では少なくともコーディング規約を考えたり、ツールやフレームワークの選定をしたりする必要がありますし、プロジ

    プログラミングと設計は本来切り離せないものなのでは - 達人プログラマーを目指して
  • 1