日記/2010/07/02/"Working Effectively with Legacy Code"読書メモ

ようやく読み終えました。日本語訳が出る前に購入してしまっていたので、折角なので原著のまま読破しようと挑戦したのですが、暇を見てダラダラ読んでいた為時間が掛かってしまいました。読書会で読み切った人達マジパネェっす。

ということで、読書感想文を「やるやらコンビ」でお送りします。

　　　　　　　　　＿＿＿
　　　　　　　／ ⌒　　⌒＼
　　　　　 ／　（⌒）　 （⌒）＼　　　やっと読み終えたお！
　　　　／ 　 ///（__人__）///＼　　　いやー、購入してから一年以上
　　 　 |　　 u. 　 `Y⌒y'´　　　 |　　　かけてダラダラ読んでしまったけど、
　 　 　 ＼ 　 　 　 ﾞー ′　　,／　　　　　　長かったお！
　　 　 ／　　　　　　　＿＿|__＿　　　　　さすが400p越しはパネェッス。
　　 　| 　　ｌ..　　　／l legacy　　`l
　　 　ヽ 　丶-.,／ 　|__　_code　 |
　　　　/`ー､＿ﾉ　／￣￣￣￣／


　　 ／￣￣＼
　／　ノ　　ヽ /＼'ｰ､　　　　　　　,, ..,､　　ウム。
　|　 （ ●）（ /　　.＼` ､　　 .　／／ /　　では早速レビューに・・・
.　|　　（__人/　　 　　＼ヽ､,.／／　../　　進みたいところだが、
　 | 　　 ｀ /　　　　　　　｀`７７　 　/　　amazonのレビュー内容を参照
.　 ヽ　　 /　　　　　 　 　 / /　　 /　　してくれれば問題ないだろJK。
　　 ヽ.. /　　　　　　ｆヽ、/ / , -,./　　実際msakamoto-sf自身の読感
　　　/./　　　 　r-､ ヽ　∨,ノ　/　　　　もamazonのレビューと大差ないしな。
　　　|. ＼　　　〈＼.＼,〉　｀,　 ｆ
　 　 |　.　＼　　(ヽ ヽ ｀..　　　|　　只、若干msakamoto-sf自身「この本どうなの？」
　 　 |　　 　.＼　＼　　　　 　ﾉ　ってゆー点もあったようだが。

　 　　　＿＿＿_
　　　／　　 　 　＼
　 ／　　─　 　 ─＼　　　　三行でkwsk。
／ 　　 （●） 　（●） ＼
|　 　　 　 （__人__）　 　 |
./　　　　 ∩ノ ⊃　　／
(　 ＼　／ ＿ノ　|　 |
.＼　“　　／＿＿|　 |
　　＼ ／＿＿＿ ／


　　　　　　　　　　 　 　 /7
　　 　 　 　 　 　 　 　 //
　　　　　　　　　　 　 //　　　１．(英語の)文章が読みづらい感じがする。
　　 　 　 ＿＿　 　 //　　　　２．技法の名前紹介と詳細説明が相前後
.　　　 ／ノ　ヽ＼ .//　　　　　　　しているため、真面目に追おうとすると
. 　 ／　（●）（●〉/　　　　　　　　行ったり来たりしてしまう。
　　l　 　 （__人_,//l　　　　　　３．とにかくページ数が多い。
.　　|　　 　｀⌒// ﾉ
　　 l 　 　 　 // ./
.　　 ヽ r-‐''7/）/
　 　　/　と'_{'´ヽ
　 　 /　 _.､__〉　ﾄ,
　 　 {　 ､＿_}　 |.i
　 　 ヽ　_,.ﾌ　　.|.|


　　　　　　　 ／￣￣＼　　　　「１．(英語の)文章が読みづらい感じがする」
　　　　　　 /　ヽ､_　　　＼　　についてだが、実際amazon.com側のレビュー
　　　　　. （　（● ）　　　　|　　でもお星様2つのレビューで「Hard to read, 
　　　　　. （人__）　　　　　 |　　annoying editorial errors」とあるから、
　　　　　r-ヽ　　　　　 　　 |　　英語ネイティブの人でも読みづらい感が
　　　　 （三） |　　　 　　　 |　　あることは確かなようだ。誤植もあるようだし。
　　　　　>　ノ　　　　　　 /
　　　　/ 　/ ヽ　　　　 /　　とはいえ、「テストコードの書きづらさ」という人間の
　　　/ 　/　へ>　　　 <　　主観や感情部分の記述も混ざるので、技術文書
　　　|＿__ヽ　　＼／　 )　　の竹を割ったような英語しか読まない
　　　　　　　|＼　　　／|　　msakamoto-sfには少しレベルが高すぎたかも知れない。
　　　　　　　|　 ＼_／　|


　　 ／￣￣＼
　／　　 _ノ　　＼　　　「２．」の相前後している、という点については
　|　　　 （ ー）（ー）　　構成上仕方ない点もある。テストコードを書く為の
.　|　　　　 （__人__）　　リファクタリング技法の詳細をPartIIIにもってきて、
　 |　　　　　｀ ⌒´ﾉ　　　状況別のcase studyをPartIIに持ってきた以上、
.　 |　　　　　　　ｎｌ^l^l　　PartII側でPartIIIに出てくる技法名を紹介するのは
.　 ヽ　　　　　 |　　 ﾉ　　仕方ない。
　　 ヽ　　　　ヽ　く　　しかし、最初から順を追って理解していきたい人には
　　　/　　　　　ヽ　＼　読みづらさとして受け取られかねないな。


　　　　 　＿＿＿
　　　　／　　 　　＼　　　「１」と「２」は分かったけど、
　　 ／　 _ノ ''　'ー　＼　　「３．とにかくページ数が多い。」っていうのは
　／　　（●）　 （●）　 ＼　　msakamoto-sfの単なるひがみじゃないかお？
　|　 　　　 （__人__）　 　　|　　本自体の評価とは関係ない気がするお・・・
　＼ 　 　 　｀ ⌒´　　　／


　 　／￣￣＼
　／　　 _ノ　　＼　　読みやすい文章でページ数が多いのは構わない
　|　　　 （ ●）（●）　　んだけどな。「１」でも挙げたが、読みづらい文章で
.　|　　　　 （__人__）　　ページ数が多いのは正直辛い。
　 |　　　　　｀ ⌒´ﾉ
.　 |　　　　　　 　 }　　なまじ豊富なPartIIのcase studyが仇となって、本書中
.　 ヽ　　　　　 　 }　　　もっとも「サクサク読める」PartIIIのリファクタリング技法
　　 ヽ　　　　　ノ　　ｍm　　の解説が325pから、というのは精神的に
　　　/　　　￣￣￣　つﾉ　　辛かったぞ。
　　　|　　　　|￣￣￣


　　　 ／￣￣￣＼
　　／　　　　　　　 ＼　　なるほど、正直確かにそんな感じはあったお。
　/　　　 ─　　　─　ヽ
　|　　　 （●） 　（●）　|
　＼　　∩（__人/777／
　／　　（丶＿//// ＼



　　　　　　 　　 ＿＿＿
　　　　　　　 ／　　　 　＼　・・・でも、それ以上にmsakamoto-sfが
　 　 　 　 ／　 _ノ 　ヽ､_　＼　　気になる点があった。
　 　 　 ／　 /⌒)　　 ‐=･=- ＼　　それを隠せると思ったかお？
　　　　 |::::::::/　/（__人__）:::::::::::::|
　　　　 ＼:/　/:::::ﾄｪｪｪｲ｀::::::::／
　　　　　　　　　　`―‐'



