Continuous Refactoring - Revision history

Kevlin at 18:33, 11 July 2009

Kevlin — Sat, 11 Jul 2009 18:33:16 GMT

←Older revision		Revision as of 18:33, 11 July 2009
Line 23:		Line 23:
	When refactoring you often encounter an epiphany at some point. This happens when suddenly all puzzle pieces fall into the place where they belong and the sum of your code is bigger than its parts. From that point it is quite easy to take a leap in the development of your system or its architecture.		When refactoring you often encounter an epiphany at some point. This happens when suddenly all puzzle pieces fall into the place where they belong and the sum of your code is bigger than its parts. From that point it is quite easy to take a leap in the development of your system or its architecture.

-	Some people say that refactoring is waste in the ~~lean~~ sense as it doesn't contribute to the business value for the customer~~. But it does so~~. Improving the design of the code is not meant for the machine. It is meant for the people ~~that~~ are going to read, understand, maintain and extend the system. So every minute you invest ~~know with your current knowledge earned about the codebase~~ in refactoring it to make it more intelligible and comprehensible is time saved ~~manyfold by~~ the ~~future poor~~ soul that has to deal with it. And the ~~saved~~ time ~~translated directly~~ to saved costs. When refactoring you learn a lot. I use it quite often as a learning tool when working with ~~unknown~~ codebases. Improving the design also helps spotting bugs and inconsistencies by just seeing them clearly now. Deleting code ~~(which often happens while~~ refactoring) reduces the amount of ~~LOC~~ that has to be cared for ~~for several years~~ in the future.	+	Some people say that refactoring is waste in the Lean sense as it doesn't directly contribute to the business value for the customer. Improving the design of the code, however, is not meant for the machine. It is meant for the people who are going to read, understand, maintain, and extend the system. So every minute you invest in refactoring the code to make it more intelligible and comprehensible is time saved for the soul in future that has to deal with it. And the time saved translates to saved costs. When refactoring you learn a lot. I use it quite often as a learning tool when working with unfamiliar codebases. Improving the design also helps spotting bugs and inconsistencies by just seeing them clearly now. Deleting code — a common effect of refactoring — reduces the amount of code that has to be cared for in the future.

	By [[Michael Hunger]]		By [[Michael Hunger]]

Kevlin at 18:09, 11 July 2009

Kevlin — Sat, 11 Jul 2009 18:09:25 GMT

←Older revision		Revision as of 18:09, 11 July 2009
Line 1:		Line 1:
-	Code bases that are not cared for tend to rot. ~~That does not mean they are converted into valueable soil.~~	+	Code bases that are not cared for tend to rot. When a line of code is written it captures the information, knowledge, and skill you had at that moment. As you continue to learn and improve, acquiring new knowledge, many lines of code become less and less appropriate with the passage of time. Although your initial solution solved the problem, you discover better ways to do so.
-	When a line of code is written it captures the information, knowledge and skill you had at ~~this~~ moment. As you ~~continually~~ learn and improve ~~and get to know~~ new ~~bits of information~~ many of ~~those~~ code ~~lines~~ become ~~more~~ and ~~more inappropriate~~ with the passage of time. Although your initial solution solved the problem you discover better ways ~~for doing~~ so.	+

-	It is ~~plainly~~ wrong to deny the code the chance to ~~evolve~~ with ~~your growing~~ abilities.	+	It is clearly wrong to deny the code the chance to grow with knowledge and abilities.

-	~~For the initial problem solving solution TDD is one very useful approach. It gives your~~ code ~~an environment (tests)~~ to ~~be executed in and validates that it actulally solved the problem (passing the tests). The design is driven implicitely~~ to ~~a testable state that has a higher design quality already~~. ~~But~~ you ~~shouldn't stop there. The TDD mantra is red-green-REFACTOR.~~	+	While reading, maintaining, and writing code you begin to spot pathologies, often referred to as ''code smells''. Do you notice any of the following?

