Java による新規開発案件

今までの仕事は, C 言語での流用開発. switch 文に条件を追加していくだけの簡単なお仕事だったので, クラス設計やソフト構造の設計などまったく関わりがなかった.

しかし, 今回の仕事は Java の新規開発案件だ. そのため, はじめの設計で保守性の高いクラス構造を決める必要がある.

はじめての OO 設計

一応 UMTP L2 の資格を持っているし, デザインパターンについてもいろいろ調べたりしてきたけれども, 実践で利用したことがないということについて,とても歯がゆい気持ちでいた.

そのため, (ついに!) 仕事でクラス図をかけたことがとてもうれしいく感じた.

みんなでいろいろと意見を言い合ってソフト構造について議論するのだが, それがとても楽しい.

『このクラスの責務は重すぎるので, この責務は別のクラスに移譲するべきだ』

『このクラスたちは疎結合にするのがよい』

チームメンバで一人, とても OOP に詳しそうな人がいて, クラスの責務に関するコメントや, デザインパターンが言葉の端々に登場する. そういう開発に少し憧れていた.

『このクラスには状態が必要. ここはステートパターンで実装したほうがいい』

『ここには, ビジターパターンのような考えが利用できる』

ずっとやりたかった, Java での新規案件だけれども, ソフト構造を決めたらあとは黙々とつくっていくことになるのだろう.

もともと, Java をはじめた理由がケントベックの TDD の本を読むためだったので, 実は TDD をしたいのだけれども, 今回の開発ではおそらく TDD はやらない.

今回の開発は, ネットワークの高速化をめざしいているため, 開発というよりも研究に近い. 動作するものを早くつくって性能を測ることが大事なので, テストは 2 の次なのだ. まずは性能を出すことが第一目標.

設計どおりにつくって高い品質を確保できたとしても, 性能がでなければなんの意味もない.まずは, 動かしてチューニングしたい.

しかし, このプロジェクトは今の時点でデスマーチな匂いがとてもする…

か弱い下請け仕事なので, 強いられた工程を死守しないといけないのだが, 結構乱暴な工程が引かれている… 今の時点で正月がない気がするのだが. 思ったように性能がでないときに, 真の地獄が待っている…

楽しさと辛さが紙一重なのだが, なんとか頑張るつもり.