omoが書いたよ

Making Bad Design Look Bad

xxx の日報に反応を書いたがねたとしてそれなりに面白い気がしたので Wiki へ.

XXX です。
* gen
  * 文章書き: Application ってクラス名は具体性が無くて良くなかった。
    「なんとかManager」っぽいダメさがある。

Application とかなんとか Manager は、名前以前に 設計がまずいことが多いです。(なんとか Context も同じ。) 依存関係の整理をさぼり、とりあえずなんでもつっこんでおく オブジェクトをつくってしまっている可能性があります。 そういうのは役割分担を考え直し、 オブジェクトやインターフェイスを分割するのが筋です。

逆に、まずい場所にまずい名前をつけておくのは悪いことではありません。 ソフトウェアの規模が小さく部分的にさぼってもインパクトが少ないなら、 そういう手抜きはトレードオフとしてありえます。

そんなときに「すまんがここはさぼった」というマークとしてまずい名前は有効です。 「間違ったコードは間違って見えるようにする」のバリエーションで、 「まずい設計はまずく見えるようにする」というかんじです。

もとねた

別に同僚を dis たりして日々を過ごしているわけではありません。 これはたまたまです。いやほんとに。 ちなみに当人からは 「ダメなとろには FIXME: マークをつける方がオシャレ」 と反応がありあした。そうかも。

表題のもとねたは Joel on Software の Making Wrong Code Look Wrong から。

前回のつづき

しまった金曜だ。森田です。こんにちは。 先週 つづく と書いたままなのを思いだし慌ててかきます。

あらすじ。再利用再利用っていうけど 再利用できるコードを書くのは大変でしくじりがちだし、 再利用できるはずのコードなのに使うのが大変だったりするよね。 どうしよう？ <- 今ここ

さてつづき。 再利用が難しい理由はいくつかあります。 その一つは、再利用を意図してコードを書くのが 本質的に投機的な面を持つからでしょう。 投機という言葉に抵抗があるなら投資と呼んでもいいけれど、 とにかく不確実な未来を相手にしています。

インターフェイスをつくるのは投機です。 あとから別の実装を作る未来に bet しています。 パラメタを外部化するのは投機です。 あとから調整する未来に bet しています。 同じコードをまとめることにすら投機的な面があります。 コピーせず一つにまとめる DRY 原則は、 コードをあとから変更する未来に bet しているのです。(他の目的もあるけどね。)

投機/投資をする以上、リターンの期待値を大きくしたいのが人情です。 そのための戦略は多く知られています。 玉石ある手口の中から、 そのなかの一つ "Rule Of Three" を紹介したいと思います。 ようやく本題です。前置きが長くて済みません。

Rule Of Three

Wikipedia には様々な Rule Of Three が紹介されています。 プログラミングにおける rule of three は こう です: 「同じコードを 3 回コピペしたらコードを関数にまとめろ」。 書籍 リファクタリング にも同じことが書いてありました。 もう少し一般化すると、 「同じようなコードを 3 回書いたら再利用に備えろ」と 言うことができそうです。

以前、私は別のところで似たような話を読んだことがあります。 フレームワークの改変戦略を議論した Evolving Frameworks という記事で、 著者らは「いつフレームワークを作るべきか」の指針として "Three Example" パターンを示しました。

Develop three applications that you believe
that the framework should help you build.
These applications should pay for their own development.

まず三度アプリを作れ、というわけです。 三度似たようなアプリケーションをつくるなかで、 ホットスポットと再利用可能な箇所の区別がついてきます。 再利用先があるという自信も持てます。 一回や二回ではそれがわからないということでしょう。

私も身に覚えがあります。 学生の時分、 自称「グラフィクスエンジン」の OpenGL/DirectX ラッパを何度書いたことでしょう。 ベクトルや行列を実装した回数や数えきれません。 空で逆行列計算のコードが書けるくらいです。(というのはブラフでかけ算くらいかな...)

はじめてウェブの仕事をした頃も、 自称 「J2EE コンテナ」の servlet ラッパを書き散らしてバイト先に多大な迷惑をかけました。(時効です。)

Rule of three に従うなら、酷いコードでもまずゲームやウェブサイトを作るべきだったのです。 そうすれば、半透明のポリゴンやフレームを含む HTML を正しく扱えない 役立たずの「フレームワーク」を実装する無駄な労力を避けられたことでしょう。

