レガシー コード 改善 ガイド。 レガシーコード改善ガイド 第一章

bmf

レガシー コード 改善 ガイド

始めに 本書ではレガシーコードを テストがないコードと定義しています。 コードの綺麗さ、オブジェクト指向か、カプセル化されているかなどは関係ありません。 何故なら、ソフトウェアは変更されるものであり、テストがない限り変更が正しく行われたかどうかはわからないからです。 これは綺麗なコードや優れた設計は価値がないということはなく、むしろ有益です。 しかし、大規模な変更をするときはそれだけでは不十分で、より安全で安心な変更をするために必要だということで、このような定義をしています。 第1部 ここでは主にソフトウェアの変更に置ける問題点を、テストでどのように解決するかを述べています。 例えば単体テストがあり、それを動かしながら修正をすることで、フィードバックを受けながら作業を進めることができます。 リファクタリングがうまくいっていることができます。 テストが失敗すると、エラーの箇所の特定が早く行えます。 また、レガシーコードを扱うためのツールの紹介や、レガシーコードにテストを入れるとき、どのように見るべきについて述べています。 第2部 実際にレガシーコードを変更するときに起こりうる様々な問題に対する対処法が多く書かれています。 例えば、 ・時間がないのに変更しなければならない ・いつまでも変更が終わらない ・何をテストすればいいかわからない ・クラスが大きすぎる ・同じコードをいろんなところで変更している ・何も改善できない などなどです。 第3部 ここでは依存関係を排除する手法についてを紹介しています。 通常のリファクタリングと違うのは、テストがないコードにテストを整備することを目的にしていることです。 紹介されている手法は、 ・パラメータの適合 ・メソッドオブジェクトの取り出し ・グローバル参照のカプセル化 などです。 これらの手法の中に、カプセル化に反するものもあるため、二の足を踏む人もいるかもしれませんが、提案手法を適用して保守性をあげた上で、再度リファクタリングを行えば、設計を綺麗にすることもできます。 まとめ レガシーコードの定義が厳しく思いましたが、読み進めていくと、うなづける点が多くありました。 特に、テストを動かすことで、フィードバックを受けながら作業をするのは心理的安全を得ることに効果があるように感じました。

次の

『レガシーコード改善ガイド』討論・品評会 #1 #lckaizen

レガシー コード 改善 ガイド

