今日はお休みです。
税金収めに地元に戻ってました。
暑いね。こんな暑い中歩き回ったので後で熱中症にでもならないか不安だ。

--- 久しぶりに… ---
プログラム以外のコンテンツに手を入れてみました。
アクセス解析のページに「今月の検索ワード」を追加。
トップページから「カウンタのイメージをクリック」→「これまでの経緯」で行けます。
1日1回しか更新されないので、頻繁に見ても変わりません。

いよいよウィンブルドンも佳境に入ってきた。
男女共ベスト4が出揃い、昨日は男子の準決勝。

ウィンブルドン名物といえば、雨による中断。
1時間を超える中断などザラである。

--- 伝統 ---
昨今、スポーツは商業的な要素が強くなってきた。
典型的なのがサッカーだろう。
数十億円にもなる移籍金の話が飛び交うのも、テレビ放映による莫大な放映料があるからこそ。
ロスタイムや延長を含めても、ある程度試合時間の計算が出来るところが大きい。

それに引き換えウィンブルドンはどうか。
いつ試合が中断するか判らない。ひどいときは丸一日試合が無かったりする。
これでは付いてくれるスポンサーも激減するだろう。

でも、正直そんな事観てる僕達には関係無い事。
そして、ウィンブルドンはいつも極上の試合を観せてくれる。
スポーツは商業的になり過ぎちゃいけないんだ。ウィンブルドンを観ていていつもそう思う。
100年を超える伝統があるからこそ、この大会が成り立つんだろうね。
いつまでも、このスタイルを貫いてほしい。

--- 最近のオススメ ---
以前から僕の中で夏といえばカンパリソーダ命だった訳ですが。
それに続く夏のオススメカクテルを発見した。
ココモ・ピニャ・カラーダ。
ココモ(ココナッツのリキュール)とパイナップル・ジュース、牛乳を同量シェイクして完成。

本来のピニャ・カラーダはラムとココナッツ・ミルクを使うんだけどね。
うちの近所にはココナッツ・ミルクが売ってないのだ。
ココモはラムベースのココナッツ・リキュールだから、これと牛乳を混ぜれば
ピニャ・カラーダになるという訳。
初めて自分で作って飲んだとき、思わず「うめー！」と叫んでしまったという伝説の(笑)一品です。

あぁ参った。隣の人がまた始まりました。
今度は延々とマウスのボタンをカチカチカチカチ…
もうかれこれ10分以上は続けてるぞ。

やる気無いのはいいが、周りに迷惑かけるのはやめてほしいね。
こっちのやる気まで削がれてくる。
もう帰っていいよ？

--- 冷蔵庫並 ---
この部屋は冷えすぎている。
温度設定を冷蔵庫と間違えてるんじゃないのか(笑)？

--- 保守性 ---
先月末でメンバーが大幅に抜けたので、
彼らが作っていったプログラムでも見てみることにする。
今後バグがあったら僕の方で対応していくことになるだろうからね。

なんか一つだけやけにサイズの大きいコンテンツがあったので見てみる。
…これは見なかった事に(笑)。
ふぅ、これはなかなか厄介な代物だぞ。

大量のプログラム、そして大量のSQL文、
そしていくつかのストアド・プロシージャ(以下SPと略)。
自分の持てる力を存分に発揮してるつもりかもしれないけど、
こんな複雑なプログラム組んどいて保守する人間の身にもなってくれ。

--- 最良の選択 ---
システムを作る上で、いくつか考慮に入れるべき点がある。
その中で僕が最も重要視しているのが、プログラムの保守性。
これを何より優先して考える。
それは、プログラムが見やすい事。そしてコード量が少ない事。
そして何よりシンプルな事。

プログラムが完成した後、処理速度が必要な部分があればそれを修正していく。
満足のいく処理速度が実現できている場合、
このプログラムに手を入れる必要はどこにも無い。

コード量を3割増やして得られた結果、
処理速度が1.1秒から1.0秒に上がっただけだったら
果たしてその修正は本当に必要だったのだろうか。
ただ単にプログラムを汚くしてしまっただけかもしれない。

