Il tuo obiettivo per il nuovo anno? Entrare in Red Gate Software!

Guarda il video per scoprire cosa significa essere uno sviluppatore software in una delle migliori aziende software inglesi. Sono un italiano che 5 anni fa ha deciso di fare il grande passo e andare a lavorare in UK. Posso dire che e' stata una delle decisioni migliori della mia vita!

Vuoi lavorare con noi?
Per un accesso privilegiato, scrivi una mail all'indirizzo andrea.angella (at) red-gate.com

The pleasure of Down Tools Week

I have just arrived home.

It's Friday and an another Down Tools Week is ended.

I am writing this post to capture my feeling in this exact moment before my emotions disappear and I start to enter in the "Week End Mode".

I feel very tired. It was hard work but I am incredibly proud of what we achieved.

For the entire week, I didn't have meetings, I didn't check emails but I only focused on writing the minimum code that works in order to present something for the "Show & Tell" that usually happens on Friday afternoon.

The feeling during Down Tools Week is awesome.

You are completely absorbed on the tasks at hand, in the most pragmatic way you collaborate and assign tasks between the newly formed team. You can feel a constant release of adrenaline. Even after work, you can't stop thinking about what you want and should do the following day.

The most intriguing thing is that even if I worked very hard and I ate very quickly just to be able to start coding and squeeze every minute, the time passed incredibly quickly. You don't feel the time at all, actually you fight against it.

This is what I define as "Fun", what I define as "Feeling a programmer" and what I define as "Feeling alive".

Surely my passion for programming amplifies these emotions.

Psychologists call this feeling "The Flow".

The FlowA mental state of operation in which a person performing an activity is fully immersed in a feeling of energized focus, full involvement and enjoyment in the process of the activity.

I never worked with James and Peter before. Actually I never met them before in the company. In a week, I have learnt to work with them in a very effective way. I don't know if they feel the same way but I have to say that I am very impressed by what a team can do in a so short amount of time. It is fascinating to see what a bunch of people can do when time is given to them to do what they want.

The initiative is called Down Tools Week an integral and fundamental element of the culture of Red Gate where creativity is unleashed, people are empowered to learn together and create great things.

When I was young, I used to feel like this quite often. I coded games for my friends losing track of the time while I was doing it. This week remembered me those good days.

I'd like to thanks Red Gate to offer me the ability to feel in this way. I'd like to thanks James and Peter for helping me in developing further the idea of "Code Complexity as a service" (technical details will follow in a new post).

Above all, this week was seriously fun!

Webcast: Vuoi essere uno sviluppatore software in Red Gate (UK)?

Giovedi' 13 Novembre 2014

Sede: evento online
Ora: 17:30 - 18:30
Speaker: Andrea Angella

Q/A: Jodie Pinkowski 

Red Gate Software produce "ingeniously simple tools" per professionisti e sviluppatori Microsoft in tutto il mondo. L'azienda e' principalmente specializzata in MS SQL Server, Cloud, .NET e Oracle con l'obiettivo di diventare leader nel Database Lifecycle Management (DLM), la componente database dell' Application Lifecycle Management (ALM). Sviluppatori e DBA saranno in grado di trattare database come ogni altra parte dell'applicazione adottando processi di sviluppo moderni, come continuous integration e continuous delivery, per rilasciare spesso e in modo sicuro.

Per raggiungere questo obiettivo ambizioso, Red Gate e' anche alla ricerca di sviluppatori software italiani.

• Ti sei mai chiesto come possa essere l'esperienza di uno sviluppatore software in UK?
• Sei alla ricerca di un ambiente di lavoro piu' stimolante e gratificante che possa veramente farti crescere professionalmente?
• Sei alla ricerca di un migliore bilanciamento tra lavoro e vita privata?
• Stai considerando la possibilita' di fare una esperienza all'estero?

Andrea Angella e' un italiano che lavora in UK da 5 anni e presentera' tutti i vantaggi di lavorare in Red Gate dando risposta a molte delle domande che un italiano si pone prima di compiere il grande passo. Durante l'intero webcast, la responsabile delle risorse umane, Jodie Pinkowski, sara' a disposizione per rispondere direttamente alle vostre domande (Only In English).

Iscriviti all'evento

Database Unit Testing and Learning TSQL

Did you know that you can write database unit tests for SQL Server?

