tagged by: clean code
Workflows of Refactoring
Refactoring has grown into a well-known technique, and most software development teams at least claim to be doing refactoring regularly. Many teams, however, don't appreciate the different workflows that refactoring can be used in, and thus miss opportunities to effectively incorporate refactoring into their development activities. In this deck I explore various different workflows. I hope it will encourage teams to integrate refactoring more deeply into their work, resulting in a better designed code-bases that will make it quicker and easier to add new features.
8 January 2014
infodeck
Refactoring code that accesses external services
When I write code that deals with external services, I find it valuable to separate that access code into separate objects. Here I show how I would refactor some congealed code into a common pattern of this separation.
17 February 2015
article
Using Metadata
You can use metadata based approaches to remove the pain from tedious data oriented tasks.
November 2002
BeckDesignRules
Kent Beck came up with his four rules of simple design while he was developing ExtremeProgramming in the late 1990's. I express them like this.
2 March 2015
bliki
CommandQuerySeparation
The term 'command query separation' was coined by Bertrand Meyer
in his book "Object Oriented Software Construction
5 December 2005
bliki
DataClump
Whenever two or three values are gathered together - turn them into a $%#$%^ object.
-- Me (it was funnier with the voices)
This is one of my favorite CodeSmells from the refactoring book. You spot it when you constantly see the same few data items passed around together. start and end are a good example of a data clump wanting to be a range. Often data clumps are primitive values that nobody thinks to turn into an object.
bliki
Detestable
(Here's an addition to your dictionary.)
Detestable (adjective): software that isn't testable.
16 March 2005
bliki
GangOfFour
In my view the Gang of Four
bliki
TechnicalDebt
You have a piece of functionality that you need to add to your system. You see two ways to do it, one is quick to do but is messy - you are sure that it will make further changes harder in the future. The other results in a cleaner design, but will take longer to put in place.
1 October 2003
bliki
Yagni
Yagni originally is an acronym that stands for "You Aren't Gonna Need It". It is a mantra from ExtremeProgramming that's often used generally in agile software teams. It's a statement that some capability we presume our software needs in the future should not be built now because "you aren't gonna need it".
26 May 2015
bliki
The Basics of Web Application Security
by Cade Cairns and Daniel Somerfield
Modern web development has many challenges, and of those security is both very important and often under-emphasized. While such techniques as threat analysis are increasingly recognized as essential to any serious development, there are also some basic practices which every developer can and should be doing as a matter of course.
5 January 2017
article
To Be Explicit
Often designs techniques are used to make a system more flexible, but end up being harder to work with. One of the reasons is that explicitness is a property that often gets forgotten in design.
November 2001
When to Make a Type
Guidelines on when to make a new user defined type (or class) for values.
January 2003
CodeSmell
A code smell is a surface indication that usually corresponds to a deeper problem in the system. The term was first coined by Kent Beck while helping me with my Refactoring book.
9 February 2006
bliki
ComposedRegex
One of the most powerful tools in writing maintainable code is break large methods into well-named smaller methods - a technique Kent Beck refers to as the Composed Method pattern.
24 July 2009
bliki
DesignStaminaHypothesis
Is it worth the effort to design software well?
20 June 2007
bliki
FunctionLength
During my career, I've heard many arguments about how long a function should be. This is a proxy for the more important question - when should we enclose code in its own function? Some of these guidelines were based on length, such as functions should be no larger than fit on a screen . Some were based on reuse - any code used more than once should be put in its own function, but code only used once should be left inline. The argument that makes most sense to me, however, is the separation between intention and implementation. If you have to spend effort into looking at a fragment of code to figure out what it's doing, then you should extract it into a function and name the function after that “what”. That way when you read it again, the purpose of the function leaps right out at you, and most of the time you won't need to care about how the function fulfills its purpose - which is the body of the function.
30 November 2016
bliki
SelfTestingCode
Self-Testing Code is the name I used in Refactoring to refer to the practice of writing comprehensive automated tests in conjunction with the functional software. When done well this allows you to invoke a single command that executes the tests - and you are confident that these tests will illuminate any bugs hiding in your code.
1 May 2014
bliki
TestDrivenDevelopment
Test-Driven Development (TDD) is a technique for building software that guides software development by writing tests. It was developed by Kent Beck in the late 1990's as part of Extreme Programming. In essence you follow three simple steps repeatedly:
5 March 2005
bliki
