リファクタリングのいつ - ひげろぐ
リファクタリングのタイミングはいつなのかという問いについて。 ベストなのは開発と並行して。 書いたばかりのコードはリファクタリングしやすい。 時間が経つほど内容を忘れていくのでリファクタリングしにくくなる。 ありがちなのは「時間が余ったらリファクタリングしよう」 時間は得てして余らないものなので、リファクタリングの機会は永久に来ない。 リファクタリングは余った時間でするものではない。 むしろ時間を余らすためにリファクタリングすると言ってもいいくらい。 リファクタリングによってコードがシンプルで修正しやすい状態に保たれるため、開発スピードを保つことができるからだ。 （という口車を使ってリファクタリングの時間を確保しよう！） リファクタリングは「外部から見た振る舞いを変えずに実装を変えること」なので、振る舞いを変えるものを「リファクタリング」とは呼ばない。それは単なる「修正」。 リファクタリン
テストコードのリファクタリング - ひげろぐ
TDDBC 福岡2でのTDDの失敗ケースとは何かという質疑応答から。 テストコードにもリファクタリングが必要 昔はテストコードがメンテ対象であるという意識が薄かった 見てすぐ分かるテストコードがよいという考えからコピペコードが非常に多かった テストコードがたくさんあることによって動きが取りづらくなり、変更コストも上がる 素早く動きたいがためにTDDしているのにそんな皮肉な結果になってしまう たくさん書くのではなく必要十分書くことが大切 書き散らすと「テストケース爆発」を起こす テストコードもメンテし続けるためにリファクタリングして行く必要がある テストコードもプロダクトコードと同じようにテストのGreenの状態が維持されていることで、既存のコードが壊れないことを保証しつつリファクタリングしていくことができる。 （ただしテストが無条件でオールグリーンになるみたいな酷い壊し方をしてしまう心配は
Railsじゃなくてもマイグレーションを使えるStandaloneMigration - ひげろぐ
Rails等のフレームワークを使っていないプロジェクトでマイグレーションを使いたい時にはStandaloneMigrationが使える。（Ruby以外のプロジェクトでも使える。動かすにはもちろん要Rubyだけど） thuss/standalone-migrations – GitHub これを使わなくてもActiveRecordを使って自前でいろいろ書けばできるが、そういういろいろの面倒を見てくれるので楽ができる。 インストール gem install standalone-migrations 又はbundlerを使ってもいい。 というか環境を移すことを考えるとbundlerを使ったほうがいいですよね。 Rakefileの修正 以下のコードを追記。 begin require 'tasks/standalone_migrations' rescue LoadError => e puts
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
