2017年10月
1 2 3 4 5 6 7
8 9 10 11 12 13 14
15 16 17 18 19 20 21
22 23 24 25 26 27 28
29 30 31        

最近のトラックバック

無料ブログはココログ

« ダイヤグラム構成部分の設計を見直し | トップページ | 大晦日・雪の米原 »

2010年12月30日 (木)

2010年のOuDia総括/リファクタリングの効果

 今年も残り2日ということで、今年の総括をしてみたいと思います。

 今年のOuDiaのバージョンアップは、5回に留まりました。2009年は3回でしたが、これは職場の変化があって忙しかったからです。今年は仕事は去年よりも楽だったのですが、その割にはOuDiaの開発効率は上げられなかったという感じです。

 今年のOuDiaの目に見えた変更点は、以下のようなものでした。

  1. 時刻表ビューの選択表示の変更(Ver. 1.00.03 (2010/04/30))
  2. 駅ビューでの駅の順序の反転(Ver. 1.00.03 (2010/04/30))
  3. 駅時刻のプロパティダイアログに[時刻の繰上げ・繰下げ] の選択を追加(Ver. 1.00.03 (2010/04/30))
  4. ダイヤグラムビューのサイズ変更時の動作を変更(Ver. 1.01 (2010/09/26))
  5. ダイヤグラムビューのスクロールの高速化(Ver. 1.01 (2010/09/26))
  6. [列車種別のプロパティ]として、[時刻表.フォント] を追加(Ver. 1.01 (2010/09/26))

 作業量として大きかったのは、1・4・5です。
 1.はグリッド形式ビューのリファクタリングの副産物です。
 また、4.の実現にあたっても、ダイヤグラムビューのかなりのリファクタリングが必要でした。このリファクタリングの過程で、5.を実現することができました。

 2010年のOuDia開発を総括するなら、

一見無駄なリファクタリング作業にかけた時間が多くを占めたが、リファクタリングの効果が性能向上として現れた。

ということになると思います。

 リファクタリングは、すぐに機能追加につながるわけではありません。このため、業務としてのソフトウエア開発現場では、リファクタリング作業を認めてもらうことは大変困難です。開発現場は「(収入になる)ユーザー要望の機能追加をさっさとやれ」という論理が優先されることがほとんどですし、営業サイド・経営サイドには「何も機能が追加されないなら、ソフトを直すのは無駄だ」と考えている人も多く、リファクタリングの効果が広く理解されていません。

 しかし、設計の見直しを行うことなく機能追加ばかりを繰り返していると、ソフトはついにはリファクタリングもままならないほどの設計破綻をきたしてしまい、誰にも理解できないソフトになってしまいます。このようなソフトは、バグを修正することすらできなくなります。具体的には、1つバグを直したと思ったら、新たな2つのバグが発生した・・・という泥沼に陥ります。

 そんな粗悪ソフトの事態収束の責任を押し付けられたプログラマは最悪です。モチベーションをなくすだけでは済むものではなく、退職(辞め逃げ)したり、心身を病んだりする人も出てきます。僕はそんな悲惨なソフトもいくつか見てきました。

 フリーソフトウエアであるOuDiaには、「(収入になる)ユーザー要望の機能追加をさっさとやれ」などという制約はありません。せめてここでは、まず設計を良好な状態に保ち続けることを優先したいと思っています。

 先日も述べたように、現在もダイヤグラム関係のソフトのリファクタリングを行っています。目だった機能追加にはつながりませんが、必ず効果はあるものだと思うことにしています。

 年末は荒天の予報ですが、皆様もどうかよいお年をお迎えください。

« ダイヤグラム構成部分の設計を見直し | トップページ | 大晦日・雪の米原 »

コメント

コメントを書く

(ウェブ上には掲載しません)

トラックバック

この記事のトラックバックURL:
http://app.cocolog-nifty.com/t/trackback/186995/50438126

この記事へのトラックバック一覧です: 2010年のOuDia総括/リファクタリングの効果:

« ダイヤグラム構成部分の設計を見直し | トップページ | 大晦日・雪の米原 »