There is a framework called tSQLt that helps you to do it.

There is also a tool from Red Gate Software called SQL Test that provide a nice UI on top of it, integrated in SQL Server Management Studio.

What about using tests for learning TSQL?

I think that it is not unreasonable to design a TSQL course where each lesson is made of a set of tests that you need to make pass. This idea of learning by making tests pass is used in the nand2tetris course that I am doing with the friends of the Cambridge Programmer's Study Group.

In this post, I try to create an example using tSQLt.

The database I use is from the Training Kit: Querying Microsoft SQL Server 2012.

Installing tSQLt

First run the following SQL statements.

Execute the tSQLt.class.sql script provided by tSQLt.

Creating the test

First, you need to create a test class that we call Tests.

Then, we create a test.

The framework tSQLt allows you to create fake tables but in this case the test use the actual table HR.Employees and the actual data contained in it.

Running the test

You can run the test individually using the tSQLt.Run or alternatively you can run all the tests in the database using tSQLt.RunAll. 

You can also create a keyboard shortcut to run all the tests easily.

You can see that the test fail!

Make the test pass and learn

You can make the test pass simply adding the DISTINCT keyword in the select statement.  

Run the tests and they all pass.

I really like the idea of learning by making tests pass.

What do you think?

Enneagram Personality Test

I like psychological tests to learn more about myself.

Few months ago, I tried the Personality Type Indicator test.

Today, I did the Enneagram Personality Test that shows how you are balanced between nine personality types (called wings) and to see which one are the dominants.

It looks like I am pretty balanced with a preference of the Type 3 (The Achiever), Type 9 (The Peacemaker) and Type 1 (The Reformer).

What is your result?

Secrets of Success from the Story of Bill Gates - Part 2

Persistence

Never give up there is always a way out. Do what you are supposed to do; it will lead to bigger opportunities along the way.

If you can make up your mind that you will not settle for less, you will not settle for less. You will keep right on going and you will achieve your goals and dreams. If you convince yourself nothing is impossible, nothing will be impossible for you.

Don't concentrate on how hard it is but focus on the reward and satisfaction you get by achieving your goals.

Always focus on the final outcome from the start, never lose that ability to focus. As the road gets harder, you get harder; as the road gets tougher, you get tougher; as the journey becomes difficult and seems like it’s impossible, just continue to focus and keep going and watch what will happen. The only true failure is when you give up and you stop moving on.

Reward your progress when you reach a milestone.

Bring your best to every situation; you may never know when your breakthrough opportunity presents it to you. Persistence always pays off. Don't take rejections to heart or personally, it’s only a normal process of taking out what is not good for you. Persistence takes action.

The most successful people in life are always persistent. Persistent people are often accused of being cold and heartless, but a careful re-evaluation shows this is not the case at all, they are simply singled minded in their pursuit of their own personal destiny.

Secrets of Success from the Story of Bill Gates - Part 1

This is an very inspiring and motivational book: Secrets of Success from the Story of Bill Gates.

Bill Gates is a person that always inspired me and continue to inspired me. 

Bill Gates built Microsoft from scratch – he created the single most influential technology company of our modern age, and it made him so wealthy that he is now able to focus on the eradication of poverty and disease through the work of his charity foundation.

In 1994, Gates and his wife Melinda founded a charitable organisation called the Bill and Melinda Gates Foundation which supports initiatives in global health and education. The aim of the foundation is to eradicate poverty, disease and illiteracy from the world.

Bill Gates has received numerous international and national accolades, and honorary doctorates from the Royal Institute of Technology, Stockholm, Sweden in 2002, Waseda University, Tokyo, Japan in 2005, Harvard University in June 2007, and other universities. He was also made an honorary Knight Commander of the Order of the British Empire (KBE) from Queen Elizabeth II in 2005.

The book describes the key elements of  the history of the Bill Gates but he also introduce a lot of examples from other great people who are equally inspiring.

Learnings from software development coaching sessions

Back in November 2013 I wrote a post sharing with you my decision of being mentored by a friend and agile coach Matteo Baglini with the goal of exposing myself to agile engineering practises and become a better developer.

At the time, I promised to write posts about my learning but ultimately I didn't. So, it is time to start now!