--- オブジェクト指向 ---
Javaは言うまでもなく、オブジェクト指向言語である。
SPは確かにプログラム言語だが、オブジェクト指向ではない。
この2つの言語の決定的な違いは何か。
それこそずばり、保守性の違いに他ならない。

オブジェクト指向言語は高い保守性を誇る。しかしSPはそうではない。
コード量が多くなればなる程、SPを保守するのに大変な労力を必要とする。
たった一箇所の修正をするのに、何時間にも及ぶ作業になることだってある。

確かにSPは、高速なDB処理をする為には必要不可欠な技術だ。
しかし、果たしてそれが本当に必要な場面がどれだけあるだろうか。
SPでなくJavaで記述すれば、処理速度は犠牲になるが
それ以外の面では圧倒的に優位な事が多い。その筆頭はもちろん保守性の高さだ。

--- 最悪の選択 ---
そして、多くの現場で見られる最悪の選択がこれだ。
「1文のSQL文で全てを済まそうとする」

SQLは読んで字の如く「文」だ。言語ではない。
だから、JavaよりもSPよりも保守性が低い。
誰が他人の書いた200行を超える(単一の)SQL文を修正する気になるのだろうか。
こんなのはもはや自己満足以外の何物でもない。
大抵の場合、こんな大層なSQL文を書いたところで大した速度は得られない。
それだったらシンプルなSQL文とシンプルなJavaロジックの2段構えで構成した方が
よっぽど良い選択という事だ。

速度を上げる為にSQL文発行回数を減らすという発想は正しい。
しかし、それによってどれだけの効能が上がるかをまず考えて欲しい。
多大な苦労をしてまで複雑なSQL文を発行しても、
結果が伴っていなければ何にもならないからだ。

--- また引越し ---
このプロジェクトに入ってから、やたらと引越しする機会が多いような気がする。
この前この場所に引越してきたばかりなのに
今度は同ビルの別階に移動。あぁ面倒です。

連日猛暑です。
こう暑い日が続くと肉体的にも精神的にも参ってくるね。

--- まだまだ続きます… ---
隣の人の破天荒ぶりはまだまだ止むことを知らない。
今週から引越してきたフロアは別部署の人もいるから、
通常勤務時間帯は物を食べたりするのは厳禁(飲むのはOK)なんだけど
この人はそんな事お構い無しでバリバリボリボリ。
いくら敷居に囲われた空間だとはいえ、ちょっとどうなんでしょう？
年下だったら注意してやるとこだけどね。

--- 残業する理由 ---
先月はほぼノー残業で過ごしてきた僕ですが、
今月に入ってからは少しだけ残業をしている。
その理由は、定時の6時だとまだ外が明るいからだ(笑)。

こんな時に帰ろうもんなら暑い日射しに照らされて地獄を見るのがオチだから
いつも1時間くらい待ってから帰る。
それでもまだ7時だからね。

それにしてもSE達は暇そうだ。
設計終わったらもう何も貢献できる事が無いらしい。
こんなんで俺と同等以上の給料貰ってるとは許せんな。

少しでも開発を手伝える能力があれば良いんだけどね。
っていうか暇なんだからそれ位自主学習でもしてくれよ。
普段からプログラムやりたいとか言ってるくせにさ。
こういう類のは一生プログラムをやる事なく過ごしてくんだろうね。
向上心の無い奴らはこの業界から消え去ってほしい。

--- 携帯しない奴ら ---
この業界の奴らってのは、何故か携帯電話を「携帯」していない。
常に机の上に置いたままで平気で席を離れたりする。
あのな、そんとき携帯コールがあったときの周りの迷惑考えたことあるか？
しかもそういう奴に限って騒がしい着メロを使ってたりする。

ちなみに、以前から話題(？)になっている非常識さんも当然この部類に入る。
ふぅ、人に迷惑を掛け続けながら生活していて
平然としていられるその神経のズ太さに感心するよ。

--- オールマイティ ---
全能。世間一般的に言うオールマイティの日本語訳はこんな感じらしい。
僕がこの言葉に持つイメージは「広く浅く」。
多くの分野において、全てに秀でた物などあり得ないのが現実だからだ。

