読者です 読者をやめる 読者になる 読者になる

業務参画時の基本的な注意事項

【全般】

・ドキュメントについて

 ですます調にするか、である調にするか。

 段落番号のつけ方

 句読点をつけるか、つけないか。

 お客様が作成してほしいイメージを「まず」聞く。

 

・質問について

 たとえ聞く相手がすごく忙しそうにしていようが、こちらの作業が進まなければ

 自身の進捗率が上がらない。

 他の人を押しのけてでも、聞きに行く。

 

 質問は、提案形式にする。

 「~についてなんですけど、どうでしょう?」みたいな聞き方だと、

 相手に丸投げしている感が強く、相手の作業が常に止まってしまう。

 

 「~について、AかBがあると思ってるんですけど、どうでしょう?」のような

 聞き方だと、

 相手はAかBを選択するか、気に食わなかった場合のみCを考えればいい。

 一緒に考えている感が強く、相手の作業をむやみに止めることなく、好感も

 持ってもらえる。

 

【スケジュール】

・試験実施時のスケジュールを立てる際の材料

 試験項目数*重み*時間

 

【開発】

・名前の付け方

 変数名に限らず、お客様やほかの開発者がソースコード

 見たときにわかりやすい名前、コメントをつける。

 ただし、コメントをつけすぎても、後で仕様変更等で

 コメントを変更する可能性があることを考えると、

 わかりやすく、最小限にするのが「望ましい」。

 

・ログの出力

 基本はdebugレベルで出力する。

 出力するdebugログの種類は以下の通り。

 1)INFOレベルで出力するまでもないが、出力させておくと
  テスト実施時等に捗る内容

  (例)起動時に読み込んだ設定ファイルの情報

 

 2)処理時間

  性能要件を満たしているか判定するためにも、製造時に仕込んでおくと、

  結合試験時等にログの内容で処理時間が分かる。

 但し、ログは客先環境でエラーが出たときに参照し、解決するために必須な

 ツールの為、以下のような種類のログはINFOレベルで出力する。

 1)操作ログ

   エラーが出たときに最後に何をしたか判断するために出力する

   例)状態の切り替わり、ボタン押下時の画面情報

 

 2)エラーログ

   エラーの場合は、画面を出力するとともに、エラーログも出力して、

   いつその画面が出たかが分かるようにする(深夜稼働時に出たのか、

   ついさっき出たのかが分かるように)

 

 *出力しすぎても処理が重くなるので、連続で出力されるようなログ内容は、

  出力される時間間隔を決めて、連続で出力されないようにする。

 

・クラス設計

 visual studioのクラスビュー等を使用して、クラス間のメソッド、

 プロパティの統一感が図れるようにする

 

・バグ対応について

 バグは上げられた箇所だけ直せばいい、ということはない。

 まずパターンを考え、この場合はどういう挙動をすべきか、を突き詰めて

 修正範囲を確認、修正して、初めて修正完了となる。

 (自分は同じ個所について2、3回指摘を受けたところがあり、

 何回も修正するハメに....)

 

トランザクション

 時間がかかる処理は、処理中ダイアログを出し、ロールバックできる

 処理の場合はロールバック処理を入れる。

 また、キャンセル処理も時間がかかる場合は、キャンセルの処理中ダイアログ

 も実装する。

 

・DB処理について気を付ける箇所(もっといっぱいあるだろうけど..)

 SQLインジェクション

 排他制御

 インサート処理(時間がかからないよう、StringBuilder,バルクコピーを利用)

 

・画面処理について気を付けること

 複数画面の統一

  →BindingSourceを使用して、画面が100画面あろうが、1000画面あろうが、

   フォントサイズ、ボタンサイズ等の情報を一か所に集め、保守性を高める。

 

・データの持ち方

 1)シングルトンインスタンス

   メリット

     同じソースを複数の個所で記載する必要がなく、スレッドが異なっていて

     も、一意の値を取得することができる

   デメリット

     複数のスレッドから値を書き換えてしまうと、

     値の一意性が保てない

 

 2)データ持ち回り

   メリット

     複数のスレッドから値を書き換えられない為、

     自身のスレッドの中での値の整合性が保たれる

   デメリット

     同じソースを複数の個所で記載する必要がある。

     例)AソースからBソースに引数で渡して、BからCへ....みたいで面倒。

 

・設定ファイル・共通プロパティ

 一つのソリューションに複数のプロジェクトがある場合等に、

 プロジェクト毎に同じ設定パラメータを作らないように、

 xmlなどで共通化しておく。

 *なお、ファイル読み込み時は値チェックを行うことを忘れずに。

 

・エラー対応

 エラー時の挙動を明確にする。

  メッセージ出力内容

  挙動

   1)ポップアップ画面として出力するのか、ログを出すだけでいいのか
   2)エラー状態になったことで、何かすることはないか(タスクトレイアイコンを
    エラーに変えたり...)
   3)エラー状態から復帰したら、何かすることはないか(タスクトレイアイコンを    正常に戻したり...)

 

・ソース解析

 1)保守性の高さを判断する   コードメトリクス
  2)コード自体の問題が内科判断する
   コード分析

 

【テスト】

・テストパターン(随時追加?)

 1)正常ルート
 2)異常ルート

   データなし

   データ異常

   時刻

    日マタギ

    0埋め 

 3)特殊記号(DB 特殊文字)

 

・テストデータを作成する際の注意点

 大は小を兼ねる

 例)10分間のテストデータと1時間のテストデータを使用して

   テストを行わなければならない場合、

   1時間のテストデータを作成すれば、10分間のデータは

   作成しなくても済む場合がある

   →事前に項目書を確認してどのようなテストデータが必要か

    抽出しておくと効率的。

 

・テスト時のエビデンス

 テストに使用したデータ(サイズがでかい場合は作成方法等を明記)

 ログ

 キャプチャ

 テストデータを使用することで生成されたデータ等