クソコード、あるいは技術的負債 - 時計を壊せ
クソコードについてここ数日で考えたことを書いてみる。 技術的負債まわりのえらいひとたちの議論を眺めてて、技術的負債って言うとなんかプロっぽいけど、クソコードって言ったほうが示したいモノを素直に表してるし分かりやすいきがしてきた。 クソコードを書くなとは思わないけど、クソコードをいつまでも放置するのはやめようって思う。 クソコードは次なるクソコードを生み出すし、バグを隠蔽するし、メンテナンスコスト増大の悪循環のキッカケになるし、新人の教育上良くないので無くて済むならもちろんないほうがいい。 ただ、ギークな人たちを除いて、さらっと60点*1のコードなんて書けない。僕を含め大多数のエンジニアは自分自身が書いたクソコードをリファクタリングして60点以上のコードを目指すための時間が必要になる。 そのうえ、そういうコードを書いてもだいたい時間経過に伴って事情が変わって、60点のコードの挙動を壊さないよ
YAPC::Asia 2013 で ぼくがかんがえたさいきょうのMVC についてはなします #yapcasia - 時計を壊せ
YAPC::Asiaとは 日本で最大級の規模のPerlのカンファレンスです。Perlのカンファレンスですが運用、プロトコル、テスト等開発に関わる様々なトークがあり、和気あいあいとした雰囲気でときには意識高い話もしつつ、ゆるふわにPerlとその周辺技術等への学びや発見を得る事が出来ます。詳しくは http://yapcasia.org/2013/ をどうぞ。 今回、ありがたい事に僕が応募していたトークを採択して頂きました。 ぼくがかんがえたさいきょうのMVCとは 下のリンク先をご覧下さい。 http://yapcasia.org/talk/show/f60b8522-d43e-11e2-ac80-4cc16aeab6a4 ではちょっとさみしいのでこのトークを応募した経緯を書いてみます。 僕は仕事でソーシャルげーむを作っています。ソーシャルゲームは若干特殊な部分はありますが基本的には普通のWe
間接オブジェクト記法の怪 - 時計を壊せ
怖い話 友人がこんなコードがうまく動かなくてハマっていました。 擬似コード use strict; use warnings; # ... sub hogemethod { # ... try { A; } catch { die $_; #(comment out) # ... }; # ... } # ... 1; このコードはtryの中で死ぬかもしれない処理Aをして、catchでエラーを受け取ってそのままdieする処理に見えます。 しかし、実際はtryを実行し終わったあと、catchも実行されてしまいます。 tryの中の処理が成功した場合はcatchは実行されない筈ですよね？ なぜ実行されてしまうのでしょうか。 答えは、Try::Tinyをuseしてなかったからです。 「じゃあ当たり前じゃん」と思った人はそのままブラウザバックするか、こんな時間にこんな記事読んでないで寝ると良いでしょ
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