開発の世界でも同様に。
オールマイティを目指している製品がある。
これは別に悪いことではない。
一つの製品で多くの事を出来るというのは便利だし、
実際それを達成している製品も数多くある。

--- 反オールマイティ ---
が、別の意味でオールマイティを目指している製品もある。
その目的はずばり「独占」だ。
その製品さえ使っていれば、他の製品を使う必要が無い。
つまり、ユーザが他の製品を使うことを拒絶しているのだ。

Microsoftは以前からこの傾向にあることは誰もが知ってる事だとは思うが
実は僕にとってはそれ以上に厄介な存在がある。Oracleだ。

--- 代替手段 ---
Windowsを使っていても、Linux環境を再現するCygwinの存在もあるし
MeadowなどのGNU製品が多数存在するので
特に不便だと感じる事も無い。

しかし、Oracleを使っているとなかなか良い代替手段が存在しない。
現在、大半のプロジェクトでOracleが使われている実状を考えると
しょうがないのかも知れないが、これはプログラマにとって大きな弊害になる。

--- 移行の難しさ ---
開発時、全ての環境をローカルマシンで実行できる事は重要だ。
その方がデバッグの効率が格段に上がる。

しかし、Oracleをローカルマシン上で動かすのはやや困難だ。
インストールが難しいとかそういう問題ではない。
単純に、メモリ消費量が半端無くデカいのだ。
だったら他のDBを入れたらどうかという意見があるが、これも一筋縄ではいかない。
Oracleは独自性が強いので、DBの移行は手間の掛かる作業となる。

これは、OracleがDBを独占しようとしているからに他ならない。
つまり互換性の事を全く考えていない。
SQL文には共通の仕様もあるというのに、それに従うことをしない。
それどころか、OracleのツールはDBをSQL文で吐き出す事すら出来ないという有り様。
Oracle独自のダンプファイルを吐き出す仕組みになっている。

--- 複雑 ---
複雑なテーブルの初期設定なんかも嫌気がさすね。
これは一見カスタマイズが可能で便利なように思えるが、裏を返せば
Oracleは何もしてくれないという事なのだ。
「面倒な設定はユーザ側で頑張ってチューニングして下さいね」って訳だ。

そしてその面倒な設定を行うことでOracleマスターの称号を与えている。
何も知らないDB管理者はこれに喜びを感じるのだろう。
Oracle社に踊らされてるだけとも知らずに…

--- 狭い世界 ---
所詮、一つのアプリケーションを極めたところで
そのスキルはそこでしか使えないわけだから
あまりそれに固執するのは本来良い事ではない。
そこまでの時間を割いてまで価値のある事なのかを見極める必要がある。

そうじゃないと、外に出たときに全く使えない人間になっちゃうよ。
一生Oracleと心中するような狂気の持ち主なら別に構わないけど。

--- 先延ばしの結果… ---
しまった。
今日の夜って確か女子バレーじゃなかったっけ？
予定が入っていてその時間はテレビ観れない事に今気付いた。

しかもビデオは以前壊れたっきり。新しいの買いにいこうと思ってたのに
ついつい先延ばしにしてしまった。
最近は特に録画の必要無かったからね。

というわけで。誰かイタリア戦を録画する(してた)人いませんか(笑)？

ようやく雨が降る。
でもあまり涼しくない。蒸し暑い感じが嫌だよね。

--- バレー ---
昨日の第1戦が見れなかったので、今日は2戦にして初観戦。
やっぱりアテネ前の大会ってこともあって難しいんだろうね。
今日も吉原を温存して手の内を見せない戦いだった。

結果はポーランドにフルセット負け。
モチベーション的にもそんなに高くなかった感じ。
だいたい何でこんな時期にトーナメント戦やるんだろうね。
もうオリンピック始まるっていうのに。

うぉ、やばいぜ。冷蔵庫の中が満杯状態だ。
まとめて買い過ぎたか。
ドリンク類が3割くらい占めてるからこれは連日飲むしかないな(笑)。

--- 間近？ ---
もうすぐ関東でも梅雨が明けるらしい。
梅雨前からこんな暑くてどうすんのって気もするけど。

