Refactoring can be dangerous, to your program and to your health. In this episode we discuss techniques to enable safe and healthy refactoring methods.Show NotesStory time(Thomas) I used to have delusions of grandeur about my refactoring abilityAustin recent projectPurpose: to make the code betterThe challenge, how to do it so that:You don’t break things unintentionallyYou don’t get mired in the details and unable to move forwardIt doesn’t take foreverMethodCode is the way it is for a reasonIncrementalKeep a working versionDevelop in parallelContractsDon’t break contracts until you have a working replacementContracts are:between input and outputfunctionscomponentsinterfaceslibrariesBottom-upDon’t worry about code duplication until the endAvoid “second-system” effectTry to understand why the original system was created the way it was, don’t assume you know better, even if you doStory timeI’m working on a large refactoring project involving the inventory systemNo down-time, must be 100% accurateI’m building it:In parallel with the existing system until it proves to be a worthy replacementIncremental, developing and deploying many smaller pieces along the wayNOT as one large project that gets deployed all at once Support the show

Ver todos los episodios