著作一覧 |
なんで以下のようなコードが生まれるのだろうか?
... } catch (Exception e) { logger.error("xxxでエラーになった"); }loggerはLog4JのLogLogのインスタンスなので、あと3文字追加すれば、
... } catch (Exception e) { logger.error("xxxでエラーになった", e); }
となって、話が異様に簡単になる。
なっていなかったので、例外になったという事実だけを淡々と記録したログを前に途方に暮れて調査に無駄な時間を使うことになった。
どうも、彼らはユニットテスト(xUnit系の話ではない)時に、loggerの行にブレークポイントを置いて調べるから、eをLogLogのメソッドに送る必要性をまったくわかっていないようだった。
実際にインストールして動作させて異常時にログから調査する、というばかばかしいほど当たり前のことに思いが至らないのだ。
至らないのを個人の責に帰することは、ばかげている。
至るシステムを考えるべきだ。
もちろん、悪いのはEclipseで、Eclipseマターな開発をしているからeを与えることに思いが至らないのだから、Eclipseが勝手に「, e」を補完してやれば良いのだ。
そのへんの中途半端な設計思想が嫌いだ。
ジェズイットを見習え |
これはEclipse関係ない気が。Eclipse脳でもそんな開発しません。ログ設計されてないことが問題で、さりげなくEclipse批判に論点を摩り替えるとか正直どーかと。<br><br>至るシステムを考えるべきだ→もちろん悪いのはEclipseで〜<br><br>つながらないですよ。
それもどうかと思いますよ。「ログ設計されていない」って、さりげなくここで例にしている開発チームに責任をすり替えてませんかねぇ。だって知らないでしょ?
このあたりは、Eclipseのcode templateの設定で、どうにでもなるんで、開発プロジェクトでは、デキるやつが、きちんとcode templateを作って、exportし、みんなに配布しないといけないでしょうね。逆に言えば、Eclipseって、デフォルトの設定に変なのが目につくってことですが。
それが正解(bestでなくてbetterだから、良解かな)ですね。> template
追加記事(というか本題?)が出てるのに今更ではあるんですが、<br>折角システムの問題、という視点が出ているのに一ツールの問題、という近視眼的なオチに持って行ってしまっているのはちょっともったいないかなと思いました。<br>優秀なartonさまと一緒に仕事をしておられるのですから、「彼ら」が「何も知らない阿呆の子」というのも考えがたいわけで、「一見馬鹿馬鹿しい行いが何故その現場での最適解になってしまっているのか」を考えた方がみんなが幸せになれるような気がします。<br>例えば「ログのフォーマットが厳密に決められていてスタックトレースの追加出力が許されていない」「異常を報告してくるチームからまともなログが提出されず、よくて先頭数十文字しかもらえない」等はよくある話ですし。<br>特に馬鹿馬鹿しいのは後者で、運用チームのログ監視/通報/トラブル管理ツールの制限で先頭1024バイトしか即時に確認出来ないであるとか、トラブル発生時の第一報がオペレータからの電話連絡で当該メッセージの一行目を読んで貰えるかどうかというレベル、なんてケースは実地に経験しましたね。
また、追加記事にてお書きになっておられたメソッドシグネチャの件ですが、やはりJava界隈ではよくある話のようで、記事中に名前を出しておられるひがやすをさまとその周辺の方々が数年前に同じようなことをネタとして語っておられたと記憶しています。<br>ちなみに当時のネタのオチは「それってハンガリアン記法では?」とかそういう感じだったかと思います。<br><br>個人的にはやはり皆さん同じところで引っ掛かって同じようなアイデアを閃くものなのだなあ、という感想を持ちました。<br>Ruby界隈で例えるならば、一時LL界隈でCOMが流行りかけたときの、「256倍本邪道編が何年前に出たと思っているのか?」という何ともいえない感慨というか。
最初のはログのフォーマットが厳格であっても、添付の型式でスタックトレースを別に出せばいいんじゃないんでしょうか。あるいは、調査コストとログフォーマットの変更コスト(あるいは運用ルールの変更コスト)で後者が大きいと判断できているなら、当然そのシステムではそれが正しいのでしょう。<br>実際に、その状況で「今更ながら」(できればこういうバカな名前はやめて欲しいな。ウンパ君とかボンゴ君とか、もっと人間らしい名前を選べば良いと思う。ツッコミフォームにも「お名前」と書いてあって「Subject」とは書いてないし)が成果を上げているわけだから、まったく問題ないように思えます。そこが開発中にエラーになりましただけのcatch節を見つけた場合に行う考察との相違です。<br>追加記事のやつは、大体3〜4年ほど前くらいのやつの蒸し返しですね。ここだとコード補完が山ほどメソッドを返すってのは20060209.html#p01あたりでネタにしてるし。ひさびさにJava開発に返ってきたら驚くほどIDEが普及しているのにインターフェイスがまったく旧態依然なのに驚いたということかな。
「通り眇めの老人」ってのはどうだろうか? 時代劇っぽくてかっこいいし、ちょっと斜に構えた感じがいかしているかも。
どうも。当コメント欄の#5と#6です。<br><br>いわゆる名詮自性を採用する人は多そうなものですが、artonさまがお気に召さぬとなればやむを得ませんので<br>改めてみましたがいかがでしょうか?<br>一応、私のなしたコメントは全て同一のE-mailアドレスが記録されているかと思います。<br><br>>ウンパ君とかボンゴ君とか、もっと人間らしい名前を選べば良いと思う。<br>>「通り眇めの老人」ってのはどうだろうか?<br>「諧謔が過ぎた」とお考えになったのか、「これでは伝わらぬ」とお考えになったのかはわかりませんが、<br>すぐさまお改めになったことは英明な行いと思います。<br><br>>「通り眇めの老人」<br>通りすがりで歳ばかり喰った割には何も見えていない私には存外似合いの命名で有り難いのですが、<br>ご遠慮しておきます。それは私の名前ではないので。<br><br>しかしまあ、「人間らしい名前」とのお言葉には少し考えさせられるものがありました。<br>いわゆる創氏改名も「人間らしい名前にせよ」「人間らしい名前を付けてあげよう」という善意が動機の発端だったのかもしれませんね。<br>(それは逆説的に命名する側の「人間」の定義を明らかにするものでもあるわけですが。)
さて、#5と#7についてですが、#5の本旨としては「一見馬鹿馬鹿しい行いが最適解となってしまうような制約が別にあるのではないか?」ということで、<br>#7でartonさまがおっしゃるような「制約があるから仕方ない」ではなく、「可能であるならば制約を廃する、あるいは緩める」ことで<br>「みんなが幸せ」になるのではないか?というものでした。<br><br>実は「別の制約」があるにも関わらず別の部分を「改善」してしまったときに、それが幸せな結果をもたらすかは丁半博奕のレベルかと思います。<br>例えば追加記事のような(これ自体はネタであるとしても)対策を実施してなお、コード補完で大変な思いをしてまで、開発チームが<br>logger.error("xxxでエラーになった");<br>を選び続けるといった事態が発生するとか。<br><br>#9の話と無理矢理こじつけますと、そのあたり、<br>「植民地人が氏名で差別されるそうだから新たに人間らしい名前を付けてあげよう」といった「誤った原因認識に基づく誤った対処」によって<br>本来救われるべき対象の人々が余計に苦難を抱え込むことになったような、「一面的な善意からの悲惨」を招くのではないかと<br>他人事ながらご心配申し上げている次第です。<br>まさに「今更ながら」のお話でございますが、長々と失礼致しました。
名前のことは、単に返事がしにくいって言ってるんじゃないかなポン
ご明察 >ボンゴ君。<br>ありがとう
ボンゴじゃないポン。ひどいポン
ごめんなさい。>ポンゴ君