--- そろそろ… ---
仕事も暇になってきた。
なんかやる事見つけないとなぁ。
今いち興味をそそられる技術が見当たらないのだ。
JDK5は手を付けるにはまだ早い気もするし。

なんかネタでも無いかなぁと思い、探したのがこれ。
Javaソースからバグパターンを検知するツールだ。
Eclipseのプラグインにもなってるので使ってみることにする。

まずは簡単なプロジェクトにチェックを掛けてみる。
大方の予想通り、大量のバグパターンが報告された。
なかなか使えるね、これは。
プロジェクトが大きくなればなる程、
未然にバグを防ぐという事は非常に重要だからね。
今度まとめてプログラムページで公表する予定です。

--- 再びバリバリ… ---
はい、隣でせんべい割ってます(笑)。
と思ったら今度は遅刻王からのバグ報告だ。
なんでこいつは話すときこんなに顔近づけるんだ。気色悪いんで止めてくれ。

今月いっぱいで一人抜けるので、補充メンバーを面接するらしい。
技術もそうだけど、それよりもまず通常の人格を持った人間を採用してほしいよ。
まぁ採用決める人間がアレじゃあ、どうしようも無い気もするけど。

あ?、何だってここの営業はクズみてぇな奴ばっかなんだ。
ただでさえモチベーション下がってるんだから俺の前に姿を現さないでくれ。
即刻帰りたい気持ちで一杯だ。

技術者のモチベーションを上げてくのもお前らの仕事だろ。
それが逆に下げさせてどうするんだ。
そんなんだから社内の技術者はロクでもない奴ばっかりなんだろうな。
こんな奴の下で働いてりゃそうなるのも仕方無いよ、実際。

--- 強敵だらけ ---
バン！と突然大きな音。
どうやら隣のヒジョーさん(←たった今命名)が机の上にいる虫を始末した音らしい。
どんな理由であれ、机ぶっ叩くのは止めようよ。
みんな作業してるんだからさぁ。

地獄のような暑さの中出勤。
仕事場に着いて1分も経てば、頭痛がするほどの寒さに襲われる。
冷やし過ぎです…

--- ピッタリ ---
明日からは3連休。
それに合わせたかのように、全英オープンが始まっている。
これで最終日(月曜の朝)までバッチリ観戦できるって訳だ。
丸山は初日を終えてUnder Parの40位。まだまだこれからだね。

仕事場来たのはいいが、こう暑いと思考が働かない。
こう毎日毎日だとさすがに参る。たまには涼しい日がないとねぇ。

--- 2日 ---
今月は前半頑張ったおかげで、あと2日休むことが出来そうだ。
今週来週と1日ずつ取るのが妥当かな。
週の間に取るのもいいけど、やっぱここは金曜に休んで3連休×3といくのが吉とみた。
ホント、こんな事考えてないと仕事続かないね。

--- グッドタイミング？ ---
などと考えていたら、すっかり忘れていた。
今週から新コンテンツ開発の作業があるんだった。
設計レビューがあったので適当に参加。
見積りはおよそ14日。まぁまぁやりごたえはありそうだ。

とはいっても休みはきちっと取るよ。
基準時間超えてまでこの現場に貢献するような気持ちは
もうこれっぽっちも残っちゃいないからね。

今日は最高気温が昨日より3度ほど低いそうです。
でも36度です(笑)。
まったくこの暑さはおかしいね。どうりで昨日は仕事場が涼し過ぎなかった訳だ。
今日はまた冷え冷えとした空間が僕を待っています。

--- 開発工程について考える ---
あ?あ、朝から俺は何をやっているんだ(笑)。
とあるサイトを読む。
昨日あたりリンクに追加したので暇な方は見るといいかも。ただし上級者向。

--- システムが出来るまで ---
日本では当たり前のように行なわれている、システムの「発注」。
システムを使う企業が、開発をする会社に
「これこれこんなシステムを作るんで、お前らちょっくら作ってみろ」
やや乱暴な言い方ではあるが、実際こんな感じである。

アメリカでは、システムを使う企業が開発者を内部に引き込んで進めることが多いという。
誰がどう見たって、この方が合理的な手法ではないか。

