ゴミゴミゴミエラーゴミゴミクラッシュなログ
よくあるパターン。
そもそもメソッド内で今どういうパラメータ持ってるかとかログに出されてもしらねぇよと言いたい。
ぶっちゃけそのメソッド作ってる時しか価値がない情報だろそれ、と。
メソッドを使う側からすれば失敗した場合になんで失敗したのかを探りたい訳ですよ。
そういう意味ではsuccessログもいらねぇよと。
メソッド使って成功したかどうかは帰ってきてる値で分かるから、と。
要するに一般的にデバッグログと呼ばれるレベルのログって役に立つ事がほぼない。
作り終わったらさっくり綺麗にしておいていただきたい。
ログコンソールにはそんなゴミみたいな情報じゃなくて、エラー情報だとか重要なものを出力してほしいね。
とりあえず出しておく、というログが多すぎる。
95%ゴミでしかないよねと思う。
要するに、有益な情報って1/20しかなくて、そのうち重要な情報って多分さらにそれの1/20くらいになる。
400のうち読むに値するログって一つあるかどうかと考えると、思考を放棄したログ出力がどれだけ作業効率を低下させてるのかというのが理解できるんじゃなかろうか。
ちなんでおくとするなら、ゴミみたいなログ出すのって自分が作ったものの品質を担保できないからだと結論してたり。
自分が作ったもののエラーパターン網羅できてないのがそもそもの問題。
だからって安易にログ出すな、と言いたい部分はある。
それよりちゃんとエラーパターン網羅してエラーログだけ吐くようにしてくれと。
それなりにプログラマやってて一番重要だと感じる点というのは、次の作業者にいかに作業しやすい環境を提供するかだと思ってます。
三日後の自分は他人だ、とかいう言葉がありますが、ある意味ではその通りです。
ソースがあるなら記憶も遡れるけど、大抵のプログラマって『このプロジェクトのこの機能のここ』って言われても何してたかなんか覚ええない。
『このプロジェクトのこのクラスのこのメソッド』でも覚えてるのは少数派。
ソースを見てみてようやくどの辺りにどういう手を入れたか思い出せるくらいが普通だと思う。
さらに言えば、プログラマとアップデートというのは切り離せないお話でしょうよ、と。
大抵の場合アップデート案件というのは作ったところにまず話が行く。
そこで予算的に問題があれば別の場所に行くだけの話で、そういう作り込みの部分を無視する顧客なら逆に切れてくれて万々歳だと考えるべきなんだと思う。
逆に、作ったもののアップデートって半分以上は返ってくるんだからコメントとかログとかその辺り、しっかりしようよ、と。