-	~~So after solving your problem you must look at your~~ code ~~base from a wider perspective. How does it fit with your systems architecture,~~ the ~~programming model principles~~ (~~e.g.~~, ~~object oriented, functional, etc.~~)~~, the language idioms? How well is it integrated with existing code.~~	+	* Duplication, near and far
		+	* Inconsistent or uninformative names
		+	* Long blocks of code
		+	* Unintelligible boolean expressions
		+	* Long sequences of conditionals
		+	* Working in the intestines of other units (objects, modules)
		+	* Objects exposing their internal state

-	~~While reading~~, ~~maintaining and writing~~ code it ~~is quite~~ easy to ~~spot pathologies also known~~ as "code ~~smells" (releated by Kent Beck to bad baby smells)~~	+	When you have the opportunity, try deodorizing the smelly code. Don't rush. Just take small steps. In Martin Fowler's ''Refactoring'' the steps of the refactorings presented are outlined in great detail, so it's easy to follow. I would suggest doing the steps at least once manually to get a feeling for the preconditions and side effects of each refactoring. Thinking about what you're doing is absolutely necessary when refactoring. A small glitch can become a big deal as it may affect a larger part of the code base than anticipated.

-	Do you ~~notice things like:~~	+	Ask for help if your gut feeling does not guide you in the right direction. Pair with a co-worker for the refactoring session. Two pairs of eyes and sets of experience can have a significant effect — especially if one of these is unclouded by the initial implementation approach.
-	* duplication (near and ~~far),~~	+
-	* inconsistent or uninformative names,	+
-	* long pieces of ~~code~~	+
-	* unintelligible boolean expressions	+
-	* long sequences of ~~conditionals~~	+
-	* working in the ~~intestines of other units (objects, modules)~~	+
-	* exposing your internal state?	+

-	~~Your IDE may~~ help ~~you~~ with ~~this~~. ~~The code intentions they provide~~ offer a ~~good starting point as they are tailored to~~ the ~~language~~ and ~~sometimes offer quick fixes (dubbed ''~~refactoring ~~by example'' by Kent Beck)~~.	+	We often have tools we can call on to help us with automatic refactoring. Many IDEs offer an impressive range of refactorings for a variety of languages. They work on the syntactically sound parse tree of your source code, and can often refactor partially defective or unfinished source code. So there is little excuse for not refactoring.

-	If so you have ~~an opportunity to take action. Try deodorizing the smelly code. Don't rush. Just take small steps. And~~ keep ~~your tests~~ running so that you can easily see if you broke something. ~~In Martin Fowler's ''Refactoring'' the steps of the refactorings presented are outlined in great detail~~, ~~so it's easy~~ to ~~follow. I would suggest doing the steps at least once manually to get a feeling~~ for ~~the preconditions~~ and ~~side effects of each refactoring. Thinking about what you're doing is absolutely necessary when refactoring. A small glitch can become a big deal as it may affect a larger part of the~~ code ~~base than anticipated.~~	+	If you have tests, make sure you keep them running while you are refactoring so that you can easily see if you broke something. If you do not have tests, this may be an opportunity to introduce them for just this reason, and more: The tests give your code an environment to be executed in and validate that the code actually does what is intended, i.e., passes the tests.
-		+
-	~~Ask for help if your gut feeling does not guide you~~ in ~~the right direction. Pair with a co-worker for the refactoring session. Two sets of eyes~~ and ~~experiences can have a significant effect — especially if one of these is unclouded by~~ the ~~initial implementation approach.~~	+
-		+
-	~~Another great way to look for the target of your refactoring~~ is ~~design patterns. Although the original work by Martin Fowler et al does not mention design patterns very much~~, ~~the additional work of Joshua Kerievsky does a good job in discussing design patterns as goals for refactorings~~.	+
-		+
-	~~Fortunately in our time we have the tools available to help us with automatic refactoring~~. ~~Most IDEs offer an impressive range of refactorings that work on~~ the ~~syntactically sound parse tree of your source code (and so can even refactoring partially defective or unfinished source code). So there is no excuse for not refactoring~~.	+

	When refactoring you often encounter an epiphany at some point. This happens when suddenly all puzzle pieces fall into the place where they belong and the sum of your code is bigger than its parts. From that point it is quite easy to take a leap in the development of your system or its architecture.		When refactoring you often encounter an epiphany at some point. This happens when suddenly all puzzle pieces fall into the place where they belong and the sum of your code is bigger than its parts. From that point it is quite easy to take a leap in the development of your system or its architecture.