First of all, I wish to thanks my manager Dom Smith in Red Gate Software to offer me the opportunity to have these sessions during working hours. This really offers me the ability to have sessions regularly every week.

In this post I will condensate the learning of the last few months of mentoring with links to the various resources that I read since then.

We started discussing TDD and the approach described by Kent beck:

1. Write new code only if an automated test has failed
2. Remove duplications

Duplication is the most important code smell and it can be hard to see. For this reason, sometimes it is useful to write verbose code just to help you find duplications.

I did the full Money example in the book TDD By Example exactly how Kent did it (with few changes as I did in C#) and deeply reflected on each step. I spent a full day to do it but it was worth the effort.

Learning well a refactoring tool like ReSharper is very important. However it is important to consider that the biggest advantages of a refactoring tool is not merely productivity:

• Avoid the human error
• Remove the context switch between using keyboard and mouse
• Shorten the feedback loop by decreasing the time needed to refactor a piece of code
• You can answer quickly questions like: Is the new design better?

Doing a kata multiple times without changing the solution to just focus in how you code and use refactoring tools is a very useful technique.

Here is a collection of very useful advices:

• Check the error message when a test fail
• Run tests often
• After a refactoring run the tests
• Avoid copy & paste as much as possible
• When you find something to do, don't stop your current task. Add a note and do it later.
• Don't stop the flow only to rename a method or a property! Add a note and do it later.
• Primitive obsession can be often removed by introducing Value Objects
• Sometimes you can add a test and comment it out in order to do necessary refactoring
• Don't be too confident! Always use tests to validate what you are doing
• Keep tests as stupid as possible. Limit test logic as much as possible!
• In case of regression (red bar) never change test logic otherwise you won't know what was right
• If you lose control, just slow down or discard changes and restart
• Don't restrict yourself in a Top Down or Button up approach.
• The code guides you. TDD is a feedback tool.
• Consider adding code even if it is not strictly required to improve readability or simply to add symmetry
• Some tests are simply tests to support you during development. You can remove them when other tests cover the same functionalities. Don't be afraid. 
• Consider the "Copy Type" ReSharper command
• The production code tests the tests!
• Extract Method is a powerful refactoring tool
• It is sometimes useful to make a private internal method public just for the sake of temporary writing unit tests but don't submit that code! Use it only to increase your knowledge about the problem.
• Learn how to do small steps when needed.
• A test is done only when duplication is eliminated!
• Consider writing a test to force the creation of an object that we expect to need late but attention of not doing upfront design
• Relying on the compiler can be a useful technique
• If it takes a lot of time to make a test green... reflect!
• Prefer static methods to factory classes when implementing the factory pattern
• Getters are smells. Pay attention to not use objects as mere data structure.
• Resist the temptation of not creating new classes... try, get feedback and see!
• Observe the frequency of change. Change should be distributed among classes.
• Use the Single Responsibility Principle to see pattern of change
• The class who own the data should do the operation: Tell, Don't Ask!
• In designing API it is best to offer a single way to do something. Make it simple!
• Use the history in SCM to get insight about your project
• Analyse temporal correlation of class changes
• If you feel that something is annoying in the code base that is a sign of poor design.
• Remain at the same level of abstraction within a test
• Write a high level test and when you see the need to cover a lot of cases go down of one level of abstraction and write more specific unit tests.
• You will often be pushing tests up and down between different levels of abstraction
• Remember to not look inside the object when you do testing even on individual classes! Test the behaviour so that you can easily change the instance of the class with a new class but keep the tests intact.
• Do not use TDD as a way to get permissions to write production code (that is cheating).
• Do not be too enthusiastic about new technologies or methodologies. Slow down and reflect. There will be always a hype and later a fall. If you are pragmatic you can fall less.
• Consider writing the assertion first

The essence of object orientation is thinking about behaviours

TDD test are always behavioural and at different level of abstraction. TDD can be done at different levels of zoom: it is sort of a dance between them. Unfortunately TDD has been often misunderstood and even attempts were made to fix this with ATDD and BDD. But these methods have often been identified with tools and things like Cucumber only create a new layer without bringing much value: having the on-site customer is far better than executable requirements that are a dream.

Pair programming helps a lot to keep focused and the role of navigators is supporting drivers in maintaining discipline and avoiding distractions

I and my mentor discussed many times about the Theory of Constraints and the importance of identifying bottlenecks in order to remove them. It is quite interesting to note that also humans can be a bottleneck and therefore an issue that can be addressed by increasing sharing. This can be done both with pair programming or with the Expert in Earshot pattern.

Quotations:

I never known exactly how to achieve high cohesion and loose coupling regularly until I started writing isolated tests, Kent Beck

I get paid for code that works, not for tests, so my philosophy is to test as little as possible to reach a given level of confidence (I suspect this level of confidence is high compared to industry standards, but that could just be hubris). If I don’t typically make a kind of mistake (like setting the wrong variables in a constructor), I don’t test for it. I do tend to make sense of test errors, so I’m extra careful when I have logic with complicated conditionals. When coding on a team, I modify my strategy to carefully test code that we, collectively, tend to get wrong. Different people will have different testing strategies based on this philosophy, but that seems reasonable to me given the immature state of understanding of how tests can best fit into the inner loop of coding. Ten or twenty years from now we’ll likely have a more universal theory of which tests to write, which tests not to write, and how to tell the difference. In the meantime, experimentation seems in order. Kent Beck

Resources:

• Book: TDD By Example
• Book: Refactoring
• Book: Implementation Patterns
• Book: Growing Object Oriented Software guided by tests
• Book: Working Effectively with Legacy Code
• Book: Holub on Patterns: Learning Design Patterns by Looking at Code
• Book: The 4 rules of simple design
• Book: ATDD By Example
• Article: Extreme Programming Values
• Article: Exagonal Architecture
• Article: The Clean Architecture
• Article: Visualizing Test Terminology
• Article: Programming like Kent Beck
• Presentation: Embrace Uncertainty, Jeff Patton
• Presentation: Theory of Constraints, J. B. Rainsberger
• Blog: Growing Object Oriented Software, Guided By Tests
• Blog: Working Effectively with Legacy Code
• Blog: Design Patterns
• Blog: The Definitive Guide to Learn JetBrains ReSharper Shortcuts in Visual Studio

Stored Procedure to Calculate Expressions

I was reading the section Character Functions in the Chapter 2 of the book Querying Microsoft SQL Server 2012 and pretty soon I get bored of trying individually the various functions on strings available in T-SQL.

Then, I challenged myself to write a stored procedure (this is my first one) to evaluate an arithmetic expression with parenthesis and show the individual steps of the calculation. I wanted something generic but I added some restrictions to it after seeing how crazy is to implement a split function in T-SQL.

This is the stored procedure. I know, it is crazy and I am sure there are much better way of doing it. Remember that my goal was to just get confidence with the T-SQL functions on strings. Anyway, I am happy to receive feedback on it and see different way of implementing this behaviour.

This is the result of the execution.

It was fun :)