外部発注には多大なロスが発生する。
発注側だってコストが掛かるし、
開発側は仕様がはっきりしないまま開発を続けるので作業がはかどらない。
そして最終的な納品物は、ほとんどの場合相当質が悪い。

--- 距離 ---
そろそろ、時代も動く頃ではないだろうか。
莫大な資金を掛けてシステム開発をしている事に疑問を感じる企業が出てくるはずだ。
これを解決するにはどうするべきか。
まず、発注側と開発側の距離を縮める事が最優先だ。

従来では、明らかに発注側は上から開発を見下ろしていた。
奴らには金を支払っているのは俺達なんだから当然だろ、という意見があるかもしれない。
しかしこれは相当な時代錯誤だ。
そういった態度で接していて、果たして自分達が求めるシステムが完成するだろうか。

意思の疎通、開発者のモチベーション、様々な面で
発注側と開発側はお互い助け合うことが必要だ。
なぜなら、システムを作るのも使うのも「人間」なのだから、

--- モデル ---
両者の距離が縮まったとして、次に考えるべき大きな問題がある。
今までも度々話に出ているが、開発工程の改善である。
もうそろそろこれを認識する企業があってもいいだろう。
従来の「要件定義」「設計」「開発」「テスト」という工程が最悪の開発モデルだという事を。

この悪しき工程を非効率だと認識できないのは、
正しい開発工程がいかに優れているかを知らないからに他ならない。
本来、開発はスケジュール通りに進められるべきものである。
しかし、これが守られている現場を僕は見たことが無い。

これが達成されない原因は大きく二つある。
一つは、発注側の不備。もう一つは純粋に開発の遅れだ。
前者は「両者の距離」が関係してくるし、後者は「開発工程」が関係してくる。
つまり、これがどちらも揃っている現場は皆無に等しいという訳だ。

--- 勉強せよ ---
これらの問題は、既に海外では当たり前の事として認知されている。
例えば、とある研究によれば
「要求仕様の40％は、開発工程に入るまで明らかにならなかった」そうだ。
これは8000以上の大規模プロジェクトで調査された結果という事で
非常に信憑性が高いものである。

これを見れば、前述した「要件定義→設計→開発」の流れは間違っている事が明白だ。
開発の段階になって、仕様に40％以上の漏れがあったら
現在のSE達は何を思うだろうか。
おそらく「要件定義や設計が甘かった」と考えるだろう。
しかしそれは違う。「それがシステム開発の実際なのだ」という理解が必要である。

要件定義や設計段階で全ての仕様を決定する事など事実上不可能だという事を知っておく。
これが、システム開発をする上で重要だ。

--- システムを理解するには ---
ではなぜ40％もの漏れが発生してしまうのだろうか。
それは実際に開発をしてみればすぐに判る。
いくら紙の上でシステムを構築しても、
それで実際のイメージと完全に一致する事などあり得ないからだ。
ユーザは実際に出来たシステムを動かしてみて、初めてそのシステムを理解する。

「実際にシステムを構築しない限り、自分たちのシステムでも理解することは絶対にできない」

前にも確か話したことのある、「アジャイル」という開発スタイルの基本概念だ。
この概念は、実際のシステム開発の特性をよく表している。
だから、アジャイルでは設計を完全に決める前にコーディングを始める。
もしくはプロトタイプのようなものを作る。
Webアプリならば、HTMLだけで簡単に作ってみる。
これにより、ユーザは実際のシステムをより良く理解できる事となる。

--- その為に必要な事 ---
さて、最後の関門がやって参りました。
それを実現できるかどうかはこれに掛かっています。
もうお判りですね？
そう、この開発工程を実現するには
プログラマのスキルが重要なファクター(要素)となってきます。

それは何故か。
プログラム経験のある方ならお判りでしょう。
仕様が不確定のままコーディングをする事の難しさを。

--- 常に仕様変更 ---
仕様がほぼ確定した段階でコーディングを開始するのは、一番理にかなっています。
まずプログラムを完成させ、そこからバグを潰していく。
バグが無くなればテストは完了です。

