- ベストアンサー
バグを多発してしまいます。
いつもお世話になっております。 IT業界に勤務して3年目の pinchcock と申します。 現在、私が所属しているプロジェクトは、部長 ― 私(平社員) といった、2人体制の社内システムプロジェクトです。 社内システムの新規機能追加・保守が頻繁にあるわけですが、 開発~試験まで一人でこなす必要があります。 ただ、私の実力不足(主にチェックリストを網羅できない)と スパゲティプログラム(1000行近くのSQL文等)が合い重なって、 改修などすると、別のところでバグを発生させてしまう状況が、 ここ最近多く見られます。 先日も、私が発生させてしまったバグが原因で、 経営陣会議に出席し、バグの説明&謝罪をしました。 とても情けなかったですし、向いていないのかなとも 感じてきております。 そこで、品質管理に関するセミナーに参加しようと 考えているのですが、経験豊富な皆様にもアドバイスを頂きたく 質問させて頂きました。 皆様が開発・保守で気をつけておられる点は どのような点でしょうか? お聞きしたいことは、 (1)新規機能を作成する際に、気をつけるべき点。 (2)改修のときに、気をつけるべき点。 (3)お勧めの品質管理のセミナーor書籍情報 です。 以上、ご教授の程よろしくお願い致します。
- みんなの回答 (3)
- 専門家の回答
質問者が選んだベストアンサー
スパゲティプログラムばかり指摘されていますが 一番の問題点は「主にチェックリストを網羅できない」でしょう? スパゲティくらい、ほどいてしまえば一本道でしかないのだから たいした問題では無いです。 (もちろん、書いてもよいというわけではありませんけど) 修正する前に、影響範囲を業務的側面に渡って検討していますか? ぱっと読んだ感じだと、コーディングレベルのバグというよりも 設計段階のバグが多いんじゃないかなと思いました。 影響範囲の洗い出しは一部慣れということもありますが テスト項目にインターフェイス的な総当たりの機能テストも盛り込んでみてはいかがでしょうか?
その他の回答 (2)
- mk48a
- ベストアンサー率56% (1133/2007)
スパゲティプログラムはそのまま使うならともかく拡張性を期待してはいけません。 今後も機能拡張をするつもりならば、いったん全面改修してメンテナンス性の良い構造にする方が後々のコストが安くつきます。 まぁ、まとまった工数が必要になるので上司を説得するのは難しいと思いますが・・・ とりあえずの改変を加えてできあがったのが現在のスパゲッティプログラムであることを認識した方が良いと思います。 品質管理とかはそれらができた上で行わないと手間だけ増えるだけですよ。 まずはリファクタリングについて勉強した方が良いかも。 http://www.amazon.co.jp/s/ref=nb_ss?__mk_ja_JP=%83J%83%5E%83J%83i&url=search-alias%3Dstripbooks&field-keywords=%83%8A%83t%83%40%83N%83%5E%83%8A%83%93%83O&x=0&y=0 その後、品質管理を勉強すれば良いと思います。 http://www.amazon.co.jp/s/ref=nb_ss_0_5?__mk_ja_JP=%83J%83%5E%83J%83i&url=search-alias%3Dstripbooks&field-keywords=%95i%8E%BF%8A%C7%97%9D+%83%5C%83t%83g%83E%83F%83A&x=0&y=0&sprefix=%95i%8E%BF%8A%C7%97%9D%81%40
お礼
お礼が遅くなり申し訳ありません。 ご回答ありがとうございました。
どう考えても原因は「スパゲティプログラム(1000行近くのSQL文等)が」でしょ。 何で機能単位に分けないんでしょうか? 機能単位に関数化して、メインルーチンからは各関数を呼ぶだけに留める。 各関数は、I/Oのインタフェースをしっかり決めて、中の動きを知らなくても使えるようにしておく。 PCLは、それぞれの関数単位と、メインルーチンに分けて、メインルーチンのPCLでは、各関数の中身は確認しない。 先ずは、そういう基本的な所からやり方変えないと、どうしようもないのでは? >開発~試験まで一人でこなす必要があります 開発から試験までなら、未だマシな方だと思いますが。 社内プロジェクトだから、未だ楽な方ですよ? 対顧客開発だったら、客との打ち合わせから、基本設計、詳細設計、開発、テスト、って全部受け持つ場合もありますから。 なおかつ、断れない仕様変更が出たり、さらに、それでも納期は変わらない、とか。 まぁ、部長の人が飾りなら、全部一人でやらないと駄目って事でしょうから、教えを請える人がいないって点には同情しますが・・・ 改修の時に気をつけること・・・どんなに汚いロジックだろうが、正常に動いている所は絶対に触らない、これ鉄則です。 なお、品質管理のセミナーや書籍とか以前の、根本的な作業のやり方的な問題だと思いますので・・・
お礼
お礼が遅くなり申し訳ありません。 ご回答ありがとうございました。
お礼
お礼が遅くなり申し訳ありません。 ご回答ありがとうございました。