My Personal Brand Survey Results (2014)

In the last few years, I read some books about personal branding and pretty much all of them highly recommend to take an anonymous 360 degrees surveys in order to understand how people perceive you.

For this reason, I decided to give it a go and try.

After a little bit of research I decided to use the 360 Reach platform. The survey is completely free for 15 days but I decided to pay for a premium version in order to get more results and a detailed report out of it.

In this post I am going to share with you the most interesting results.

Preparing for Querying Microsoft SQL Server 2012

Few months ago I joined Red Gate Software and I am having a lot of fun so far. We have a great team in SQL Compare and we are working hard to add support for SQL Server 2014.

I think that learning more about SQL Server is very important because a lot of Red Gate products are designed to make DBA and developers working with it in a very productive way.

This is why I decided to start the path toward becoming a MCSA on SQL Server. To be honest, as a developer, my goal is just learning more about SQL Server and not necessarily get certified. However I will use the certification materials as a clear path to increase my knowledge.

The first exam on the list is
[70-461] Querying Microsoft SQL Server 2012

I know SQL and I have studied database development and design at University. However I don't know much about SQL Server specific features and the incredible power that the platform can offer. 

In order to keep me motivated I will post on my blog all the things I found interesting during my learning.

The following is a list of all the resources I will use to prepare for this exam:

• Book: Querying Microsoft SQL Server 2012
• TechEd 2014: Exam Prep: 70-461 - MCSA: Microsoft SQL Server 2012 (Querying)
• Hands-On-Lab: What's New for T-SQL in Microsoft SQL Server 2012
• Pluralsight: SQL Server 2012 Querying (70-461) Part 1
• Pluralsight: SQL Server 2012 Querying (70-461) Part 2

