hidenorigotoの開発日誌（2）

私がカルテットコミュニケーションズに入社して半年になります。前回の開発日誌を書いてから4ヶ月経ちました。この4ヶ月での私の仕事で大きかったのは、Lisketのウリの機能の1つであるアカウントCSV作成ツールの内部処理の置き換えを行ったことです。

AccountConstructor2コンポーネントの開発

アカウントCSV作成ツールの内部処理は、私が入社する以前からAccountConstructorというコンポーネントとして開発され、かなり高機能になっていました。経緯は割愛しますが、これを新しく作り直すことにし、ベースのエンジンとして私が別途開発したHaydnを使ったAccountConstructor2を開発しました。処理の雰囲気は「Haydnを使った掛け合わせデータ生成」を参照して下さい。

入出力完全互換

この内部処理コンポーネントの置き換えでは、ごく当たり前のことですが、コンポーネントの入出力のインターフェイスを旧バージョンと完全互換にして、処理部分だけ取り替えるというアプローチをとりました。

入力は、生成するための基礎情報が1つの配列になっています。出力は、SystemOutWriterというオブジェクトを通してレスポンスがクライアントへ返されるようになっています。この入出力のセットを処理コンポーネントへ渡して処理が実行されるようになっていたため、同じインターフェイスの処理を作るのが簡単でした。

また、新旧両方の処理に対して、同じ入力から同じ出力になることを確認する自動テストなども作成し、万全を期しました。

チームメンバーによるコンポーネントの改良

現在、私とは別の開発メンバーが、アカウントCSVを異なる形式に変換するツールの開発に取り組んでいます。これはもともとLisketにある機能ですが、アカウントの構造やCSVの定義をLisket内で一元化するため、以前の開発日誌で書いたAccoutModelやAccountCsvReaderといったコンポーネントを活用したものに置き換えています。

この過程で、私が最初に開発したAccountModelやAccountCsvReaderを、別のメンバーが修正・拡張しています。これらのコンポーネントは、変換ツールの開発で利用するのですが、私が開発した別の機能（AccountCsvChecker、AccountConstructor2）からもすでに利用しています。ですので、AccountCsvReaderの修正や拡張が、AccountConstructor2に影響することがあります。こういった状況が発生するたびに、どのコンポーネントで、どのように問題を解決すべきか、という設計について話し合い、解決してきました。これによって、私が見落としていた観点で設計が改善されたと思います。

複数のコンポーネントに囲まれて、それぞれの要請を調整しながら開発するのは、前回の日誌でも書いたように結構大変なことです。それがもやもやとした雲の中で行われるのだとしたら、到底できそうにありません。しかし、明確に定義された依存先のそれぞれに自動テストがあり、変更によって依存先のどの機能がどう変わるのか、ピンポイントで見定めながら、設計の変更について検討していく。これは私にとっても、とても学びのある経験でした。一時的にでも、複数のメンバーがそれぞれの領域を持ち、領域同士で牽制しあいながら、前に進んでいく。まさにこれが設計だと思います。

何よりも嬉しいことは、私が最初に開発したコンポーネント群が、チームの別のメンバーの手によって成長しはじめたことです。一方で私自身は、チームのまた別のメンバーが過去に作ったインターフェイスを利用して、上手く仕事をこなせました。「忘己利他の開発」の感触を実際に得られた気がします。