私のソースコードの書き方 - @kyanny's blog
note.mu なるほど自分も同じような感じでやっているなぁ、と思った。もうちょっと詳しく書くと、 まず変更しようと思っている部分の周辺のコードを読んで、「ここらへんをいじればよさそう」と当たりをつける（当たりのつけかたにもいろいろあるのだが後述） 土地勘を養ったところで具体的な変更の仕方を考える。必要に応じて紙に下手くそな図を書いたり、考えを箇条書きにしたり、実際にコードを試しに変更してみたりする この方針でいけそう、と道筋が見えたらいよいよコードを書き始める。細かい単位でコミットするかどうかは場合によるが、少なくとも git add はこまめに行う（エディタの undo でせっかく書いたコードを失わないため） 道筋が見えなかったり、プロトタイプ的に書いたコードが望み薄そうだったら潔く諦める。煮詰まっていることを自覚して、コーヒーを買いにいったり、オフィスの外を散歩したりして頭をリフレッ
RubyKaigi 2015 - @kyanny's blog
二日目の夕方からと三日目の二コマ目から参加した。 この一年ほどは Ruby/Grape,Rails よりも CoffeeScript/Backbone,Marionette を書いてる時間の方が圧倒的に長く、仕事以外でも特に面白いものを作らなかったので、トークに応募しなかった。準備せず手ぶらで参加するだけのカンファレンスは、ラクだけどやっぱりどこか物足りないなと思った。もっとも、この冬の忙しさでは準備できたとも思えないが。 今年は「Ruby にこだわる」姿勢というものを感じるトークが多かった（自分が聴いたものの中では）特に mruby は、数年前に出てきたときは全然ピンとこなかったけど、今年はなぜか「Rubyist ならパフォーマンスが出ないからとかいって Go なんか選ぶんじゃなく Ruby でパフォーマンスを出す方法を考えるのが筋だろ？」と言われているような気がして身が引き締まる思いだ
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