一方、物事があまり決まっていない段階でコーディングをするとどうなるでしょう。
まずプログラムを完成させます。この段階でバグはありませんでした。
その後次々と仕様が固まっていきました。
その度にプログラムを修正し、再度テストをします。
仕様を追加・修正する度にプログラムは汚れていきます。
そしてバグの混入する確率も高くなっていきます。

--- 理想と現実 ---
もちろん、理想は前者です。
仕様が固まった状態でコーディングする方が効率的だからです。
しかし、現実はそうではありません。
仕様は完成したと思っていても、次々と仕様は変更されるでしょう。
何故なら先程も言ったように、開発を始める段階では仕様の多くが抜け落ちているからです。
もしくは、実際にシステムを使っていくうちにユーザから「要望」が出てくるのは
当然のことと言えるでしょう。

結局、最初から後者の方法を取る方が良いのです。
これならば仕様変更は当たり前という認識で作業するので
いかなる機能追加・修正にも柔軟に対応できます。

--- リファクタリング ---
ただし、ここが最大の鬼門です。
これを実現するために、プログラマがやらなければいけない事があります。
それが「リファクタリング」です。
通常、プログラムは修正を繰り返すと「汚れて」いきます。
それを綺麗にするのがリファクタリングの目的です。

リファクタリングには相当のコーディング技術と
それなりの開発時間が必要となります。
実際の現場でこれを実現する事は、かなり難しいのが現状です。

しかし、これを実現しなければ効率的な開発というのはあり得ません。
仮にもプロとしてやっていくならば、
これくらいの事を達成できないのは恥ずべきことだと考えるべきです。
事実、海外の企業ではとっくにこれらを実践している企業も数多くいます。

--- 将来の為に ---
将来、この業界で生き残っていく為にはこれらの技術は最低限必要だ。
ISOやなんかの資格を持っていても駄目だ。
そんな事は、実際にこれらの資格を持っている現場で働いてみればすぐに判ることだ。
結局これらの企業は、資格に踊らされている。
その資格に食い付くような愚かな発注元しか相手にしないのならば問題は無いかもしれないが。

一部の腐った大企業ならともかく、一般の企業はそんな目に見えないものに
大金を支払うような真似はしないはずだ。
納期を守れたか、ユーザの希望を取り入れたシステムを作り上げたか。
明らかに形になるような判断材料が山ほどあるのだから。

--- 実践投入 ---
今はなかなかに忙しいのです。
午前中は長文の日記を書き上げ(笑)、午後は本業であるコンテンツ開発を進める。

このコンテンツ製作にあたって、僕は最大のテーマを決めた。
それは先程話した「リファクタリング」を実践で使ってみる事。
今まで、頭では判っていてもこの作業を実践に取り入れる事は無かった。
それには膨大なテストをする必要があるからだ。

--- テストの重要性 ---
リファクタリングをして動作がおかしくなってしまっては何にもならない。
それを保証するのがテストなのだが、Webアプリのテストというのはとにかく厄介だ。
だから、多くの現場ではリファクタリングどころか
単体テストさえ行われていないのが実状だ。

実際に画面(ブラウザ)からボタンを押していってテストをするというのは
リファクタリングの際に行うテストとしては全く使いものにならない。
テストは自動化されるべきだからだ。
たった1行のコードを追加しただけで全てのテストを手動でやり直す気に誰がなるだろうか？

僕が目を付けたのは、JUnitをベースにしている
WebアプリケーションテストフレームワークのCactus。jakarta製だ。
そして、それをStruts用に少しだけ拡張したStrutsTestCase。
これが上手く使えれば、Strutsアプリケーションのテストを自動化できる。
結果は如何に…

--- スヤスヤ… ---
はい、隣の人はただ今爆睡中です(笑)。
僕が直接注意するのもアレなんで、昨日会社の人に伝えておいた。
このままじゃさすがにマズいだろって事で。

--- 本当ですか？ ---
明日からはまた「通常」の暑さに戻るらしい。
あんまり天気予報を信頼したくないけど、今回ばかりは信じたいね。
涼しい夜が過ごせますように。

なんか最近急に意欲が湧いてきた。
もちろん現場の仕事とは無関係だけど(笑)。
ただ、全く関係が無いわけじゃないからね。

