Loading...

社内システム開発日記:その83

前書き

お疲れ様です!
小手投げです。

久々に体重計に乗ったら、安定していた80kgから6kg増えてました。
ベルトに肉が乗るのがはっきりとわかるくらいになりました。
とりあえずこのまま90kgまで様子を見ます。

今回は日記です。

日記

Go言語でのログについて調べる

標準ログ
・Print、Panic、Exitしかない
・ログレベルで制御できない
・FATAL以上のログはすべてexitする

標準ログ以外だと色々なパッケージがあり、
seelog、glog、logrusといったあたりが有力か

担々麺にロガーで実現する機能は何かと質問
第一にエラー時のスタックトレースが確認できること
try-catchがあるなら囲う
デバッグの際にはブレークポイントを仕込む
設計としてはログをどこにはくか、動作、結果に対してどんなレベルのログを出すか
ログの内容はどういうものか、を決める
開始、成功やDBに接続した時の条件やSQL内容など

golangにはtry-catchはない
panic(を自発的に発生させる)とrecoverはあるが利用は推奨されない
errorを使う
errorは値だけでスタックトレースを含まない

基本的にはerrorを細かく設定する
errorにスタックトレースを含める方法はいくつかある
panicが発生した際はスタックトレースを出力してくれる

ブログの執筆公開

部長からPDF出力のシーケンス図について指摘を受ける
・PDF出力機能というオブジェクトが機能を持ちすぎている
 出力という名前ならば出力する機能だけを持つべき
 粒度が他と比べて大きすぎる
・社員マスタにエンジニア情報を取得しにいくのは、
 社員マスタにエンジニア情報があるという前提を強要するのでだめ
・出力形式でPDFを選択してPDF出力機能に行くのはおかしい
・シーケンス図にもブラウザとアプリとデータの分類を書いた方がいい

シーケンス図を直す

後書き

ロガーの何を決めればいいかというところが何となく分かってきました。

シーケンス図の粒度は前に指摘されたので意識するようにはしたのですが、大きくなりすぎてしまいました。

ではまた次回。

情報戦略テクノロジー