　　　　　 　／￣￣＼
　　　　　／　　 ⌒　　＼　　　・・・バレたか。
　　　　　|　　ﾐｨ赱､i .i_r赱
.　　　　　|　::::::⌒ （__人__）
.　　　　　|　　 　　ﾄｴｴｴｲ
.　　　　　ヽ　　 　　｀""´}
　　　　　　ヽ　　　　　ノ
　　　　　　　/　　　 く


　　　　　　　　 ／￣￣＼
　　　　　　　／　　 _ノ　　＼
　　　　　　　|　　 　（ ⌒）（⌒）　　確かに内容は素晴らしいんだよ、この本。
　 　 　 　 　 |　　 　　（__人__）　　レガシーコードをxUnitに組み込む手法や
　　　　　　　 |　　 　　 ｀ ⌒´ﾉ　case studyが、著者の実体験を元に書かれている
　 　 　 　 　 ,|　　 　　　　　 }　　のも評価出来る。
　　　　 　 ／ ヽ　　　　　　 }
　　　　　く 　く ヽ　　　　 ノ　　現場の技術者が、この本を読んでテストコードを
　　　　 　 ＼　`' 　　　 く　　書くきっかけや意欲を持つのも無理ないだろ。
　　　　　　　 ヽ、　 　 　 |
　 　 　 　 　 　 | 　 　 　 |


.　　　　　　　 ＿__
.　　　　 　 ／　―＼　　　けど、
　　　　 .／ノ　　(●)＼
　　　　 |　 ( ●) 　 ⌒)ｌ　　「テストコードを書くのはこれほど大変なのか」
　　　　 }　　　（_ノ￣　 i
　　　　 |　　　　　　 　 /　　という点が一番の障害だと思えるんだよな。
　　　　　＼　　　 　 _ノ　　オブジェクト指向に限らず、言語の機能を熟知し、
　　　　　　/´　　　　 `、　　インターフェイスを上手く分離して・・・って。
　　　　　 /　,＿__　 ,.　i　　　はっきり言って「入門者向き」のテクニックじゃない。
　　　　　（ ､＿＿⌒) ノ
　　　　　　ヽ、　i⌒i⌒i
　　　　　　　　　i　 i　 i＿
　　　.　　　　 　 ＼＿）＿）


