2005年10月29日

ソースとバグ管理票の紐づけ

皆さんは自分の開発したソースをちゃんと管理していますか。
筆者はソースの管理が不十分だったため,顧客に怒られたことがあります。

とある本番稼動中のシステムでプロセスが異常終了しました。
原因はメモリの初期化忘れ。メモリの初期化を忘れたため,変数に想定外の値が入っており,不正なアドレスを参照してプロセスが異常終了していました。 その場でプログラムを修正し,顧客への修正版の提供と,障害報告書の提出で,この件はクローズとなりました。

そう,問題が発生したのはこの後でした。

しばらくしてからシステム更新の提案を行い,顧客に予算を取ってもらいました。更新内容を提示し,顧客から了承をとってプログラムを修正。自社内でのテストまでは完璧でした。
本番稼動中のシステムに差し替え,実際に稼動させてからが問題でした。

以前とまったく同じ場所でプロセスが異常終了したのです。

問題が発生したと連絡を受けた時点で顧客はカンカンに怒ってました。

「あの不良は直ってたんじゃないのか。どうしてまた発生するんだ。」

急いで調査したところ,案の定,更新したシステムではメモリの初期化忘れの処理が修正されず残っていました。
よくよく考えると顧客環境でしか問題のプログラムを修正しておらず,自社に持ち帰るのを忘れていたのです。自社でバグ管理票は起票していたのに,対応するソースが入っていないという間抜けなミスをしていたのです。

気がついたときはあとの祭り。顧客からは以前のシステムで発生した障害への対策がすべて組み込まれてることを確認しろと言われ,社内では反省会でボロボロにされました。



posted by まる at 09:55| Comment(0) | TrackBack(0) | プログラマ Chips | このブログの読者になる | 更新情報をチェックする

2005年10月25日

負担のババ抜き

小規模の開発では自社と顧客との関係は一対一ですが,中規模以上の開発では同業他社が絡んできます。
この際に重要となるのが,同業他社との関係です。

同業他社を味方につけて顧客の無茶な要求を断ったり,面倒なところを他社におしつけるのです。
例えば,ショッピングサイトなどのWebとDBを使用したシステムにおいて,Web側のプレゼンテーション層を自社であるA社が,DB側のビジネスロジック層をB社が受注したとします。

当初の顧客の要望は買い物カゴに入れる商品は一度に1点まででした。
コーディング・テストと進め,開発も終盤にさしかかったところ,顧客の一言がプロジェクトに火をつけました。
「うーん。やっぱりまとめ買いできたほうがいいね。」

凍りつく担当者。
複数の商品を買い物カゴに入れる機能は,当初の顧客からのヒアリングにより実装しない方針で進めてきました。
ここで取れるコマンドは3つ。さあ,どうする。

  1. たたかう
  2. かわす
  3. たてにする

1の「たたかう」は顧客と戦い,仕様変更そのものをナシにしてもらうか,値増しと開発期間増加を認めてもらいます。
2の「かわす」は修正工数の少ない別の方法を提示します。これが選択できればベストですが,選択できない場面の方が多いでしょう。
3の「たてにする」はB社に仕事をおしつけて自分は逃亡します。

A社,B社,顧客という3者が,負担という名のジョーカーをめぐってババ抜きをするわけです。
ババ抜きに負けた会社が負担をかぶります。

このような局面では,B社の出方を観察するのが賢明でしょう。
JavaScript等を用いてWeb側で複数点の商品を買いものカゴに入れる手段を,B社が提案する危険性があるからです。
この仕様であればDB側は一度に1点のままなので,B社に被害はありません。そうなると,顧客とB社の双方を相手に戦うことになります。このままではピンチです。なんとかB社と連携して「たたかう」を選びたいところです。
B社にしてもA社がDB側の問題と主張して,A社と顧客の双方と戦うのを警戒しているハズです。
そこで,B社と協力して顧客と戦えればベストなんですが,競合他社はライバルなので,相手の失点にしようとして責任のなすりつけあいをすることになりがちです。 そうならないのがベストなんですが…。

posted by まる at 00:28| Comment(0) | TrackBack(0) | 管理者 Chips | このブログの読者になる | 更新情報をチェックする

2005年10月18日

入力値はすぐに妥当性を検証せよ

ユーザが入力した値は信用してはいけません。
ユーザというものは,プログラマの予想の斜め45°上を行くものです。油断してはいけません。
入力値の妥当性チェックは必須。それも入力が行われた直後にするべきです。
ユーザの仕込んだ恐ろしいトラップがプログラムを異常終了や不正演算に追い込むのです。

例えば身長と体重を入力すると,BMI(肥満度を示す指標)が出力される簡単なプログラムを考えます。
BMIは体重(Kg)/(身長(m)×身長(m))で求められます。
身長を0,体重を60として入力するとどうなるでしょう。

計算式に値をあてはめると次のようになります。
BMI=60/(0×0)=60/0=???
結果として,計算結果が不正となるか,例外を送出するか,異常終了するかのいずれが発生します。
身長に0を入力するほうが間違いです。しかし,入力が間違いであることを通知しなければなりません。 入力値のチェックをせず無邪気に計算するようでは,プログラマとしての腕が疑われます。