Michael Hunger: Continous Refactoring moved to Continuous Refactoring: title change

Michael Hunger — Tue, 16 Jun 2009 20:24:59 GMT

Continous Refactoring moved to Continuous Refactoring: title change

←Older revision

Revision as of 20:24, 16 June 2009

Michael Hunger: Ruthless Refactoring moved to Continous Refactoring: title change

Michael Hunger — Tue, 16 Jun 2009 20:17:52 GMT

Ruthless Refactoring moved to Continous Refactoring: title change

←Older revision

Revision as of 20:17, 16 June 2009

Michael Hunger at 10:49, 16 June 2009

Michael Hunger — Tue, 16 Jun 2009 10:49:29 GMT

←Older revision		Revision as of 10:49, 16 June 2009
Line 30:		Line 30:

	When refactoring you often encounter an epiphany at some point. This happens when suddenly all puzzle pieces fall into the place where they belong and the sum of your code is bigger than its parts. From that point it is quite easy to take a leap in the development of your system or its architecture.		When refactoring you often encounter an epiphany at some point. This happens when suddenly all puzzle pieces fall into the place where they belong and the sum of your code is bigger than its parts. From that point it is quite easy to take a leap in the development of your system or its architecture.
		+
		+	Some people say that refactoring is waste in the lean sense as it doesn't contribute to the business value for the customer. But it does so. Improving the design of the code is not meant for the machine. It is meant for the people that are going to read, understand, maintain and extend the system. So every minute you invest know with your current knowledge earned about the codebase in refactoring it to make it more intelligible and comprehensible is time saved manyfold by the future poor soul that has to deal with it. And the saved time translated directly to saved costs. When refactoring you learn a lot. I use it quite often as a learning tool when working with unknown codebases. Improving the design also helps spotting bugs and inconsistencies by just seeing them clearly now. Deleting code (which often happens while refactoring) reduces the amount of LOC that has to be cared for for several years in the future.

	By [[Michael Hunger]]		By [[Michael Hunger]]

Michael Hunger at 10:35, 16 June 2009

Michael Hunger — Tue, 16 Jun 2009 10:35:06 GMT

←Older revision		Revision as of 10:35, 16 June 2009
Line 1:		Line 1:
-	Code bases that are not cared for tend to ~~take the same route as a compost heap. They~~ rot. ~~Every~~ line of code ~~that~~ is written ~~starts to age~~ at ~~the~~ moment ~~of its creation~~.	+	Code bases that are not cared for tend to rot. That does not mean they are converted into valueable soil.
-	~~Due~~ to ~~limited~~ information ~~at the time~~ of ~~writing, newly written~~ code ~~is mostly an~~ inappropriate solution ~~for~~ the problem~~. First~~ you ~~get it to solve the problem~~.	+	When a line of code is written it captures the information, knowledge and skill you had at this moment. As you continually learn and improve and get to know new bits of information many of those code lines become more and more inappropriate with the passage of time. Although your initial solution solved the problem you discover better ways for doing so.

-	~~Try using ''test-driven development'' (TDD) for validating that~~ your ~~problem is solved. But you shouldn't stop there. The TDD mantra is red-green-refactor~~.	+	It is plainly wrong to deny the code the chance to evolve with your growing abilities.