ふりだしに戻ると？

前回の話に戻ります。 再利用の成功体験を語る同僚と、 再利用の失敗体験に苦しむ私の違いは何だったのでしょうか。

話によれば、 その同僚が再利用を志したのは度重なるコードの繰り返しに飽きたからでした。 これは先の "Rule Of Three" を満たしている気がします。 二回じゃ飽きないですからね。 逆に私が苦しんだフレームワークはアプリケーションに先立って書かれたものでした。 (テストすら通っていないものもありました...)

Community Engine のミドルウェアはどうでしょうか。(ここからは宣伝なので適当に眉唾してね:D) VCE の初期バージョンは、ボスがゲーム開発をするの中でちまちま作ったものだそうです。 WS の売り文句には 「これまでにコミュニティーエンジンで培ってきたネットワークゲーム開発の知恵がこめられています」 とあります。ノウハウ培う過程で似たようなコードを書いたことでしょう。 これらも Rule Of Three を満たしていそうです。 つまり良いフレームワークなのだといえます。おひとついかがですか？

...会社 blog っぽいオチをつけてみました。ではまた。

名前の由来など

茶袋の会の元ねたには、"Brown Bag Lunch" と呼ばれているものがあります。 昼飯時に集まってグダグダ(とは限りませんが)何かやることをこう呼ぶそうです。 私は アジャイルプラクティス という本で知りました。 brown bag は昼の弁当を入れる袋を指すそうな。 (Google で "brown bag" と 画像検索してみてね 。)

残念なことに、弊社の近所で brown bag に弁当を入れてくれるのは Subway くらい。 毎週 Subway を食べるのも面倒なせいか、コンビニその他の Plastic Bag Lunch が大半。 初台近辺で茶袋をくれる、おしゃれなパン屋をご存知の方は一報ください。

Fall The Bar

茶袋の会には各人がさまざまな野心を持って臨んでいます。 (野心の例: ustream でメジャーデビュー) 私個人は、会社で思いつきや興味を話す敷居を下げられればいいなと思っています。 もちろん社内には Wiki も ML もあって、雑談をする場所が無いわけではありません。 一方で、文章を書くのはそれなりにかったるい作業です。 反応するのも面倒で、やりとりが殺伐になりがちです。 誰もが私のように図太いわけではないですから、 そうした殺伐は書き手の敷居を高めてしまうことがあります。

たとえばロボットの話や見た DVD の紹介なんてのは 画面や実物を見ながら口頭で話す方が文章を書くよりずっと簡単に説明できます。 また話の中に説明不足があっても、その場に当人がいれば会話で補うことができます。

そしてなにより、茶袋の会はグダグダです。 なにしろ聞き手はみな弁当を食べています。 会に興味のない人が画面の前を通ってコーヒーを淹れてます。 唐揚げを床に落とした悲痛な叫びが上がります。 そういう雰囲気なら、多少アホで不完全な話をしても良い気がするものです。

そうやって発言の bar を下げると、 「もう少し整理してから話そう」とか「まとめて書こう」とか 「面白い気がするけど他の人には当たり前かな」などと 思ったまま死蔵されていた知識やアイデアに 日の目を見せることができるかもしれません。 グダグダには、そんな発掘の意図がなくもないのです。

それらしい建前を書いてみました。 洋画の再放送をみながら弁当を食うのには飽きたから おまいら何か話してよ、という本音は公然の秘密です。

ではまた。

複数プロセスのデバッグ

このごろ、いわゆるネットゲーのようなものを作る仕事をしています。 ネットゲーなのでクライアントとサーバがいます。 開発中は、両方を同時に動かすことになります。

開発環境は Visual Stduio です。 Visual Studio の UI は単一のプロセス相手にデバッグする前提で設計されています。 「実行」の F5 キーで起動できるプロセスは一つだけです。 クラとサバのいるネットゲーづくりには向きません。 今まではクライアントの初期化中にバッチファイルを呼び出し、サーバを起動していました。 これだと起動は自動化されますが、サーバにデバッガがアタッチされません。 (つまりステップ実行できません。) 今日は面倒なバグを追う必要があり、仕方なくクラとサバの両方にアタッチする方法を調べてみました。

