Top / プログラミングテクニック / 20.こんなプログラマ(ム)いらない

なんで外注さんのプログラムって出来がよくないのかなぁ?
もうちょっと責任もって仕事してよ。(`ε´*)プンスカ
というわけで、害虫さんから受け取ったプログラムについて、気になった部分を取り上げて見ます。
あなたは、こんなプログラムを作っていませんか? 

やたら配列を使う

とにかく配列を使いたがる。2次元3次元はあたりまえ、おまけに DB から読み込んだデータを配列に入れて、ぶん回している。
ソート順や、SQL の書き方に気を使ったり、コントロールブレイク処理を使えば、そんな必要もないのだが。

10 件、20 件ならば、そうでもないが、1000 件、2000 件になるとメモリをバカスカ喰うことになるが、意識しているのだろうか?

CSV を読み込んでソートするために 「VB でお気楽ソート」を教えてあげたのだが、配列に格納してるのはなぜ?
配列に入れた後、Recordset にセットしてソートしてるぞ。
おまけにソートしたあと、また配列に入れてるよー。(T_T)

最初から Recordset でデータを保持してりゃいいのに。

なんかよくわからんが ActiveX.DLL にして処理の共通化を図った(らしい)

共通化するのはいいことだが、プログラム固有の処理まで ActiveX.DLL にしちゃいかんだろう。
おまけにバグだらけである。メンテナンスが大変。

プロパティやメソッドの引数などが適当でないため、やたら効率が悪い。

DBへの出力結果を確認していない

画面はそれらしく動いているが DBへの出力結果を見るとダメダメ。

ゼロ件だとまともに動作しない。

DB から読み込んだ件数がゼロ件だと、エラーが出る。 いちおうゼロ件を意識した様子が注釈からうかがえるのだが、テストしてはいないようだ。 あー、1件のときもだめだ。

エラートラップできていない

一生懸命例外処理を書いているのだが、なっちゃいない。
たとえば、

   Sub Main()
       On Error Resume Next
       Call Hoge
       MsgBox "なっちゃいねえよ"   -------------- (1)
   End Sub

   Sub Hoge()
       Dim a
       a = 1 / 0 -------------------------------- (2)
       If Err.Number <> 0 Then
           MsgBox "エラーざんす"  --------------- (3)
       End If
   End Sub

(2) でエラーが発生すると、(1) に飛んでしまうので、(3) の例外処理が日の目を見ることはないのである。 (--;)

プログラムのログ出力

プログラムでログを吐き出しているのだが、プログラムをデバッグするためのログになってしまっている。(このログは、お客さんが目にする)
想定できないエラーに対して、VB のエラーメッセージを出したり、サブルーチン名を表示するのはかまわないが、ファイルがないとか、DB に接続できないとか、想定できるエラーに関しては、それなりのメッセージを出すべきだろう。

ファイル出力

なんで Output で開いたファイルをいったん閉じて、そのあと、Append してるんだ? ログファイルなら、そういう処理も OK だが、開いたら、そのまま書いていけばいいではないか。

ORACLE にADOX

テーブル構造の取得が簡単だからって、ADOX なんか使ってくれるなよ。 案の定、不具合が出ちまった・・・ しょうがないから oo4o で書き直そう・・・

今はどうかわかりませんが、違うスキーマに同じオブジェクトが存在していると、一緒になって取得されていました。

特殊文字の処理ができていない。

おいおい、ここの項目はシングルコーテーションが入る項目だろ?入らない項目であっても、処理しとかなきゃだめじゃん。 SQL エラーでコケちゃうぞ。

注釈と処理が違う

〜をクリアって書いてあるけど、ぜんぜん違うものをクリアしてる(;_;)




トップ   編集 凍結 差分 バックアップ 添付 複製 名前変更 リロード   新規 一覧 単語検索 最終更新   最終更新のRSS
Last-modified: 2009-10-27 (火) 02:35:04 (2799d)