新たなAPIが次々と増え、大量のデータが生成される、こうした状況はアプリケーションのメンテナンスに重くのしかかってくるだろう。Dr.DobbsのチーフエディタであるAndrew Binstock氏は、完成したアプリケーションを効率よく管理するためには、継続的開発プロセスが必要だと考えている。これにはアジャイルプロセスに着目した、メンテナンスに関するまったく新しいマインドセットが必要になるだろう。
先週、Andrew Binstock氏が継続的開発について記事を書いた。まず彼は継続的開発を継続的インテグレーションと継続的デリバリーと比較した。開発アクティビティだという明らかな違いは別にして、これまでは継続的という言葉が大げさに使われてきたが、継続的開発は本当に継続的だと彼は主張する（本当に「日に何度も」）。話は変わるが、"Continuous Enterprise Development with Java"の著者であるAndrew Lee Ribinger氏とAslak Knutsen氏は、「継続的開発」という言葉をアプリケーション開発プロセス中に継続的にテストするという意味で使っている。
続けてAndrew氏は、変化するテクノロジーの状況について、特にその大転換を先導しているIoTデバイスベンダーが公開するAPIについて述べた。こうしたAPIのバージョン変更に伴う変更がどれだけ開発者をメンテナンス作業に釘付けにするか、記事では次のように述べている。
プロダクトの機能はリリースするたびに変わり、SDKの拡張により新たなデータセットが使えるようになります。しかも、以前のAPIのまずかったところに気づいて、新しいプロダクトでは古いAPIを捨てて新しいAPIを公開する場合もあります。いずれも開発者を引き戻して、既存の動いているコードをメンテせざるを得なくします。それほど大変に聞こえないかもしれませんが、複数のIoTのデータソースをモニタリングするダッシュボードのような、大量のAPIに依存しているアプリを想像すると実感がわくでしょう。
さらに彼は、データの指数的増加とデータ処理要求を扱うための、ビッグデータとMap-Reduceのような関連プログラミングパラダイムへのシフトについても語っている。これもまた、データフォーマットの変更からプラットフォームAPIの急激な変化、そして新たな処理コンポーネントの追加といったこと全てに適応するため、継続的開発の変化に影響を受ける。このようなマインドセットの変化には、コード変更をコミットすることのコストとメリットのバランスをとることが大きな課題になるだろう。
あなたはどう考えているだろうか。アプリケーションのメンテナンスにとって、こうした変化の波はプロセスの変更を必要とするほどのものだろうか。それとも、新たな技術ベンダーによるプロダクトとプラットフォームが成熟するまでの、一時的なメンテナンスの増加にすぎないのだろうか。