プログラマとして最初のステップは、プログラムを組む事だ。
まず、どんな形でもいいから動くプログラムを作る。

次に向かうのは、効率の良いコードを書く事だ。
プログラマというのは繰り返し作業を嫌う。
繰り返し作業というのは単調だし、何よりミスを伴う。
得てして手動による繰り返し作業はバグの発生源となるのだ。

--- さらなるステップ ---
さらにステップアップするために、僕は次へ進むことにした。
それは、バグを発生させにくいプログラムを書く事。
この為にいくつかのツールを用意した。

FindBugs、そしてメトリクス測定だ。
前者は一般的なバグパターンの検出。後者はプログラムの「複雑度」を測定する。
もっと厳密にやるなら、CheckStyleなどのコーディングスタイルチェックも必要だろう。

--- メトリクス ---
僕が今一番注目しているのがこれ。
具体的には、クラスやメソッド毎の行数やパラメータ数などをカウントする。
これがいかに重要であるかは、中級者以上のプログラマならば重々承知のことだと思う。

複雑なプログラムというのは、全ての面において不利である。
僕は常日頃からシンプルなプログラムを心掛けているが、
それを計量するという考えは無かった。
しかし、メトリクス測定を用いればこれを数値により具体化できる。

一般的に、単一のクラスやメソッドに含まれる行数が多いほど保守は大変になる。
従って、これらを複数に分割する事を考える。
これによってプログラムの複雑度は減り、保守がし易くなる。
しかしこの作業は骨が折れるし、時間も掛かる。

今回、1000行ほどのクラスをリファクタリングしたところ
3つほどのクラスに分かれたが、この作業に約3時間を費やした。
納期に終われている現場なら、とてもじゃないがそんな暇は無いだろう。

--- 推測するな、計測せよ ---
なぜこんなにも時間が掛かったのか。
それは、プログラムを作り始めるときからこの作業をしなかったからだ。

リファクタリングというのは、日常的に実行して初めて意味を為す。
ある程度まとまったところでやろうとするのが一般の考えだと思うが、
実際に作業をすればそれはすぐに誤った認識だと理解するに違いない。

プログラマは「感覚」だけで行動してはいけない。
もちろん、時にそれは優れた結果を生むかもしれないが
多くの場合、感覚よりも「理論」を持って行動する事が必要だ。
そして一度実践すれば、それはより確かな感覚となって自分の脳に焼き付けられるだろう。

--- 一番の早道 ---
常にリファクタリングをし、的確なコメントを記述する。
システム完成までの道程を考えれば、これが一番の早道となるのだ。
プログラミングに掛ける時間を短くしようとするのは、時に致命傷となり得る。
なぜなら、それによってデバッグに掛かる時間が大幅に増加するからだ。

コーディング、テスト、デバッグ。
下手なコーディングをしていると、これらの割合が 1:1:20 なんて事にもなりかねない。
コーディングに掛ける時間を倍にするだけで、これを 2:1:5 に出来るかもしれない。

--- 連休続き ---
さて、今月は勤務時間が余ってるので明日はお休みです。
このままいけば来週も金曜は休めそうな感じ。

まぁ別に家にいたって大してする事もないんだけど、
かといって現場に行ってしまうと仕事の密度が薄くなるから
出来る限り休みをはさんで行った方がいい。
そうしないとすぐに暇になるのは目に見えてるからね。

今日は久しぶりに雨。
これで少しは涼しくなればいいけど、
電車の中はかえって暑かったりするから困ったもんだ。

--- 不備続出 ---
新コンテンツの開発を進めている。
が、不備が多すぎて少々やる気が失せる。
本来SEが用意するはずだったマスタデータもまだ出来ていない。
こんなの待ってたら何日掛かるか判らんのでこっちで作ることにする。
あ?あ、面倒だぜ…

--- 選択ミス ---
このプロジェクトは、JBoss + Tomcat という形式で開発を続けている。
が、JBossといってもEJBはほとんど使っていない。
何の為にJBossを使ってるのかというと、分散処理を行いたいからだという。
もともとH社が作ったプロトタイプなのだが、
分散処理など今現在使われていない。そして今後も使われることはないだろう。