It's time to write SQL :)

Growing Object Oriented Software, Guided By Tests

Few weeks ago I finished to read the famous book
Growing Object-Oriented Software, Guided by Tests

In this post, I try to summarize what I think is the most interesting content.

The book present the interesting approach of starting a new project with a Walking Skeleton that is a tiny implementation of the system that performs a small end-to-end function

The point of the walking skeleton is to help us understand the requirements well enough to propose and validate a broad-brush system structure.

In most Agile projects, there’s a first stage where the team is doing initial analysis, setting up its physical and technical environments, and otherwise getting started. This is usually called Iteration Zero.

Top 10 Debugging Tips in Visual Studio 2013

I watched the "Debugging Tips and Tricks in Visual Studio 2013" session from TechEd and I found some very interesting debugging tips I was mainly unaware of.

Run to Cursor (CTRL + F10)

Run the debugger and stop in the location of your cursor. This allows you to debug your code from a particular location without the need to set a breakpoint. This is useful because often people create breakpoints but forget to remove them and the debugging becomes very slow.

F11 

You can start your application and automatically break at the first line of code. This avoid you to manually find the entry point of the application.

Thank you BASIC!

The first of May 2014 was the 50th Birthday of BASIC.

I couldn't resist the temptation to write a post on it because BASIC has been my first programming language and I have used it for more than 9 years. Seriously? Yeah :)

Actually, I didn't write BASIC programs on a PC but on Casio calculators using a variant called Casio BASIC.

This was the power of my first programming language :)

Casio graphic calculators use a BASIC-like programming language but variable names are restricted to single letters A-Z which are shared by all programs including subroutines which are stored as separate programs. This means there are no local variables, they are all global. These variables are also shared by other functions of the calculator. For example, drawing a graph will overwrite the X and Y values.

Everyone who grow up with me knows that I never walked without my calculator in my pocket. I was a true geek :) Most of the time I used to create games for my friends: board games, card games, strategy games, casino games and so on. They were pretty popular!

The first 5 years I only coded on the Casio calculators. Then I got a PC and I also started to write code with Visual Basic and C/C++. However, I didn't have a laptop so I continued to write code on the calculator for other 4 years so that my friends could play on the train.

Becoming an Outlier: Reprogramming the Developer Mind

I finished to watch an awesome course on Pluralsight from Cory House

• Becoming an Outlier: Reprogramming the Developer Mind

This course is not intended for everyone but only for the people who really love their work and want to become the best they can be.

Cory created a website to lunch a movement of developers who don't want to be average!

http://www.outlierdeveloper.com/

The manifesto contains three simple statements:

• I’m not interested in being average. I’m out to be exceptional. 
• I’m not waiting to be picked. I’m actively creating opportunities. 
• I’m commanding my time so I can own my trajectory and maximize my impact.

I really like the quotation he used to describe himself.

"If it’s work, we try to do less. If it’s art, we try to do more." - Seth Godin

Software is my art. 

He really inspired me. Are you?

Watch the course and join the movement.

Advanced Algorithms #1 - Union/Find on Disjoint-set Data Structures.

Code
https://github.com/angellaa/AdvancedAlgorithms

Webcast (in Italian)

Slides

Advanced Algorithms #1 - Union/Find on Disjoint-set Data Structures

Questa serie di WebCast ha l'obiettivo ambizioso di aiutarti a costruire competenze algoritmiche avanzate e farti diventare un Top Coder! In ogni lezione, risolveremo insieme un problema complesso per maturare nel tempo un arsenale di tecniche che potrai riutilizzare nell'affrontare qualunque tipo di problema. Scriveremo algoritmi che spesso non sono neanche affrontati in corsi universitari come Depth First Search, Breath First Search, Convex Hull, Kd-Trees, Max Flow, Radix Sort, Suffix Array ecc. Buon divertimento :)

Registrati alla prima sessione: Union/Find on Disjoint-set Data Structures

Kindle Book Summary Creator

I am a proud owner of a Kindle device and I love reading books.

While I am reading a book I always highlight the sentences that I consider more interesting. When I finished a book, I found very useful to copy all the highlights in a notepad to create a summary of the book (usually I save them in workflowy). In same cases, for really interesting books, I often turn the summary to a blog post.

