Michael Feathers - Characterization Testing
Characterization Testing Writing tests to describe and fix existing code I think that the most confusing thing about testing is the word testing. We use it for many things, from exploratory testing and manual testing to unit testing and other forms of automation. The core issue is that we need to know that our code works, and we’ve lumped together a variety of practices and put them under this ban
「絶対要らないハズだけど、なかなか削除できずにいるもの」を対応した小話 | メルカリエンジニアリング
はじめましてこんにちは。SREの@masartzです。 私は最近joinしたのですが、今回は本番環境に古くからあるテーブルの掃除作業をした案件をご紹介します。 tl;dr; 本番の住所情報テーブルを消したけど問題なかった話 絶対要らないハズだけど、なかなか削除できずにいるもの を対処する話 本番環境の住所情報テーブルをdropするまでの作業 今回、本番環境の住所情報テーブルをdropしました。 と言っても、事故でもうっかりでもなく、既に使われていなかったものの整理という作業でした。 何故使われていなかったかというのは、メルカリの住所情報の保持の仕方の変遷が関係しています。 初期にはuser情報と住所情報は1対1の関係でした。イメージとしては以下です。 CREATE TABLE IF NOT EXISTS users ( id INT UNSIGNED NOT NULL, name VARC
デッドコードは取り除かなければならない
デッドコードは、見つけて、取り除く必要がある。デッドコードを残しておくと、プログラマの理解と行動を妨げることがあり、コードが実行されて、重大な問題を引き起こすリスクもある。 デッドコードの削除は、技術的な問題ではない。Kevlin Henney氏によると、それは考え方と文化の問題だ。 独立したコンサルタントでトレーナであるKevlin Henney氏が、ヨーロッパテストカンファレンス 2017において、基調講演「やり方の間違い」を行った。この基調講演で、デッドコードが実行されたために、ある企業が何億ドルもの損害を被ったことを発表した。 InfoQは、このカンファレンスをQ&A、要約、記事で扱う。 ソフトウェアの失敗は、個人的に不便だったり、迷惑だったりするが、経済的、または、社会的に重大な影響を与えることもある。Henney氏は、小さな不具合のせいで、何百万ドルもの損害を出した例をいくつか
技術的負債の返済 – レガシーコードをリファクタリングで救うには | プログラミング | POSTD
レガシーコードをうまく手なずけて、もう一歩成熟させるにはどうすればいいのでしょう？この投稿では、大規模なレガシーウェブアプリケーションと格闘してきた私が学んだことを紹介します。レガシーコードをうまく手なずけて 、もう一歩成熟させるにはどうすればいいのでしょう？この投稿では、大規模なレガシーウェブアプリケーションと格闘してきた私が学んだことを紹介します。 レガシーコードはリファクタリングで救出可能 耳寄りなお知らせがあります！ リスたちは毎年何千本もの木を植えてくれています 。まあ自分たちが隠したドングリのありかを忘れてしまった結果ですけどね。そしてもうひとつ。 あなたのプロジェクトも救出できる のです。 ボスから任されたプロジェクトが どんなに醜い泥まみれのレガシーコードだったとしても 、そこには 必ず 道があります。道は曲がりくねっていて、木陰にはモンスターが待ち構えていることでしょう。
無事です - Backnumbers: Steps to Phantasien
2011-03-12 近況 無事です. はいいとして, 先週 Shibuya.js で話してきました (スライド). 空気をよまず JS と無関係の話をしてしまいやや申しわけなかったけれども, WebKit の様々な幻想をぶちこわす開発の様子を知ってもらうことには個人的な使命感を感じておりつまりこれはちょっとした十字軍なのです. JS のテストってなんでむずかしいの? 地震さわぎで自宅警備中の人も多いだろうから, お互いの気晴らしをかねてだらだら書きたい. JavaScript のテストについてぐぐったりついったを読んだりしていると, JavaScript でテストを書くのは大変だとか難しくてやってないという話が多くて不思議におもった. 私は JavaScript を使ってウェブアプリを作る仕事をしたことがなく, いまいち難しさがピンとこない. 趣味でさわっている範囲だと普通に書ける. な
sexyhook 接合部作成ライブラリ - お前の血は何色だ!! 4
夏から構想をねり作り始めていたAPIフックや関数書き換えによる接合部を作成するライブラリが取り敢えず動くようになったので公開します。 #まだまだ不安定ですが ダウンロードはこちらから↓ http://code.google.com/p/sexyhook/ イントロダクション time()関数をライブラリの中に書いてあるので、失敗ルーチンのテストが書けない。。。 //2000年以上か？ bool isOver2000year() { //現在動かしたら、絶対 TRUE にしかならない return time(NULL) >= 946652400; //2000-01-01 00:00:00 } このルーチンを検証するのには、PCの時計を変更しないとだめ。 うーん、めんどくさい。 テストルーチンの時だけ、一時的に time() を昔に戻せないだろうか。 そんなことで困ってませんか？ { //現
日記/2010/07/02/"Working Effectively with Legacy Code"読書メモ - Glamenv-Septzen.net
ホーム 検索 - ログイン | | ヘルプ 日記/2010/07/02/"Working Effectively with Legacy Code"読書メモ ようやく読み終えました。日本語訳が出る前に購入してしまっていたので、折角なので原著のまま読破しようと挑戦したのですが、暇を見てダラダラ読んでいた為時間が掛かってしまいました。読書会で読み切った人達マジパネェっす。 ということで、読書感想文を「やるやらコンビ」でお送りします。 ＿＿＿ ／ ⌒ ⌒＼ ／ （⌒） （⌒）＼ やっと読み終えたお！ ／ ///（__人__）///＼ いやー、購入してから一年以上 | u. `Y⌒y'´ | かけてダラダラ読んでしまったけど、 ＼ ﾞー ′ ,／ 長かったお！ ／ ＿＿|__＿ さすが400p越しはパネェッス。 |
テストを書くこととテストをすることの違い - 未来のいつか/hyoshiokの日記
会社でレガシーコード改善ガイドの読書会をやっていて、次回で読了だ。4月に入ってから週に1回くらいのペースでやっていて、2ヶ月半くらいかかった。途中、ゴールデンウィークや所用で開催しないこともあったので、１０回くらいで完走したことになる。 一人当たり、1章ないし2章くらいを担当して、その章に書いてあることを説明した後にみんなであーだこーだ議論をする。気になったことを質問したり、どうも良く分からないことをみんなで考えたりする。 テストがないコードはレガシーコードだ！というキャッチフレーズはわたしの心をとらえた。 参加者の皆さんとその価値観を共有できた事はうれしい。 現場での開発の実情をいろいろ教えてもらった。テストを書くことはあまり一般的ではないということにわたしは衝撃を覚えたのであるが、この読書会を通じて、テストを書かない開発というのがレガシーコードを作っている事に他ならないという共通の認識
17. My Application Has No Structure - WORKING EFFECTIVELY WITH LEGACY CODE (WEwLC) - higepon blog
Working Effectively With Legacy Codeの 17章 My Application Has No Structure。 マインドマップから再構成したまとめ 僕のアプリには構造なんてないよ 構想を理解しないと コードの追加が大変だよ コスト高いよ 構造を理解する方法 ストーリーを語る システムの一番重要なことをシンプルに相手に説明する 相手は前提知識がないことを想定する 効果 何が重要なのか？を考える良いきっかけになるよ 迷ったときの指標になるよ 抽象化しているのと同じだよ CRC(Class Responsibility and Collaboration) クラス名 役割 コラボレータ（このクラスとコミュニケーションするもの） Naked CRC を試そう デザインについての会話を聞く コードとデザインがずれていたら？ 「共有するコンセプトをコードに反映でき
『レガシーコード改善ガイド』 - 真 もわ爛漫
http://www.amazon.co.jp/gp/product/4798116831/mowanetjp-22 原著 "Working Effectively with Legacy Code" が出版されたのは2004年。5年間訳書が出なかったことによってただでさえ遅れている日本は更に5年遅れた。 本著のレガシーコードの定義は明確だ。 私にとって、レガシーコードとは、単にテストのないコードです。 本著が「レガシーコード」を「改善」する「ガイド」であれば、それはつまり「テストのないコード」を「改善」する「ガイド」という意味になる。Straightforward. これは非常に重要なことだ。 つい最近私が手がけていた(そしてまだメンテナンスしている)コードにはテストがなく、効率は悪く、そして間違っていた。一方で、そのコードは本来の技術仕様外のケースをハンドルするコードがはっきりとif文
第1回 レガシーコード前夜 | gihyo.jp
はじめに 「レガシーコード」――この言葉を聞いて何を思い浮かべますか？ もしかしたら、COBOLで書かれたコード、Windows NT 4.0用のコード、書いた人がわからなくなってしまったコードなどが思い浮かぶかもしれません。 しかし、このレガシーコードをメインテーマとして正面から扱っている書籍『Working Effectively with Legacy Code』（WEwLC ※1）では、レガシーコードについて異なった見解を示しています。そう、「明日自分の書くコードもレガシーコードになるかもしれない」というWEwLCが発するメッセージは、私たちに切実に迫ってくるのではないでしょうか。 この連載では、WEwLC読書会の有志が、WEwLCが語りかけるものや、現実の課題への活かし方などを対談形式で紹介していきます。この本が発するメッセージについては連載の中でおいおい明らかにしていきたい
レガシーコード改善ガイド - wyukawa's diary
レガシーコード改善ガイド (Object Oriented SELECTION) 作者: マイケル・C・フェザーズ,ウルシステムズ株式会社,平澤章,越智典子,稲葉信之,田村友彦,小堀真義出版社/メーカー: 翔泳社発売日: 2009/07/14メディア: 大型本購入: 45人 クリック: 673回この商品を含むブログ (157件) を見る ちょっと難しいがこれは良書を超えて名著と言わざるを得ない。その理由は以下の３つ。 類書が無い 実践的なノウハウが記載されている 行間からレガシーコードに取り組む人に対するエールのようなものが感じられる １つ目は異論が無いだろう。 ２つ目は例えば依存関係の排除などはかなりページをさいて説明している。本書の中心的なテーマといえるだろう。それ以外にも仕様化テストは個人的に興味深かった。これはシステムの現在の振る舞いを調べ将来のデグレを防止することを目的とし、現在
L'eclat des jours(2009-07-13)
_ 7ページでわかるパターン、Wiki、XP 先日のジュンク堂トークセッションで、角谷&懸田コンビの掛け合いで、実は、7ページでこの本の内容がわかる秘密兵器として紹介されていたのが、クリーンコードのコプリエンの前書きだ。 いや、それデタラメじゃねぇか、とあらためて読んで思ったが、でも、確かにおもしろい点は突いている。 Clean Code アジャイルソフトウェア達人の技(Robert C. Martin) 一体、コプリエンは前書きに何を書いているのだろうか？ 印象深いのは、5Sだ。整理、整頓、清掃、清潔、しつけ。もちろん、クリーンコードという本の前書きなので、一言でまとめれば、「この本を読んで、きれいなコードを書きなさい」に尽きる。 これは、K&Kがetoさんからのアジャイルを始めるには何すれば良い？ という質問に対して、ちょっと考えただけで、「あいさつすること」と答えたことに通じるものが
あの「レガシーコード改善ガイド」が出るよ - 木曜不足
翔泳社さんから 7/14 に いよいよ出版される「レガシーコード改善ガイド」。 レガシーコード改善ガイド (Object Oriented SELECTION) 作者: マイケル・C・フェザーズ,ウルシステムズ株式会社,平澤章,越智典子,稲葉信之,田村友彦,小堀真義出版社/メーカー: 翔泳社発売日: 2009/07/14メディア: 大型本購入: 45人 クリック: 673回この商品を含むブログ (157件) を見る 昨年、原書の "Working Effectively with Legacy Code" を読書会に参加してずっと読んでいたが、その邦訳だ。 第２回 第３回 第４回 第５回 第６回(最終回) 読書会というと通常はもっとスローペースなのだろうけど、あのボリュームの洋書をわずか６回*1で読み切ってしまった。みんな続きが早く早く読みたくて興奮していた、のかもしれない。 で、この読書
「レガシーコード改善ガイド」のススメ 第2回：コードを理解するため、仕様化テストで文書化する
増え続けるレガシーコード この記事を読んでいる皆さんの多くは、これまでたくさんのシステム開発に関わってきたことでしょう。仕様変更と闘い、納期に追われ、やっとのことで稼働したシステムも数多いはずです。厳しい状況になればなるほど、実際にコードを動かすことが最優先になり、「コードを保護する」ための単体テストの整備は後回しになってしまいがちです。 ところが、システム開発はシステムが完成して無事に稼働した時点で終わりではありません。ユーザーが実際に使い始めると、保守開発としてさまざまな仕様変更や機能追加が発生するのが常です。それらに対応するためには、厳しいスケジュールの中で、やっつけ仕事で間に合わせたコードに対して改修や機能追加をする必要があります。では、このような仕事にどうやって取り組めば良いのでしょうか？ さて、前回の記事では、『レガシーコード改善ガイド』におけるレガシーコードの定義を紹介しまし
「レガシーコード改善ガイド」はもうすぐ発売 - m-takagiの日記
Working Effectively With Legacy Code の日本語版「レガシーコード改善ガイド」の発売日がいよいよ近づいてきました。 レガシーコード改善ガイド (Object Oriented SELECTION) 作者: マイケル・C・フェザーズ,ウルシステムズ株式会社,平澤章,越智典子,稲葉信之,田村友彦,小堀真義出版社/メーカー: 翔泳社発売日: 2009/07/14メディア: 大型本購入: 45人 クリック: 673回この商品を含むブログ (157件) を見る 原書の読書会で出版前の査読に参加させていただいたこともあり、日本語版が出るのを楽しみにしていました。翔泳社様から献本いただいたので一足お先に読ませてもらっているのですが、期待通りのできですなぁ。24章の『隣の新規開発の芝は、実はそれほど青くありません。……』とか、日本語で読んでも味わい深い。 頭から順に読んで
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
https://blog.8-p.info/2009/07/wewlc
「レガシーコード改善ガイド」のススメ 第3回：既存のコードに極力手を加えずに機能を追加する
开封料醚文化传媒有限公司
WEwLC の翻訳版「レガシーコード改善ガイド」が出るらしい - higepon blog
