Vineet Sinha はこの業界の様々な企業で働く中で同じような状況を見てきた。生産性の低下、誇張ではなくあまりにも保守しづらいコードベース、開発者が自分の仕事をするよりも多くの時間を打ち合わせに割いている。打ち合わせの必要性を変えることはできないだろうと思っていたが、Sinha は Java アプリケーションのモジュール化を改善することでコードベースをシンプルにすることと失われた生産性を取り戻すことができると言っている。

Sinha は Architexa 社の共同出資者でありながら CTO として開発者チームのメンタリングやプロダクトアーキテクチャのマネジメント、性能問題への対処、様々な他システムへのインテグレーションを先頭に立って行っている。彼はボストンで開催されたEclipseCon 2013においてJava 開発者とアーキテクトのための巨大なレガシー Java アプリケーションのモジュール化について非常に興味深い講演を行った。

その講演で彼はエンタープライズ開発を行っているアーキテクトに向けてレガシー Java アプリケーションのモジュール性を改善するための 4 つの手順を紹介した。

手順1. アーキテクチャマップを作る

アーキテクチャマップはプロジェクトに関するあらゆる物事を1つのページで捉えるのに重要なものだ。開発に関係したそれぞれの人がコードベースに抱く中心的な構造はそれぞれ異なっている。これは組織 (開発、QA、運用、企画)によってもそうだし、同じ組織にいる開発者の間でもそうなのだ。Sinha は 「10人の開発者にコードベースを図示させたら10通りの図ができるだろう」と述べる。続けて強調したのが「分離された開発者チームは同じ構造を別の名前で参照することができる。この混乱はチームワークを妨害する深刻な認識の相違となる可能性を秘めている」ということだ。

うまくいけば1,2時間程度の打ち合わせを1度するだけでアーキテクチャマップのベースラインを作るプロセスは完了できるだろう。小さなチームだったら中心的な開発者が自分のためのアーキテクチャマップを描き始めるだろう。そしてそれは開発者同士がどう変更するのかを議論するための開始点となるだろう。大きな組織ではすべてのステークホルダーに分かるようにすることが重要だ。Sinha はすべてのチームリーダーを同じ部屋に集めることを勧めている。彼はこう述べた。「皆が知っている実態を描きだそう。主要な物事を1枚の紙に描き下すんだ。」

手順2. アーキテクチャマップをマージする

開発者たちやチームリーダーのそれぞれがどういうふうにコードを見ているのかを描き出したら、それらを擦り合せた包括的な絵を作ることができるようになる。 成功する近代化されたプロジェクトには単一のすべてのステークホルダーにとって共通のものとなる見つけやすいドキュメントとして、現在のアーキテクチャを俯瞰的に捉える絵が必要なのだ。この地図は関係者らが成すべき事について論争ではなく協調的な対話をもたらすだろう。

あるコンポーネントがどこで何をすべきかについて大きな認識の相違があったなら、全員が合意できる点だけを採用するところから始めよう。最上位にある大きなコンポーネントに集中するのだ。それらのコンポーネントが何であるのかについてのグループの理解を深めていくのだ。コンポーネント間のつながりを詳しく説明しよう。別の名前で動いている重複したフィーチャを探そう。このプロセスによって比較的小さな変更箇所 (意味論的に類似した "trash" や "delete" といった機能など) を見出してくれるだろう。そしてコードベースを合理的に整理できるだろうし、チームを保守しやすいモジュラー化されたアプリケーションポートフォリオに近づけてくれるだろう。

手順3. 既存のコードを置き換える

ここまで到達できた開発者らは自分達でちょっとしたお祝いをしてもよい。前の 2 つの手順をうまくやり遂げたなら、開発者チームは既存のシステムについてより深く理解しているだろうし何が必要なのかも分かっているだろう。チームはシステム統合の課題について会話するためのより確かな共通語彙さえ持っているかもしれない。既存のコードを合理的に管理できるようになったのだ。

例として、クライアントサイドのフィルターとサーバサイドのクエリが同じことをしていたとしよう。チームの皆がフックについて理解しているならそれらを共通した名前に移行してフィルターとクエリの組み合せをもっとうまく機能させることができるだろう。

確かなアーキテクチャマップがあればエンタープライズアーキテクトはコードを並び替えたり編集することができる。この段階ではファイルを最終的な場所に移すための準備ができていなければならない。これは非常に大きな前進だ。Sinha は次のように述べている。「問題とはそこに注意を向けたときから始まっている。コードがよりよく体系化されていればバグは人目に付くようになるし理解もしやすくなるのだ。」

手順4. よくない依存性を捨てる

これは非常に重要な手順でDIコンテナのエキスパートが必要だ。不慣れな開発者に任せることはできない。かなりの熟練が必要なのだ。一貫したアプリケーションプログラミングインターフェースを守るために命名規約を整えることも重要だ。物事を綺麗に片づけるには正しく名前を付けることが重要なのだ。そのやり方における確かな手順は秘密にしなければならないということを心しておくことも重要だ。

これらを本当の意味で正しく行うためにスキルを磨くことは本当に難しいことだろう。だがそれは価値のあることなのだ。Sinha は上級開発者が単純なプロジェクトや仮想的なコードベースを使って DI を使ったコーディングを練習することを勧めている。彼はこう述べている。「自分だけでやるのはそんなに難しいことではない。自分のコードベースという限られた空間でやることできっと快適さを得られるだろう。」

実際のコードベースの変更作業はとても保守的だ。最も表面的なところから始めてあなたなりのやり方でコードに深くレイヤからレイヤへ潜っていく。コンパイル時依存性と実行時依存性の違いを心に留めておくことだ。データベース依存性については特に重要になる。

依存性は別として他にも特別な注意を払わなければならないタスクがある。例えばクラスローダーへの挑戦は彼等のルールによれば飛び抜けて優秀なエキスパートが求められる。彼は次のように警告する。「コードはごちゃごちゃとした複雑なものになり、アーキテクチャも粉々になって隠蔽されてしまう。未熟な開発者にとって変更作業はまるで滑りやすいスロープを歩かされるようなものなのだ。」彼はチームのコーディングリーダーである熟練メンバーにその経験を共有してもらうことと自動化テストやコードレビューによってコードの保守性を改善していくことを推奨している。

あなたの仕事相手は Java のレガシーコードだろうか？Java のモジュラリティについて思うところがあればこちらまで教えてほしい。@TTJDenman。

09 Apr 2013