文化的な生活のために！　せめて日曜日だけは！　働きたくないでゴザル！

ヘルプに入ったプロジェクトが惨憺たる有様です。
ゴールデンウィーク明けに現場で運用開始、4/20の週に現場の人を呼んでの操作研修、4/16-17にお披露目展示会、というマイルストーンが設定されています。正直な話、無理ですが。
日本で設計書を作って中国に製造・単体テストを発注、日本で結合テストという流れはコストを低く抑えられるのはがメリットですが……　ぶっちゃけ、向こうの技術者の製造技術が低すぎるんじゃー！　どう見て「安物買いの銭失い」という言葉しか出てこないんですが。

この期に及んで、作業依頼が「コーディング規約に沿ってソースの机上デバッグをしてくれ」というのがありえない。それでバグがぽろぽろ出てくるのもありえない。
例えば、共通関数からDataTable型のデータを取得した後、それがnullかどうか、Rows.Countが0かどうかもチェックせずにカラムの値を参照するなんて当たり前。
objectがnullだったらString.Emptyに変換する共通関数を通した後で、初期値チェックでnullかどうかを比較しているのもあった。
エラー発生時にtry-catchで拾うのは良いが、共通エラー処理関数を呼んだ後もう一回throwしているので、一度エラーが発生したら同じエラーメッセージボックスが5～6回連続で表示されるとか。
しかも、微細なバグをこちらで修正してしまうと、それ以降にソース修正依頼を中国にしたときに「別人の手が入っているので私どもの担当ではなくなっている」と拒否されるんだそうで、うかつに直せない。
しかも、納期が目前なのですっぱり切ることもできない（新しい人間を一から教育する暇がない）。
ヘルプに入るときに要求された条件として、C#がコーディングできて、他人の書いたソースを解析できて、日本語と常識が通じて、仕様書に記載された曖昧な部分があれば自主的に質問してくること、だったのですが。
それらの「当たり前」のことができる人が重宝される職場環境って……

最後に、頭を抱えてしまったロジックをソースから抜粋。うっかりミスでbreakが抜けているというならまだ救いようがあるけど、仕様書を確認した限り、そうではない模様。
for ( i = 0; i < dtTable.Rows.Count i++ )
{
　　if ( dtTable.Rows[i][DelFlg] == "1" )
　　{
　　　　dtTable.Rows[i].Delete();
　　}
}