　　　　　　　　　　　 ／￣￣＼
　　　　　　　　　　／ _ノ　 .ヽ、＼　　そんな、技術も知識も経験も必要な
　　　　　　　　　　|　 （●）（●）　|　　　「レガシーコードの改善」を、
　　　　　　　　　　|　　（__人__）　.|　　一技術者のモチベーションだけでどこまで
　　  　　　　　　　 |　　 ｀ ⌒´ 　ﾉ　　　現場で広め、やり通すことができるのか？
　 　 r─一'´￣`＜ヽ　　　　　　}
　 　 `ー‐ｧ　　 ,　 　 )　　　 　, -'~⌒ヽ、　　本当に難しいのは、そっちだろうな。
　　 　　 ノ　　　{. 　 ,ﾍ　　　　,l.　ゝ、_ .'ヽ).
 　 　 ／, ､　_　　　/. |　　 　.　',　　.　..　 .ヽ、
　　 （／ / // / /　...|　 　 　 ...|＼..＼＼ ＼_)
 　　 　 / // / /　　　　　　 　 . .　＼_＼_)､_）
 　　 　 ｰ' {_/ノ　　　　　　　　　 　 　　."´


　　　　　　　　　　　　　 ／￣￣＼　　　１．まずテストコードを書かなくてはならない。
　　　　　　　　 rヽ　　／　ノ　　＼ ＼　　２．テストコードを書く習慣を広める。
　　　　　　　　 i　!　　|　 （●）（●）　|　　３．テストコードを書けるように組織の技術者の
　　　　　 r;r‐r/　|. 　|　　（__人__）　 |　　　　レベルを底上げする。
　 　 　 〈_L (｀ヽ .}　　|　　 ｀ ⌒´　　ﾉ　　４．テストコードを書く作業を組織の開発
　　　　　l｀ （ ｀`/　.　 |　　　　　　　 }　　　プロセスに組み込む。
　　　　　ヽ 　　l　　.　 ヽ　　　　　 　}　　５．テストコードによる改善作業を「継続」する。
　　　　　　|,. 　 l　　 /⌒　 　ー‐　　ｨ ヽ