I created a very simple application that helps me to automatically extract highlights from all my kindle books. It is open source and you can find it in this GitHub repository: KindleBookSummaryCreator.

It is straightforward to use:

1. Connect the Kindle to your PC

2. Run the application

The clipping file should be automatically detected. If not, click the Detect button.
Specify the output folder.

3. Click START

The output folder will open automatically. For each book, there will be a text file with all your highlights.

I hope you can find this little application useful as it is for me.

Book: Working Effectively with Legacy Code

Every professional developer have to deal with legacy code in the course of his career.

The book Working Effectively with Legacy Code written by Michael Feather is considered a must read and I really recommend it. This is a summary of the book.
Michael Feather definition of Legacy Code:

Legacy code is simply code without tests.

The goal of every competent software developer is to create designs that tolerate change! This is why it is critical to learn how to confidently make changes in any code base.

The main problem is to make changes while preserving existing behaviour.

Preserving existing behaviour is one of the largest challenges in software development.

The three main questions to ask are:

1. What changes do we have to make?
2. How will we know that we've done them correctly?
3. How will we know that we haven't broken anything?

The main approach is to use tests as a way to detect changes.

But, when there are no tests, we end up in the:

Legacy Code Dilemma

When we change code, we should have tests in place. To put tests in place, we often have to change code.

Sometimes, it is possible to make changes without getting existing classes under tests:

• Sprout Method: develop a new method and call it from the existing code.
• Sprout Class: develop a new class and use it from the existing code.
• Wrap Method: develop a new method that wrap an existing method.
• Wrap Class: create a new class that wrap an existing class (the Decorator Pattern).

A technique like TDD is perfect in this context and only the new method or class will be tested.

However, when you need to touch existing code, it is necessary to do very conservative refactoring to get tests in place first.

The goal is to change as little code as possible to get tests in place.

The steps to follow are:

1. Identify change points
2. Break dependencies
3. Write tests
4. Make changes
5. Refactor

Identify Change Points

Reading through code and playing with the system helps you to identify the change points. It often pays to draw pictures and make notes to improve your understanding.

Scratch Refactoring is a useful technique for learning. Grab the code and start applying refactoring without tests and at the end throw away all your changes. As a result, your knowledge about the code base will be increased.

Object-Oriented Reengineering Patterns is a recommended book for learning how to read and understand large code bases and build a big picture of a project. Once you identified the areas of the code that you need to change, it is important to answer the following question:

If I make some changes here, where I can see the effects?

Answering this questions is very important because it helps to identify which code you should be cover with tests in order to create a good safety net that gives you the confidence you need for subsequent changes.

It is important to know what can be affected by the changes we are making!

Effect Sketching is a useful technique that can be used to answer this question. The idea is to create a little graph that shows the effect of your changes. Navigation tools like ReSharper can help you identify all usages of a particular piece of code. However, if your class has a superclass or subclasses pay attention because there might be other clients that you haven't considered.

A Pinch Point is a narrowing in an effect sketch, a place where it is possible to write tests to cover a wide set of changes. If you can find a pinch point in a design, it can make your work a lot easier. It is a place where tests against a couple of methods can detect changes in many methods. Writing tests at pinch points is an ideal way to start some invasive work in part of a program.

The tests that we are going to write are called Characterization Tests. What the system does is more important than what it is supposed to do. You are not fixing bugs at this stage! The goal is to capture what the system does to increase your confidence of making changes.

How to break dependencies?

Adding tests is not always easy. Often, it is necessary to break dependencies.

The book contains a catalogue of dependency breaking techniques:

• Extract Interface
• Adapt Parameter: wrap a parameter behind an interface
• Parametrized Constructor: create a new constructor that takes the dependency and update the old constructor to use it
• Break Out Method Object: move a long method to a new class
• Extract and Override Call: extract a call to a new method and override it in a testing subclass (ideal to break dependencies on global variables and static methods)
• Extract and Override Factory Method: extract hard-coded initialization work from a constructor to a factory method and override it in a testing subclass.
• Parametrized Method: if a method creates an object internally, pass the object from the outside
• Pull Up Feature: you can pull up a cluster of methods into an abstract superclass and you can subclass it to create instances in your tests.
• Push Down Dependency: make a class abstract and create a subclass that will be the new production class and push down all problematic dependencies into that class.
• ...