初めからTomcat単体のプロジェクトとして開発していたら
どれほどの工数を節約できただろう。
僕の体感では、EJBを全く使わないプロジェクトでJBossとTomcatを比較した場合
前者の開発には後者の約2倍の工数が掛かる。
JBossプロジェクトというのは開発・デバッグがしにくい。しかもメモリも食う。

もっとも、ほとんどEJBを使っていないという事は
Tomcatへの移行も比較的簡単に出来るという事だ。
僕はこの前この作業をしたので、今は開発をTomcat単体で行っている。
が、結局サーバに上げる際にはJBoss仕様にする必要があるのでやはり面倒だ。
最初の選択ミスが、プロジェクト全体の進捗を狂わせる大失敗だった事を奴らは知っているのか。

むむむ…どうやら検索文字列検出プログラムがうまく動いていなかったようで
しばらく「今月の検索ワード」が更新されてなかった様子。

refererから文字エンコーディング名を取得する処理があるのだが、
ここで「S-JIS」とかいうエンコーディング名を指定してきた奴がいる。
いい加減な略語使わないでくれよぉ。ちなみに、正式には「Shift_JIS」だ。

なんか台風が近づいてるみたい。
今日は帰りにどしゃ降り。珍しく残業したのが災いしたか。
とはいっても、明日はまた休み。
今日残業したおかげでちょうど1日休める時間が余ったのだ。
金曜日は現場の人が辞めるから送別会やるらしい。

--- 業務過多 ---
なんか最近急にやる事が増えてきた。
新コンテンツの開発だけならまだしも、
ちょこまかとした依頼が続々。
現場には他に出来るプログラマがいないから結局僕が引き受ける事になってしまう。

今日のも本当は別の人がやってたんだけど、
いつまで経っても解決しないので僕がやる羽目になってしまった。

プログラマにとって一番苦しい時、それは解決しない事態に見舞われた時。
どうやって解決して良いのか解らない時だってたまにはある。
が、それを乗り越えていくことで技術者は強くなる。

プログラムなんて、所詮人間が書いたコードを寸分違わず実行しているだけ。
この気持ちを持つことが大切。
コンピュータに振り回されてどうする。解決策は、必ず人間の力で見出せるさ。

--- 大丈夫？ ---
近頃何かと話題(？)のヒジョーさん。
今度はキャッシュカードを無くしたようだ。
…っていうか大丈夫か？朝からカード会社と電話のやりとりをしている。
それにしても声デカいんで疲れる。私用は外で済ませてくれよ。

午後からはまたいつものように携帯メールモード。
今日は長かったな?。軽く25分はメール打ちっぱなし。
しかも定時過ぎてるのに。さっさと帰れば？

--- どっちが良い？ ---
先々週までの反省を踏まえて、先週から酒を少し断っている。
週7日だったのを週3日に減らした程度だけど。
僕の場合、酒飲まないと寝る時間が1時間半以上遅くなってしまう。
だから、飲んでる方が朝の目覚めはいいんだよね。

まぁどっちが良いかっていったら微妙なところ。
飲んでると結局カロリー取り過ぎるからね。食生活も狂ってくるし。

…ここまで読んで気付いたあなたはかなりの通。
そう、明日は休みなので今日はアルコール漬けなのです(笑)。
それにしても最近みんな元気かな。ネットにも顔出してくれないんで安否が心配。

おぉおぉ、今日はすごい雨らしい。
僕はなんてツイてるんだろう。こんな日に偶然休みをとっているなんて(笑)。

--- 1→2の法則 ---
僕の場合、1日休みを取ると飲む日が倍になる。
例えば今回の場合、木曜に休んだので水、木と飲んでしまう。
前者は「明日休めるから飲むかぁ」、後者は「今日遅く起きたから飲まないと寝れないなぁ」。
そんな感じです。

今日は壊れてたビデオを直した。
といっても無理やりテープ引っぱり出しただけだけど(笑)。
まだ何とか使えそうだけど、アテネの最中にイカれたら最悪なので
それまでには買い換えたいなぁ…