　　　　 　 ＿＿_
　　　　／　　 　 ＼
　　 ／　ヽ 　／　 丶　　　ウッ・・・確かにそう考えると、「実際の現場」
　 /　 （●）　（●）　ヽ　　「実際の組織」で浸透させるのが何よりも難しそうだお。
　 l::::⌒（__人__）⌒:::u:l
　 ＼　　|r┬-|　　 ／　　ベンチャーや少人数の組織で、独立性が高い場合は
　　/　　 `ー'´　　 ヽ　　ともかく、大規模なプロジェクトで適用するのは
　　し､　　　　　　 ﾄ､ﾉ　　大変そうだお。
　　　 |　　　_　 　 l
　　　 !___/´　ヽ___l


　　　　　　　　 ／￣￣＼
　　　　　　　／ 　 ⌒　　 ＼　　まぁアジャイルにせよ、XPにせよ、その辺の事情
　　　　　　（ へ）（ へ）　　｜　　は変わらないだろう。
　　　　　　.（__人__）　 　 　 |
　　　　　　　ｌ｀ ⌒´　　　　.｜msakamoto-sf個人としては、むしろプログラミングの
　　　　　　　{　 　 　 　 　 .｜　イロハとしてTDDを教えてしまった方が良いと思うんだな。
　　　　　　　{　　　　　 　＿ |
　　　　　　（ヽ、ヽ　　　/ 　）|
　　　　　　 |　｀`ー―‐'|　..ヽ|
　　　　　　 ゝ　ノ　　 　ヽ　 ノ
　￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣


　　　　　　　　　　 ＿＿＿　　　━┓
　　　　　　　　　／　―　　＼　 ┏┛
　　　　　　 　／　　(●)　 ＼ヽ ・　　　「イロハ」で教えるのかお？
　　　　 　　/　　 （⌒　　(●) /　　さっき「技術も経験も必要になる」って
　　　 　　 /　　 　 ￣ヽ__） ／　　言ったばかりじゃないかお？
.　　　　／´　　　　　_＿_／
　　　　|　　　　　 　 ＼
　　　　|　　　　　　　　|



　　　　　　 ., ──‐､　　　「TDD」やテストコードを書きやすいプログラムというのは
　　　　　 ／　　　　　＼　　「インターフェイス」や「委譲」がキーになるんだが、
.　　　 　.|　　　　 _ノ　　ヽ　　実際問題、インターフェイスや適切に委譲されている
　　　　　| 　　　 （ ●) (●)　　ソフトというのは一般的に「良い設計」と考えられる。
　　　　　| 　 　 　 （__人__） , -―ーっ
　　　 　　|　　　　 ｀ ⌒´ﾉ （ ゝ彡￣　インターフェイスや委譲、abstractやvirtual、
.　　　　　 ﾝ　　 　 　 　 } ﾞ|￣'|  関数ポインタの入れ換えやRuby/Python/JavaScript
　　　 ／⌒ヽ､ 　　　 ノ　 .|,　 |　で使えるOpenClassというのは、知識単独で学ぶと
＿＿/　　　ﾉ ＼_ィ ´ー‐ｨ'　　 ∫　「どこで使うの？」ってなるんだが、
| |　 /　　 /　　　　r_＿＿__ ∬　　　テストコードを書く時にフル活用することになる。
| |　/　　 /　 　 　 |i　　　 ┌‐┐
| | （　〆⌒'──r─≒､.（(| 　 |
￣￣￣￣￣￣￣￣￣￣└‐┘￣￣￣￣￣￣


　　　　　　　　 ／￣￣＼　　　OOPの習得が難しい、というのには、
　　　　　　　／ ヽ､.　_ノ　＼　　より良いOOPを書く練習が難しい点にあると
　　　　　　　|　 （●）（●）　|　　msakamoto-sfは考えている。
　　　　　　　|　　（__人__）　｜
　 　 　 　 　 |　　 ｀ ⌒´　　|　　ある程度フレームワークやライブラリを自分で
　　　　　　　 |　　　　　　 　}　　作ってみないと、「インターフェイス」や「委譲」による
　　　　　　　 ヽ　　　　　 　}　　　　OOPの効果を実感出来ない。
　　　　　　　　人＿__＿_ノ"⌒ヽ
　　　　　　／　　　　　　　　　　　＼　しかし現場でテストコードを書くことでも、
　　　　　/ 　　　　　　　　　　 へ　　＼　　そうしたOOPのコツを掴めるようになる筈だ。
　　　　 （　　ヽγ⌒)　　　　　| 　＼ 　 ＼
　￣￣￣＼＿＿／￣￣￣￣￣￣￣￣￣￣￣
　　　　　　　　　　　｛;;;;;;;｝
　　　　　　　　　　　 L;;;;」