For languages like C and C++ it is possible to use some specific techniques like:

• Preprocessing seams: use ad-hoc macros to replace behaviour in tests
• Link seams: override behaviour linking to a different implementation in a test module
• Replace Function with Function Pointers: use pointers in tests to swap real implementation with fakes
• Template Redefinition (C++ only): make a class a template and instantiate the template with a different type in the test file.

In using these techniques it is very important to try to preserve signatures whenever possible! It is always better to do this work using pair programming.

Working in legacy code is surgery, and doctors never operate alone.

Consider reading the book Pair Programming Illuminated. Refactoring

One of the most important principle to keep in mind is the Single Responsibility Principle. It is important to find responsibilities and extract classes when required. You can start applying it at the implementation level. It makes it easier to introduce it at interface level later.

Try to describe the responsibility of the class in a single sentence.

The best way to get better at finding responsibilities is to read more books about design patterns and in particular to read more code.

You can identify responsibilities using the following techniques:

• Method Grouping
• Hidden Methods: many private or protected methods indicates that there is another class
• Coupling between variables and methods
• Sketch (dependency graph between methods)

When you do refactoring, remember to do just one thing at a time.

Programming is the art of doing one thing at a time!

Ask your partner to challenge you constantly asking: What are you doing?

Remove duplication as much as possible! 

You end up with very small focused methods. The goal is to have orthogonality in the system. Your system is orthogonal when there is only one place you have to go to make a change. Removing duplication often reveals design.

Remember, code is your house, and you have to live in it.

Rename Class is the most powerful refactoring. It changes the way people see code and lets them notice possibilities that they might not have considered before.

Consider the Command/Query Separation Design Principle. 

A method should be a command or a query, but not both. A command is a method that can modify the state of the object but that doesn't return a value. A query is a method that returns a value but that does not modify the object.

Extract Method is a core technique for working with legacy code. You can use it to extract duplication, separate responsibilities, and break down long methods. It is also recommended to extract methods in a bottom up approach. Extract small pieces first!

Conclusion

It is true that working with legacy code can be frustrating at times. However, it is only a matter of perspective and approach. Working with legacy code can be fun and doing it using pair programming is a way to get a better result.

Surely, working with legacy code is a challenge and offers the opportunity to significantly improve your software developer skills. In any case, I totally agree with what Michael Feather say at the end of the book.

There isn't much that can replace working in a good environment with people you respect who know how to have fun at work

Design Patterns Series - Learn Design Patterns quickly

What is a design pattern?

From Wikipedia:

In software engineering, a design pattern is a general reusable solution to a commonly occurring problem within a given context in software design.

I think that learning design patterns and the underline Object Oriented Design principles is really important. However, it is really difficult and time consuming. It requires a fair amount of discipline.

This is why I created this series of posts.

This post is a simple index that aggregates all the post I have written in the last two years. Most of the frequently used design patterns are covered but there are many others to cover.

I will update this post as soon as I create a post on a new Design Pattern.

My goals for this series of posts

• Read a lot of resources and consolidate the information in a single post
• Present the pattern in a easy way
• Write a good example to illustrate the benefits of using the pattern
• Put the pattern in the context of .NET
• Find real examples of the pattern in the .NET Framework

My main sources of information

• Book: Design Patterns: Elements of Reusable Object-Oriented Software
• Book: Head First Design Patterns
• Book: C# 3.0 Design Patterns
• Pluralsight: Design Pattern Library
• Articles and blogs on the Internet

 Design Patterns Posts

• Strategy Design Pattern
• Observer Design Pattern
• Decorator Design Pattern
• Factory Method Design Pattern 
• Abstract Factory Design Pattern
• Singleton Design Pattern
• Command Design Pattern
• Adapter Design Pattern
• Facade Design Pattern
• Template Method Design Pattern
• Iterator Design Pattern
• Builder Design Pattern
• Prototype Design Pattern
• Bridge Design Pattern
• Composite Design Pattern
• Flyweight Design Pattern
• Proxy Design Pattern
• Chain of Responsibility Design Pattern
• Interpreter Design Pattern
• Mediator Design Pattern
• Memento Design Pattern
• State Design Pattern
• Visitor Design Pattern

Hope you find this series of posts useful.