連動ファイル設計不備

過去の失敗をevernoteに書き留めていたので、少しずつこちらに移植。

[内容]
ファイル連動に関して、以下の考慮が出来ていなかった。
・項目にカンマを含む場合の考慮
・項目に改行コードを含む場合の考慮
・受取先が数値項目なのに、送信されてくるデータがダブルクオーテーションで囲まれていた場合の考慮
　ETLのツールによっては、型定義していないと、同じ項目なのにあるレコードでは数値、あるレコードでは文字列と自動変換してしまう。結果、後続処理でエラーになる場合がある。
・項目に半角スペースパディングやゼロパディングが行われている場合の考慮
　逆に半角スペースサプレスやゼロサプレスが行われている場合の考慮
・DBでnull、空文字で管理している項目の取扱い
　(nullも空文字も同じ扱いなのかどうか、XMLやJSONの項目の存在有無に関わるのかどうか)
・コード値が直値で設定されている項目や、変換後のデータが送信されてくる場合の考慮
・ヘッダーが含まれて送信されてくるかどうかの考慮
・ファイルによって文字データが異なったり、外字などが入ってくる可能性の考慮
・日付のフォーマットが項目によってばらばら(2017/02/01、2017/2/3、2017.1.2)
・同様にタイムスタンプも項目によってばらばら(2017.01.02 12:34:56, 2017/01/02 12:34:56.789, 2014-10-10T13:50:40+09:00)
・上記の不安定なデータが連動される可能性を考慮せず、またバリデートする事を怠っていた事

[原因]
・今まで安定しすぎたデータしか取り扱ったことがなかった為
・ユーザーが直接作成するデータを想定できていなかった為
・ファイル連動のバリデート処理や、項目定義が甘かった為

[対応方法]
・ETLなどで決め打ちなどせずに、柔軟なプログラムなど用いてバリデート処理や前処理などを行う。
　またはETLでどこまでうまく裁けるかのスペック把握を行っておく。
・連動ファイルを取り扱う際に考慮しておかないといけない事を纏めたファイルフォーマットやチェックリストを手持ちしておく
・項目のフォーマットに関しては厳密に決めておく
・事前に生データをもらっておく
・どちらが変換に責任を持つのか決めておく
　相手先との力関係、連動元がホストやNotesなどレガシー系で修正できないなどでも決まるので、その場合開発PGMの価格転嫁できるかの調整
・例外ケースの調整を行っておく