-	~~So after~~ solving ~~your problem you must look at~~ your code ~~base from a wider perspective. How does~~ it ~~fit with your systems architecture,~~ the ~~programming model principles~~ (e.g.~~, object oriented, functional, etc~~.~~), the language idioms?~~	+	For the initial problem solving solution TDD is one very useful approach. It gives your code an environment (tests) to be executed in and validates that it actulally solved the problem (passing the tests). The design is driven implicitely to a testable state that has a higher design quality already. But you shouldn't stop there. The TDD mantra is red-green-REFACTOR.

-	~~Can~~ you ~~see any ''~~code smells'' like	+	So after solving your problem you must look at your code base from a wider perspective. How does it fit with your systems architecture, the programming model principles (e.g., object oriented, functional, etc.), the language idioms? How well is it integrated with existing code.
		+
		+	While reading, maintaining and writing code it is quite easy to spot pathologies also known as "code smells" (releated by Kent Beck to bad baby smells)
		+
		+	Do you notice things like:
	* duplication (near and far),		* duplication (near and far),
	* inconsistent or uninformative names,		* inconsistent or uninformative names,
Line 21:		Line 25:
	Ask for help if your gut feeling does not guide you in the right direction. Pair with a co-worker for the refactoring session. Two sets of eyes and experiences can have a significant effect — especially if one of these is unclouded by the initial implementation approach.		Ask for help if your gut feeling does not guide you in the right direction. Pair with a co-worker for the refactoring session. Two sets of eyes and experiences can have a significant effect — especially if one of these is unclouded by the initial implementation approach.

-	Another great way to look for the target of your refactoring is design patterns. Although the original work by Martin Fowler et al does not ~~rely on~~ design patterns ~~that heavily~~, the additional work of Joshua Kerievsky does a good job in discussing design patterns as goals for refactorings.	+	Another great way to look for the target of your refactoring is design patterns. Although the original work by Martin Fowler et al does not mention design patterns very much, the additional work of Joshua Kerievsky does a good job in discussing design patterns as goals for refactorings.

	Fortunately in our time we have the tools available to help us with automatic refactoring. Most IDEs offer an impressive range of refactorings that work on the syntactically sound parse tree of your source code (and so can even refactoring partially defective or unfinished source code). So there is no excuse for not refactoring.		Fortunately in our time we have the tools available to help us with automatic refactoring. Most IDEs offer an impressive range of refactorings that work on the syntactically sound parse tree of your source code (and so can even refactoring partially defective or unfinished source code). So there is no excuse for not refactoring.

	When refactoring you often encounter an epiphany at some point. This happens when suddenly all puzzle pieces fall into the place where they belong and the sum of your code is bigger than its parts. From that point it is quite easy to take a leap in the development of your system or its architecture.		When refactoring you often encounter an epiphany at some point. This happens when suddenly all puzzle pieces fall into the place where they belong and the sum of your code is bigger than its parts. From that point it is quite easy to take a leap in the development of your system or its architecture.
