| 15 |
プログラミングを始める。何もわからずひどいコードのパッチワークで半端なものすらできない |
| 16 |
自分のコードがひどいことはわかるのだがどう改善すればいいかわからない状態 |
| 17 |
デザインパターンやテストの概念とともにリファクタリングの概念と出会う |
| 17 |
Eclipseの自動リファクタリング機能に衝撃を受ける。リファクタリングの威力を初めて実感 |
| 18 ~ 24 |
リファクタリングを自動テストやOOPなどと組み合わせつつ実践 |
| 24 |
就職。最初に入った現場でリファクタリングがまったく実践・考慮されておらずひどいコードがそのまま放置されていることに衝撃 |
| 25 |
自分が初期から書いていないプロダクトでレビューの文化(仕組み)がなく自動テストもない場合、よそ者がリファクタリングするのは非常に困難だと実感。またリファクタリングの価値を説明できず理解してもらえなかったことにも失望 |
| 25 |
継続的にリファクタリングを試みるが主に本番稼働しているコードを変更することへの恐怖・リスクからチーム内で同意が得られない。それらを自分たちで書いたメンバーはコードの構造の特殊な癖も十分に理解しており改善に対するインセンティブが薄かった |
| 26 ~ 27 |
新規プロダクトでたくさんのコードを書く。納期優先でひどいコードも量産。リリース後にリファクタリングを行ったが構造が複雑でテストがあってもリファクタリングが劇的には進まず、そもそもそのプロダクトに関して改修案件が全く来ずコード改善の効果が低かった。この辺でリファクタリングの価値について疑問を持つ |
| 2x |
ファウラーだかの言葉で「リファクタリングするより1から作り直したほうが早いときはそうするべき」というものに衝撃を受ける。それまでどんなにひどいものでも作り直すよりかはリファクタリングしたほうが早いと思っていたのだが、基本設計がひどい場合はリファクタリングでも改善できない、そういったケースがあることを初めて認識する(それまでリファクタリングは良くないコードに対する銀の弾丸だと思っていた) |
| 2x |
確率的に犠牲的 - steps to phantasien ここらへんからもリファクタリング・改善一度ではないのだなと認識 |
| 2x |
(これもファウラーかIDDDあたりだったはず) 良いものを作るには最初から正しく作らないとだめだ1という主張を読む。今までのプロダクト開発を振り返るに否定する材料がない。リファクタリングを無力に感じる |
| 30 ~ 31 |
自分の書いた新規コードと過去のメンバーが書いたコードが混在するプロダクトで、リファクタリングとコード修正のサイクルが初めてまともに回る。これはPull Requestの仕組みでレビューが制度化されたこととリファクタリングについての共通認識をチーム内で醸成できたこと、そしてなにより機能追加や改修の前にその地ならしとしてリファクタリングをするというやり方がチームへ受け入れられたことが大きいと思っている。一方で開発したプロダクトは商業的には成功せず、このときリファクタリングなんてかなぐり捨てて新規機能開発へ全力を注いだほうが組織としては価値があったのではないかという疑念は残った |
| 32 |
リファクタリングは相変わらず大好きだが年をとってステークホルダーへ説明責任を果たす役割が増えた今、その価値をどう説明するか、リファクタリングをどう活かすかについて悩んでいる |
