バリデーションとパースの分離。Goで実装する「変更に強い」CSV 処理の設計 - カミナシ エンジニアブログ

こんにちは。カミナシで「カミナシ 従業員」の開発を行っている nilpoona です。 業務アプリケーションを作っていると、避けて通れないのが CSV インポート機能 です。 最初は「encoding/csv で読んでループ回せば実装できる」と考えて作り始めるのですが、仕様が複雑になるにつれて、以下のような課題に直面することがあります。 バリデーションとパース処理が混在し、エラーの発生箇所が追いづらい。 「文字コードが Shift_JIS だった」など多様なエンコーディングへの対応で、ビジネスロジックが複雑になる。 パースやバリデーションエラーを即座にリターンしてしまうと、ユーザーは一つのエラーを直してもまた次のエラーが出る「モグラ叩き」のような修正サイクルを繰り返すことになる。 データが正しい状態か保証されないまま、後続の処理（DB 保存など）に渡されてしまう。 今回は、こういった CS

[hdampty7]

メモリに全部載せてる点でまあ好きにしろと。どうせ大容量ファイルを扱うようになったら全部書き直しだよ。

[Eiichiro]

業務システムあるあるだぁ。共通処理つくって、モジュール化したなぁ。 一案件だけだと、簡単に書けちゃうから、共通処理を使ってくれないまでも、あるある。

[toricls]

記事冒頭の課題提起のところだけでも最高に好きな記事

[lufiabb]

大容量でも全部書き換えってことはないんじゃないかなと思った。型をiter.Seqにして、スライスに詰めているところをyieldに変えるくらいだと思う

[yamadadadada2]

エンドユーザーが経理や総務ならまだマシで、中小企業のオッサンが扱うデータの入出力をデビューしたての新卒とかが実装したコードを数年後にメンテするつらい現場をなぜかよく見かける（白目

[MASSI]

RDBMSやprotobufでもシリアライズの都合はIDLやリフレクションでサクッと捌いて入り口で厳格なモデルやDTOに詰め直すのは良いやり方だと思うけど、カラムが足りないのはシリアライズの都合なのでパーサーで落としていいか

[yarumato]

“Parse, don't validate を参考にCSV処理ライブラリを実装。入力を単に検証（Validate）だけでなく、型のあるデータ構造に変換（Parse）で、安全性を型システムで保証する。様々なCSV（ユーザー、商品、在庫）に柔軟に対応可能”

[strawberryhunter]

とりあえず手元の問題を解決するために思い付きで作った感じがする。既存ライブラリを使った方が良かったのではないか。

[nojimage]

"重要なのは、「カラム数が合わない」といった構造的な問題も、即座にエラー(return err)にするのではなく、ステータスとして記録"

[mkusaka]

GoでCSVインポートを設計する際、encoding/csvに直接書かずReader/Parser/Validatorの3層に分離し変更に強くする手法を解説