-
-	Further Reading:
-	#Refactoring: Improving the Design of Existing Code Fowler, Martin 1999
-	#Refactoring to Patterns (The Addison-Wesley Signature Series) Kerievsky, Joshua 2004
-	#Design Patterns, Erich Gamma, 1995
-	#Test Driven Development: By Example (Addison-Wesley Signature Series) Beck, Kent 2002

	By [[Michael Hunger]]		By [[Michael Hunger]]

	This work is licensed under a [http://creativecommons.org/licenses/by/3.0/us/ Creative Commons Attribution 3]		This work is licensed under a [http://creativecommons.org/licenses/by/3.0/us/ Creative Commons Attribution 3]
-
-

	Back to [[97 Things Every Programmer Should Know]] home page		Back to [[97 Things Every Programmer Should Know]] home page

Kevlin at 20:27, 31 January 2009

Kevlin — Sat, 31 Jan 2009 20:27:43 GMT

←Older revision		Revision as of 20:27, 31 January 2009
Line 1:		Line 1:
-	== Ruthless refactoring ==
-
	Code bases that are not cared for tend to take the same route as a compost heap. They rot. Every line of code that is written starts to age at the moment of its creation.		Code bases that are not cared for tend to take the same route as a compost heap. They rot. Every line of code that is written starts to age at the moment of its creation.
	Due to limited information at the time of writing, newly written code is mostly an inappropriate solution for the problem. First you get it to solve the problem.		Due to limited information at the time of writing, newly written code is mostly an inappropriate solution for the problem. First you get it to solve the problem.

-	Try using ''test driven development'' (TDD) for validating that your problem is solved. But you shouldn't stop there. The TDD mantra is red-green-refactor.	+	Try using ''test-driven development'' (TDD) for validating that your problem is solved. But you shouldn't stop there. The TDD mantra is red-green-refactor.

-	So after solving your problem you must look at your code base from a wider perspective. How does it fit with your systems architecture, the programming model principles (e.g. object oriented, functional, etc.), the language idioms.	+	So after solving your problem you must look at your code base from a wider perspective. How does it fit with your systems architecture, the programming model principles (e.g., object oriented, functional, etc.), the language idioms?

	Can you see any ''code smells'' like		Can you see any ''code smells'' like
Line 17:		Line 15:
	* exposing your internal state?		* exposing your internal state?

-	Your IDE may help you with this. The code intentions they provide offer a good starting point as they are tailored to the language and sometimes offer quick fixes (~~Dubbed~~ ''refactoring by example'' by Kent Beck).	+	Your IDE may help you with this. The code intentions they provide offer a good starting point as they are tailored to the language and sometimes offer quick fixes (dubbed ''refactoring by example'' by Kent Beck).

-	If so you have to take action. Try ~~to convert~~ the ~~smelling~~ code ~~to good looking pieces that feel just right~~. Don't rush. Just take small steps. And keep your tests running so that you can easily see if you broke something. In ~~the~~ Refactoring ~~book~~ the steps of the ~~discussed~~ refactorings are outlined in great detail, so ~~its~~ easy to follow. I would suggest ~~to do~~ the steps at least once manually to get a feeling for the preconditions and side effects of each refactoring. Thinking about what you're doing is absolutely necessary when refactoring. ~~Small glitches~~ can become big ~~deals~~ as ~~you can impact quite~~ a part of the code base.	+	If so you have an opportunity to take action. Try deodorizing the smelly code. Don't rush. Just take small steps. And keep your tests running so that you can easily see if you broke something. In Martin Fowler's ''Refactoring'' the steps of the refactorings presented are outlined in great detail, so it's easy to follow. I would suggest doing the steps at least once manually to get a feeling for the preconditions and side effects of each refactoring. Thinking about what you're doing is absolutely necessary when refactoring. A small glitch can become a big deal as it may affect a larger part of the code base than anticipated.

-	Ask for help if your gut feeling does not guide you in the right direction. ~~Take~~ a co-worker ~~and pair with him~~ for the refactoring session. Two sets of eyes and experiences have a ~~really great impact -~~ especially if one of these is unclouded by the initial implementation approach.	+	Ask for help if your gut feeling does not guide you in the right direction. Pair with a co-worker for the refactoring session. Two sets of eyes and experiences can have a significant effect — especially if one of these is unclouded by the initial implementation approach.

-	Another great way to look for the target of your refactoring is design patterns. Although the original work by Martin Fowler et.al. does not rely on design patterns that heavily the additional work of Joshua Kerievsky does a good job in discussing design patterns as goals for refactorings.	+	Another great way to look for the target of your refactoring is design patterns. Although the original work by Martin Fowler et al does not rely on design patterns that heavily, the additional work of Joshua Kerievsky does a good job in discussing design patterns as goals for refactorings.

-	Fortunately in our time we have the tools available to help us with automatic refactoring. Most ~~IDE~~ offer a impressive range of refactorings that work on the syntactically sound parse tree of your source code (and so can even refactoring partially ~~defect~~ or unfinished ~~sourceode~~). So there is no excuse for not refactoring.	+	Fortunately in our time we have the tools available to help us with automatic refactoring. Most IDEs offer an impressive range of refactorings that work on the syntactically sound parse tree of your source code (and so can even refactoring partially defective or unfinished source code). So there is no excuse for not refactoring.

-	When refactoring you often encounter an epiphany at some point. This happens when suddenly all puzzle pieces fall into the place where they belong and the sum of your code is bigger than its parts. From that point it is quite easy to take a leap in the development of your system or ~~it's~~ architecture.	+	When refactoring you often encounter an epiphany at some point. This happens when suddenly all puzzle pieces fall into the place where they belong and the sum of your code is bigger than its parts. From that point it is quite easy to take a leap in the development of your system or its architecture.

	Further Reading:		Further Reading:
Line 35:		Line 33:
	#Test Driven Development: By Example (Addison-Wesley Signature Series) Beck, Kent 2002		#Test Driven Development: By Example (Addison-Wesley Signature Series) Beck, Kent 2002

-	--[[~~User:Michael Hunger\|~~Michael Hunger]] 13:~~17, 29 January 2009 (PST)~~	+	By [[Michael Hunger]]
		+
		+	This work is licensed under a [http://creativecommons.org/licenses/by/3.0/us/ Creative Commons Attribution 3]
		+
		+
		+
		+	Back to [[97 Things Every Programmer Should Know]] home page

Michael Hunger at 21:17, 29 January 2009

Michael Hunger — Thu, 29 Jan 2009 21:17:06 GMT

←Older revision		Revision as of 21:17, 29 January 2009
Line 33:		Line 33:
	#Refactoring to Patterns (The Addison-Wesley Signature Series) Kerievsky, Joshua 2004		#Refactoring to Patterns (The Addison-Wesley Signature Series) Kerievsky, Joshua 2004
	#Design Patterns, Erich Gamma, 1995		#Design Patterns, Erich Gamma, 1995
-	#Test Driven Development: By Example (Addison-Wesley Signature Series) Beck, Kent 2002	+	#Test Driven Development: By Example (Addison-Wesley Signature Series) Beck, Kent 2002
		+
		+	--[[User:Michael Hunger\|Michael Hunger]] 13:17, 29 January 2009 (PST)

Michael Hunger at 21:16, 29 January 2009

Michael Hunger — Thu, 29 Jan 2009 21:16:47 GMT

←Older revision		Revision as of 21:16, 29 January 2009
Line 29:		Line 29:
	When refactoring you often encounter an epiphany at some point. This happens when suddenly all puzzle pieces fall into the place where they belong and the sum of your code is bigger than its parts. From that point it is quite easy to take a leap in the development of your system or it's architecture.		When refactoring you often encounter an epiphany at some point. This happens when suddenly all puzzle pieces fall into the place where they belong and the sum of your code is bigger than its parts. From that point it is quite easy to take a leap in the development of your system or it's architecture.

-	~~--[[User~~:~~Michael Hunger\|Michael Hunger]] 18~~:25, ~~22 January 2009~~ (~~PST~~)	+	Further Reading:
		+	#Refactoring: Improving the Design of Existing Code Fowler, Martin 1999
		+	#Refactoring to Patterns (The Addison-Wesley Signature Series) Kerievsky, Joshua 2004
		+	#Design Patterns, Erich Gamma, 1995
		+	#Test Driven Development: By Example (Addison-Wesley Signature Series) Beck, Kent 2002

Michael Hunger: /* Ruthless refactoring */

Michael Hunger — Tue, 27 Jan 2009 00:24:35 GMT

Ruthless refactoring

←Older revision		Revision as of 00:24, 27 January 2009
Line 4:		Line 4:
	Due to limited information at the time of writing, newly written code is mostly an inappropriate solution for the problem. First you get it to solve the problem.		Due to limited information at the time of writing, newly written code is mostly an inappropriate solution for the problem. First you get it to solve the problem.

-	Try using TDD for validating that your problem is solved. But you shouldn't stop there. The TDD mantra is red-green-refactor.	+	Try using ''test driven development'' (TDD) for validating that your problem is solved. But you shouldn't stop there. The TDD mantra is red-green-refactor.

	So after solving your problem you must look at your code base from a wider perspective. How does it fit with your systems architecture, the programming model principles (e.g. object oriented, functional, etc.), the language idioms.		So after solving your problem you must look at your code base from a wider perspective. How does it fit with your systems architecture, the programming model principles (e.g. object oriented, functional, etc.), the language idioms.

-	Can you see any code smells like	+	Can you see any ''code smells'' like
	* duplication (near and far),		* duplication (near and far),
	* inconsistent or uninformative names,		* inconsistent or uninformative names,
Line 15:		Line 15:
	* long sequences of conditionals		* long sequences of conditionals
	* working in the intestines of other units (objects, modules)		* working in the intestines of other units (objects, modules)
-	* exposing your internal state	+	* exposing your internal state?

-	Your IDE may help you with this. The code intentions they provide offer a good starting point as they are tailored to the language and sometimes offer quick fixes (Dubbed refactoring by example by Kent Beck).	+	Your IDE may help you with this. The code intentions they provide offer a good starting point as they are tailored to the language and sometimes offer quick fixes (Dubbed ''refactoring by example'' by Kent Beck).

	If so you have to take action. Try to convert the smelling code to good looking pieces that feel just right. Don't rush. Just take small steps. And keep your tests running so that you can easily see if you broke something. In the Refactoring book the steps of the discussed refactorings are outlined in great detail, so its easy to follow. I would suggest to do the steps at least once manually to get a feeling for the preconditions and side effects of each refactoring. Thinking about what you're doing is absolutely necessary when refactoring. Small glitches can become big deals as you can impact quite a part of the code base.		If so you have to take action. Try to convert the smelling code to good looking pieces that feel just right. Don't rush. Just take small steps. And keep your tests running so that you can easily see if you broke something. In the Refactoring book the steps of the discussed refactorings are outlined in great detail, so its easy to follow. I would suggest to do the steps at least once manually to get a feeling for the preconditions and side effects of each refactoring. Thinking about what you're doing is absolutely necessary when refactoring. Small glitches can become big deals as you can impact quite a part of the code base.
Line 25:		Line 25:
	Another great way to look for the target of your refactoring is design patterns. Although the original work by Martin Fowler et.al. does not rely on design patterns that heavily the additional work of Joshua Kerievsky does a good job in discussing design patterns as goals for refactorings.		Another great way to look for the target of your refactoring is design patterns. Although the original work by Martin Fowler et.al. does not rely on design patterns that heavily the additional work of Joshua Kerievsky does a good job in discussing design patterns as goals for refactorings.

-	Fortunately in our time we have the tools available to help us with automatic refactoring. Most IDE offer a impressive range of refactorings that work on the syntactically sound parse tree of your source code (and so can even refactoring partially defect or unfinished sourceode). So there is no excuse of not refactoring.	+	Fortunately in our time we have the tools available to help us with automatic refactoring. Most IDE offer a impressive range of refactorings that work on the syntactically sound parse tree of your source code (and so can even refactoring partially defect or unfinished sourceode). So there is no excuse for not refactoring.
		+
		+	When refactoring you often encounter an epiphany at some point. This happens when suddenly all puzzle pieces fall into the place where they belong and the sum of your code is bigger than its parts. From that point it is quite easy to take a leap in the development of your system or it's architecture.

-	When refactoring you often encounter an epiphany at some point. This happens when suddenly all puzzle pieces fall into the place where they belong and the sum of your code is bigger than its parts. From that point it is quite easy to take a leap in the development of your system or its architecture.
	--[[User:Michael Hunger\|Michael Hunger]] 18:25, 22 January 2009 (PST)		--[[User:Michael Hunger\|Michael Hunger]] 18:25, 22 January 2009 (PST)