なにを社内フレームワークと呼ぶか？ - jfluteの日記
DKJフレームワーク？ 社内フレームワークという言葉があります。また、独自フレームワークと呼ぶことも。会社の規模によっては、社内共通とプロジェクト独自の境界線が曖昧なときも。 えてしてこの言葉はネガティブなイメージを持ちます。とにかく、ダークなイメージです。 jfluteも、若い頃なんかは特に「DKJフレームワーク (DoKuJi)」とか揶揄してました。(jfluteはいまもバカですが、昔はもっとおバカだったので...) ただ、アーキテクトとしては、単なる好き嫌い感情や、イメージだけで語るわけにはいかない。特にここ一、二年で、その辺をよく考えるきっかけがあったので、そもそも、社内フレームワークという定義、少しまとめてみたいと。 ネガティブイメージの最たる理由 社内フレームワークのネガティブイメージの最たる理由として、「ノウハウが独自なので、他の現場で活かせない、新しい人が来ても敷居が高い」
デバッグ手順(スタックトレース重要) - jfluteの日記
よくある会話 こないだ久しぶりにある方とお会いして、色々情報交換したのですが、「StackTraceをみないでデバッグし始めてしまう人」はだいぶ少なくなってきたように思っているのですが、まだまだ結構こういうことがあるようです。 X「例外がでてるのですが一時間かけても原因がわからなくて...」 Y「お、じゃあStackTraceは見た？」 X「いやみてないです」 Y「ちょっと見せてみて」 X「これです」 Y「(StackTrace見てすぐに)ああもう原因わかった」 X「...」 Y「...」 ポイントは二つ 大きく二つのポイントがあると考えました。 A. 例外発生時のデバッグ作業が手順化されてない B. スタックトレースの見方がわからない A. 例外発生時のデバッグ作業が手順化されてない 例外が発生したら、まず何をするべきか！？ A-1. 例外クラス名・例外メッセージを読む A-2. スタッ
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