頂きまして、ようやく一通り目を通したので書きます。 ありがとうございます。 どこを切り取っても話題の中心に置ける、そう言う本でした。 ざっくりどんな本かと言うと 原著「Beyond Legacy Code」が2015年とそこそこ新し目の本ではありますが、目新しいことは書いていません。 見たことも聞いたこともないようなものは書かれていませんでした。 プティス自体は目新しくはないですが、プティスの出自や必要とされた背景、実践における戦略などに焦点が置かれている点は目新しいと言えます。 この本の価値は様々なプティスから9つだけピックアップされていること。 少ないことに価値があります。 数を絞った上で個々の背景をしっかり書いたものになっています。 タイトルの「脱却」はレガシーコード改善ガイドのような既存のレガシーコードとの戦い方を彷彿とさせますが、帯には「レガシーコードを初めから作らない」と新規プロジェクトの序盤のように取れることが書かれています。 実態は レガシーコードを産み育てる土壌がターゲット で、フェーズに関係なく参考にできる内容となっています。 本書2章に「本物の虫と同じように、バグには繁殖に最適な条件がある。 」とありましたが、レガシーコードも同じでしょう。 土壌改善なので、別に序盤でしかできないものでも、既にレガシーコードが存在していないといけないものでもありません。 流石にプティス9の「レガシーコードをする」はレガシーコードが存在しないとできませんが。 面白いのが「人が一度に記憶できるのは7プラスマイナス2個」という数へのこだわり。 副題にある「ソフトウェアの寿命を延ばし価値を高める9つのプティス」は当然9つなのですが、各プティスの「実践しよう」には7つの戦略が2セットぶら下げられています。 例えば。 5章 やり方より先に目的、理由、誰のためかを伝える• プロダクトオーナーのための7つの戦略• より良いストーリーを書くための7つの戦略• 6章 小さなバッチで作る• ソフトウェア開発を計測する7つの戦略• ストーリーを分割する7つの戦略 といった感じ。 目次に無い物としては12章に6つの「変更を難しくするプティス」があるなど。 (戦略の方は無理矢理増やした感のあるものがないとは言わないけれど。 ) たぶん読まなくていい方 新しい知識が欲しい方で、ある程度の読書家な方。 たとえば以下の本のほとんどを読了しかつ実践されている方が新しい手段を求めて読むと、イマイチという感想になると思います。 (参考文献に上がっているもののうち私が読んだことがあるもので、内容のリンクが強いと感じたものを選びました。 入門やも参照されていますが、それらはそこまででもないかなって。 ) あと、って文字を見るだけアレルギー反応が出るような方も読まなくていいと思います。 徹頭徹尾プティスです。 たぶん読んだらよさそうな方 伝聞や表層だけのなんちゃってに騙されて(言い方が悪い)上手くいかず、を仕事では役に立たないおもちゃのように感じている方。 読めば誤解が解ける可能性があります。 知識や実践を通じた理解は十分でも、自分の考えの整理などを改めてしたい方。 プティスと原則の話あたりを踏まえて、個々のプティスや戦略を読んでいくといい整理になるんじゃないでしょうかね。 おさえてないところや捉え方の違いなどもあって、いい壁打ちになると思います。 あまり知識がなかったり、経験の浅い方。 冒頭で書いたように様々なプティスから9つだけをピックアップした、新設の高速道路です。 掘り下げの方向は違いますが、サイズや値段的にも達人などの古典・鈍器本に対するリーダブルコードのような印象。 鈍器本に抵抗があるなら是非。 蛇足 タイトルを見た時の感想は「またレガシーシリーズか」でしたね。 とはいえ訳者の方々が方々なので期待せざるをえず、そればかりか頂けてしまったのでこうして読んだわけです。 で、読んでみたらこれが面白くて仕方がない。 第一部の導入が良すぎて、そのノリで第二部のプティスを読むとどこまでも潜っていくことになりました。 時間かかるの仕方ない。 本当はもう少し早くブログ書きたかったんですが、いちいち考えちゃってツイートしたりしちゃって、いつ読み終わるかわからない感じになってしまった。 いやページ数の割に考えられるネタ多過ぎるんですよ…… あと、Beyondの意味とか一通りみて考えてみたのですが、脱却以上にしっくりくるものは思いつかず……レガシーコードを超えて?レガシーコードの向こう側に??うーむ、やっぱ脱却が合ってそうだなぁ。 いくつかは私のこれまでのブログやセッションで話したことがほぼそのまま(少なくとも私にはそう見える)書かれていたり、今書いてる途中のブログとネタ被りしてるものとかもあって(近いうちに公開)。 参考文献の傾向とか見ればそれはそうなんだろうって感じではあるんですが、なんか勝手にシンパシー感じたりしてました。 とりあえずもう一回読みます。 irof.

次の

[書評]レガシーコード改善ガイド|curshey|note

レガシー コード 改善 ガイド

始めに 本書ではレガシーコードを テストがないコードと定義しています。 コードの綺麗さ、オブジェクト指向か、カプセル化されているかなどは関係ありません。 何故なら、ソフトウェアは変更されるものであり、テストがない限り変更が正しく行われたかどうかはわからないからです。 これは綺麗なコードや優れた設計は価値がないということはなく、むしろ有益です。 しかし、大規模な変更をするときはそれだけでは不十分で、より安全で安心な変更をするために必要だということで、このような定義をしています。 第1部 ここでは主にソフトウェアの変更に置ける問題点を、テストでどのように解決するかを述べています。 例えば単体テストがあり、それを動かしながら修正をすることで、フィードバックを受けながら作業を進めることができます。 リファクタリングがうまくいっていることができます。 テストが失敗すると、エラーの箇所の特定が早く行えます。 また、レガシーコードを扱うためのツールの紹介や、レガシーコードにテストを入れるとき、どのように見るべきについて述べています。 第2部 実際にレガシーコードを変更するときに起こりうる様々な問題に対する対処法が多く書かれています。 例えば、 ・時間がないのに変更しなければならない ・いつまでも変更が終わらない ・何をテストすればいいかわからない ・クラスが大きすぎる ・同じコードをいろんなところで変更している ・何も改善できない などなどです。 第3部 ここでは依存関係を排除する手法についてを紹介しています。 通常のリファクタリングと違うのは、テストがないコードにテストを整備することを目的にしていることです。 紹介されている手法は、 ・パラメータの適合 ・メソッドオブジェクトの取り出し ・グローバル参照のカプセル化 などです。 これらの手法の中に、カプセル化に反するものもあるため、二の足を踏む人もいるかもしれませんが、提案手法を適用して保守性をあげた上で、再度リファクタリングを行えば、設計を綺麗にすることもできます。 まとめ レガシーコードの定義が厳しく思いましたが、読み進めていくと、うなづける点が多くありました。 特に、テストを動かすことで、フィードバックを受けながら作業をするのは心理的安全を得ることに効果があるように感じました。

次の