で、さすがは Microsoft。 Visual Studio には複数プロセスにアタッチできる機能がありました。 「ソリューションエクスプローラ」の GUI でコンテクストメニューからプロセスを起動すればいいんですね。 ただ GUI はいまいちです。自動化したい。 そして GUI からできる操作はほとんど自動化できるのも Visual Studio のいいところです。 さっそく操作をマクロに録音、再生してみました。

... が、なぜかダメです。マクロのコードはこんなかんじ。

' 改行とコメントは森田による
Public Module RecordingModule
   Sub TemporaryMacro()
       ' サーバのプロジェクトにフォーカスをあわせる
       DTE.Windows.Item(Constants.vsWindowKindSolutionExplorer).Activate()
       DTE.ActiveWindow.Object.GetItem("xxx\servers\game_server") \\
           .Select(vsUISelectionType.vsUISelectionTypeSelect)
       ' "新しいインスタンスをスタート"
       DTE.ExecuteCommand("ClassViewContextMenus.ClassViewProject.Debug.Startnewinstance")
       ' 同じことをクライアントにも
       DTE.ActiveWindow.Object.GetItem("xxx\client").Select(vsUISelectionType.vsUISelectionTypeSelect)
       DTE.ExecuteCommand("ClassViewContextMenus.ClassViewProject.Debug.Startnewinstance")
   End Sub
End Module

どうも "ClassViewContextMenus.ClassViewProject.Debug.Startnewinstance" コマンドは 遅延され、マクロのコードが動いた「後」に実行されるようです。 そのためか、二回続けて呼び出すとエラーになってしまいます。 最初は実行が終わる前に処理が戻るのかと思い、Sleep() してみましたが、それでもダメ。 困りました。

さて、私は非同期プログラマ(自称)です。このトラブルは非同期の臭いがします。 スクリプトが終わるまで処理が遅延されるなら、更にその「後」まで実行を遅らせたらどうなるの？

Visual Studio (2005) のマクロは .NET のランタイム上で実行されます。 .NET の機能がフルに使えるなら、処理の遅延なんてチョチョイと書けるはず。

書いてみました。

Public Module XxxDevelopment
   Sub TemporaryMacro()
       ' 1 秒後にサーバを起動するタイマーをセット
       Dim aTimer1 As System.Timers.Timer = New System.Timers.Timer(1000)
       aTimer1.Enabled = True
       aTimer1.AutoReset = False
       AddHandler aTimer1.Elapsed, AddressOf StartGameServer

       ' 2 秒後にクライアントを起動するタイマーをセット
       Dim aTimer2 As System.Timers.Timer = New System.Timers.Timer(2000)
       aTimer2.Enabled = True
       aTimer2.AutoReset = False
       AddHandler aTimer2.Elapsed, AddressOf StartClient
   End Sub

   Private Sub StartGameServer(ByVal source As Object, ByVal e As Timers.ElapsedEventArgs)
       DTE.Windows.Item(Constants.vsWindowKindSolutionExplorer).Activate()
       DTE.ActiveWindow.Object.GetItem("xxx\servers\game_server").Select(vsUISelectionType.vsUISelectionTypeSelect)
       DTE.ExecuteCommand("ClassViewContextMenus.ClassViewProject.Debug.Startnewinstance")
   End Sub

   Private Sub StartClient(ByVal source As Object, ByVal e As Timers.ElapsedEventArgs)
       DTE.Windows.Item(Constants.vsWindowKindSolutionExplorer).Activate()
       DTE.ActiveWindow.Object.GetItem("xx\client").Select(vsUISelectionType.vsUISelectionTypeSelect)
       DTE.ExecuteCommand("ClassViewContextMenus.ClassViewProject.Debug.Startnewinstance")
   End Sub
End Module

動いた! マクロ実行コンテクストが終わったあとも、 ランタイム自体は生きてるんですね。Visual Studio エライ。

というわけで、非同期プログラマもたまには世間の役に立つというお話でした。 ではまた。

あ。実行前にビルドが走るケースはうまく動かない・・・。 それはまた気が向いたら直すことにして、当面はだましだましやることにします。

追記:

慣れないとかったるい非同期プログラミングですが、 最近は (これも実行環境に制限の多い) クライアントサイドのウェブ開発で 見直されているようです。 興味のある方は for文をsetTimeoutに変換する などの記事が楽しく読めるかもしれません。