タグ

あとで読むとテストに関するamigogrjのブックマーク (2)

  • 達人プログラマーに学ぶ 絶え間ない結合化と容赦ないテスト | Act as Professional

    書いたコードの量が増えれば、増えるほど、比例してバグが増えていきます。 予期せぬバグはスケジュールに致命的な影響を与える。 手を加えたソースの量が増えてからバグを特定するのには多くの時間や労力を費やすことになります。 達人プログラマーはどうするのか?p.241 第8章 達人のプロジェクトより 早めにテスト、何度もテスト、自動でテスト 書いたコードが少ない段階で、少ないテストをして、小さなバグをできるだけ早く解決していく。製品コードとテストコードを同時に書いていくのです。仮にバグを埋め込んでしまったとしても、バグになっている箇所はすぐに特定できるでしょう。 このテストをあながた手を動かしてやっている暇はありません。 あなたは新たなバグを埋め込むために製品コードを書かなければなりません。絶対に自動化しましょう。 自動化してテストを何度も、何度も、繰り返しおこなえるようにしましょう。結合テストも

    達人プログラマーに学ぶ 絶え間ない結合化と容赦ないテスト | Act as Professional
  • 達人プログラマーに学ぶ リファクタリング | Act as Professional

    ガーデニングのメタファーはソフトウェア開発の現実にかなり近いものです。あるルーチンが大きくなりすぎたり、色々なことを実現しようとしすぎている場合、2つに株分けする必要があるのです。また、計画通りうまくいかないものは雑草を抜いたり剪定してやらないといけないのです。 こういったコード記述のやり直し、再作業、再設計を総称して「リファクタリング」と呼びます。 リファクタリングのきっかけ DRYの原則に反している 直交していない設計 時代遅れの知識をつかっている パフォーマンスがわるい クラス、メソッドが長い 名前がしっくりこない 同じようなコピペコードがいくつも見られ、UIを直すとロジックを直して、DBもなおすとか。非推奨のメソッドを使っていたり。ループ分が多いし、やってることとメソッドの名前があっていないとか。みなさんも、思い当たるようなことはありませんか? タイミングとガン細胞の切除 きっかけ

    達人プログラマーに学ぶ リファクタリング | Act as Professional
  • 1