　　　　　　＿＿＿＿
　　　　／　　⌒　　＾＼　　なるほど、テストコードを書くことは、
　　 ／　　（ ●） 　（●）　　　OOPを勉強する良い実地練習ということかお！
　／　　::::::⌒（＿人__）⌒ヽ
　|　　　　　　　|r┬-|　　　|　　それならイロハとして教えちゃうのも納得だお！
　＼ 　　 　 　　`ー'´　 ／


　　　　　　　　 ／￣￣＼　　　もちろん、新人一人に任せるのではなくて
　　　　　　　／ 　 ⌒　　 ＼　　ペアプログラミングというのが前提だろ。
　　　　　　（ ●）（ ●）　　｜
　　　　　　.（__人__）　 　 　 |　　UIやI/O、Socketが絡む部分などで依存性を
　　　　　　　ｌ｀ ⌒´　　　　.｜　断ち切ってxUnitに組み込むなど、「匙加減」や
　　　　　　　{　 　 　 　 　 .｜　「経験と勘」が必要な部分はあるからな。
　　　　　　　{　　　　　 　＿ |
　　　　　　（ヽ、ヽ　　　/ 　）|　そういう所は経験者がサポートして、ペアで
　　　　　　 |　｀`ー―‐'|　..ヽ|　　進めていくと良いだろ。
　　　　　　 ゝ　ノ　　 　ヽ　 ノ
　￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣


　　　　　 　／￣￣＼
　　　　　／　　 ⌒　　＼　　　OOPの勉強になるし、
　　　　　|　　ﾐｨ赱､i .i_r赱　　　依存性の低いインターフェイスはどちらにせよ
.　　　　　|　::::::⌒ （__人__）　　使いやすいことは間違いない！
.　　　　　|　　 　　ﾄｴｴｴｲ
.　　　　　ヽ　　 　　｀""´}　　組織の技術レベルとソフトウェアの品質、
　　　　　　ヽ　　　　　ノ　　　どちらも高めることができる一石二鳥の策だろ！！
　　　　　　　/　　　 く


　　 ／￣￣＼
　／　　 _ノ　　ヽ　　 .＿＿＿_　　　　いつまでも悲観的になっていても仕方ないお！
　|　　　（ ⌒）（⌒）／⌒　　⌒＼
.　|　　　　 （__人__） .（●） （ ●）＼　　新しいメリットも見出せたことだし、徐々に
　 |　　　　　｀ ⌒ﾉ ⌒（__人__）⌒:::::＼　　TDDが浸透していくと期待するだろ、JK・・・
.　 ヽ　　　　　 　} . 　　|r┬-|　　　 .　|
　　 .ゝ＿,. 　　ノ＿＿__`ー'´＿＿_.／
　-(＿＿_.)-(＿＿)＿__.)─(＿＿＿)─


　　　　　　　　　　　　 ＿＿＿_
　　　　　　　　　　　／⌒　　⌒＼　　　というわけで、TDDへのwktk感が止まらない
　　　　　　　　　 ／（ ●） 　（●）＼　　　そこの君、今すぐこのページTOPの
　　　　　　　　　｜:::::⌒（__人__）⌒::|　　　amazonリンクをクリック、
　　　　　　　　 　 | 　 ｢匸匸匚|　'"|ィ'　　レッツBUY！だろ！
　　　　, ヘｰ‐- ､ l 　｜ /＾''⌒|　　|　　　常識的に考えて！！！
　 -‐ノ .ヘー‐-ｨ ヽ 　!‐}_＿,..ﾉ　 ｜|
　''"/／ヽｰ､ 　ﾉヽ∧　`ｰ一'´　／　|
　 /／＾＼ 　ヾ-､ :| ﾊ 　￣　／　ﾉ　|
,ノ 　 ヽ,_　ヽノヽ_)ﾉ:l　'ｰｰ＜.　　/ 　|.
/　 　 <＾_,.ｲ `r‐'ﾞ :::ヽ 　＼　｀丶､ 　|
＼＿＿_,／|　 !　　::::::l、　　＼　　＼|


　　　　　 ＿＿__
　　　　／ヽ 　／＼
　　 ／（●）　（●）丶　　そこにオトスかお・・・。
　 /::⌒（__人__）⌒:::uヽ
　 l　　　 |r┬-|　　 　 l
　 ＼　　 `ー'´　　　／
　　/　　　　　　　　 ヽ
　　し､　　　　　　 ﾄ､ﾉ
　　　 |　　　_　 　 l
　　　 !___/´　ヽ___l