社内のプロジェクトで使用する汎用ライブラリについて
ユーティティ系のライブラリであったり、DBアクセス周りのクラスであったりについて。
現状の問題点
- プロジェクトによって使うライブラリが違う
- 同じライブラリでも、適宜手を入れられているためプロジェクトによって微妙に違う
- 汎用ライブラリなのに例外に対する処理が適切ではない
理想
- どのプロジェクトでも同じライブラリを基本的に使用
- ライブラリはバージョン管理すること
- 誰でもライブラリの修正に参加できる環境にあること
- 例外への対処やログの出力は適切にしてあること
ってことを考えるとGitHub等を使って管理していくのが一番だなって思います。
誤った実装は誰でも指摘できるようにし、それを受け入れる環境ってのは重要だと思います。
社内でそうした環境を整備し、部をまたいで共有したりってことができれば、生産性あがるんじゃないかと。
また、こうしたライブラリのコーディング方法や例外処理への対処方などをお手本にするようにしてもらえば
各プロジェクトのつくりもあわせていけるんじゃないかと。
数百ページもある退屈な社内コーディング基準書を見るより、実際のコードのお手本で学べます。
配属された新人も、学ぶものがはっきりしているので、分かりやすいんじゃないかと思います。
以下余談
今のプロジェクトで使用してるDB周りのは
SQL投げたときにDBから例外が返ってきたとしてもcatch句でreturn nullするような超絶仕様でした。
なのでエラーでこけたときの情報がヌルポだけですし、その他いたるところでthrow exみたいに再スローしてるので
StackTraceからも追いづらいです。
そもそも例外が発生する箇所でcatch処理がかかれていなかったり、ガード条件ではじいてなかったり、
例外はすべてExceptionでcatchしてたり。
ログを出力する機能もないですし、デバッグの方法はエラーメッセージから、自力で追うんだよ！って教えられました。
ライブラリ修正するように提案していたら、今までの実績があるから君が手を加えることは許されないっていわれました。
今のプロジェクトはC#なので、DB周りはDapperとか使用したらいいんじゃないですかって提案したら
フリーのライブラリは信用できないから導入できない。実績がない、といわれました。
例外をnullで返すような自前ライブラリよりはいいと思うのですがね。
社内のいたるところでこうした不幸な思いをしてる人いっぱいいると思うのでなんとか改善したらいいんじゃないかなと思います。
