BT

継続的開発は新しいメンテナンスの現実か?

| 作者: Jeevak Kasarkod フォローする 3 人のフォロワー , 翻訳者 笹井 崇司 フォローする 0 人のフォロワー 投稿日 2014年5月3日. 推定読書時間: 2 分 |

原文(投稿日:2014/04/21)へのリンク

新たな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の急激な変化、そして新たな処理コンポーネントの追加といったこと全てに適応するため、継続的開発の変化に影響を受ける。このようなマインドセットの変化には、コード変更をコミットすることのコストとメリットのバランスをとることが大きな課題になるだろう。

あなたはどう考えているだろうか。アプリケーションのメンテナンスにとって、こうした変化の波はプロセスの変更を必要とするほどのものだろうか。それとも、新たな技術ベンダーによるプロダクトとプラットフォームが成熟するまでの、一時的なメンテナンスの増加にすぎないのだろうか。

この記事に星をつける

おすすめ度
スタイル

こんにちは

コメントするには InfoQアカウントの登録 または が必要です。InfoQ に登録するとさまざまなことができます。

アカウント登録をしてInfoQをお楽しみください。

あなたの意見をお聞かせください。

HTML: a,b,br,blockquote,i,li,pre,u,ul,p

このスレッドのメッセージについてEmailでリプライする
コミュニティコメント

HTML: a,b,br,blockquote,i,li,pre,u,ul,p

このスレッドのメッセージについてEmailでリプライする

HTML: a,b,br,blockquote,i,li,pre,u,ul,p

このスレッドのメッセージについてEmailでリプライする

ディスカッション

InfoQにログインし新機能を利用する


パスワードを忘れた方はこちらへ

Follow

お気に入りのトピックや著者をフォローする

業界やサイト内で一番重要な見出しを閲覧する

Like

より多いシグナル、より少ないノイズ

お気に入りのトピックと著者を選択して自分のフィードを作る

Notifications

最新情報をすぐ手に入れるようにしよう

通知設定をして、お気に入りコンテンツを見逃さないようにしよう!

BT