ユーザの入力値を検証するタイミングはいつがいいか。 身長として入力された値のチェックは,ユーザが入力した直後と,BMIの計算直前の二つのタイミングがあると考えられます。
どちらでチェックするのがいいか。それはユーザが値を入力した直後です。
ユーザの入力が間違っていることがすぐに分かるからです。

例えば,身長が入力されてからBMIの計算を行うまでに5分かかる処理がある場合を考えてみましょう。
身長が入力された直後に値をチェックするのであれば,ユーザはすぐに自分の入力が誤っていたことが分かります。
ところが,BMIの計算の前にチェックするのであれば,5分待ってから初めてユーザは自分の入力が誤っていたことが分かるのです。たまったものじゃありません。

今回の例では出てきませんが,処理の直前に値のチェックをしようとすると,他の処理により値が書き換えられる場合があります。ユーザの入力値が原因で不正な処理となるのか,プログラムのバグで不正な処理となるのかが判断できなくなり,障害なのか,ユーザの入力が間違えていたかの判断が難しくなります。

入力値の妥当性チェックは必須。それも入力が行われた直後にすべきことを肝に銘じてください。

posted by まる at 01:14| Comment(0) | TrackBack(0) | プログラマ Chips | このブログの読者になる | 更新情報をチェックする

2005年10月10日

鬼の系譜

この業界は独学で習得できる技能もたくさんありますが,基本的には会社で業務のイロハを叩き込まれます。
人買いに連れ去られて客先で一人で常駐といった環境でなければ,先輩が教えてくれます。

挨拶の仕方から,仕様書・報告書の書き方,テストやコーディング手法などいろいろなことを教育されるでしょう。
そのおかげで師匠と弟子はコードの書き方,アルゴリズムの選択基準などの傾向,思考などが一緒になります。
そばで観察していると,最初は師匠の言葉に反抗していた弟子も,時間が経つにつれ師匠と同様の思考パターンで行動するようになります。過去から連綿と受け継がれる系譜というものを実感せずにはいられません。
きみらは一子相伝の宮大工か!とツッコミたくなります。

本人の人柄にもよりますが,チェックの厳しい先輩に師事した人は厳しい先輩に,甘い(優しい)先輩に師事した人は優しい先輩になります。自分自身も指導途中という未熟な身で後輩のコードをチェックしなければならないとき,人は判断するための基準を求めます。その基準となるのが過去に先輩から受けた指導なのです。後輩の書いたソースを眺めてると自分がチェックされた場所が気になるわけですね。

厳しい先輩についたほうがSEとして実力はつくのですが,あまりに厳しい先輩につくとイジメと思うほどのつらい指導がまっています。
ソースが完成した後で最初から書き直させるとか,仕様書を紙で書かせるとか,全体スケジュールから見れば余裕のある状況下で徹夜をさせたりなど,まさに鬼の所業です。
厳しい指導に耐え切れずやめていく後輩たち。その指導の鬼気迫る様から「鬼の系譜」と名づけられました。
生き残れば実力を身につけれるが,一歩間違うと業界からの退場が待っています。
しかも生き残った先輩が後輩に同じ指導を繰り返す。まさに「鬼の系譜」です。

あなたを指導してくれた先輩はどんな先輩でしたか。

posted by まる at 23:06| Comment(0) | TrackBack(0) | 社会人 Chips | このブログの読者になる | 更新情報をチェックする

2005年10月03日

こわ〜いソースの著作権

最近はオープンソースなアプリケーションであふれています。あのシステムはLAMP(Linux/Apache/MySQL/Perl)で組まれたという話を聞く機会も増えました。
営業の視点から見れば,オープンソースなアプリケーションにより安価な提案をできるというメリットがあります。
しかし,プログラム開発に視点を転じると目を覆いたくなるようなお寒い状況です。

よくあるのが,別の顧客に納品したソースを使いまわしている例。
次に多いのが,Webで公開されているサンプルソースをプログラムに組み込んでいる例。
最後に,ライセンスを意識せずにライブラリを製品に組み込む例です。

どの例も全くのNGではありません。別の顧客に納品したソースの場合は,そのソースに対する著作財産権を放棄しない契約を結んでいれば問題ありません。Webで公開されているサンプルソースもサイト管理者から使用許諾をもらえばいいだけですし,ライセンスのあるライブラリは,ライセンスを遵守すればよいのです。

問題なのは,手続きを全く意識していない人がたくさんいるという現実です。これが顧客にバレると,該当ソースの除去ですめばよいほうで,最悪は契約解除のうえ出入り禁止というペナルティが待っています。一般の人に販売する製品でGPL違反が発覚した場合などは,会社のイメージダウンは避けられません。

自分のためにも法律は守りましょう。

posted by まる at 20:51| Comment(0) | TrackBack(0) | 管理者 Chips | このブログの読者になる | 更新情報をチェックする

広告


この広告は60日以上更新がないブログに表示がされております。

以下のいずれかの方法で非表示にすることが可能です。

・記事の投稿、編集をおこなう
・マイブログの【設定】 > 【広告設定】 より、「60日間更新が無い場合」 の 「広告を表示しない」にチェックを入れて保存する。


×

この広告は180日以上新しい記事の投稿がないブログに表示されております。