Mahmut Canga

These are my notes from the book Beyond The Legacy Code by David Bernstein. I think most of the items here are always acknowledged by developers, managers etc. but really applying them in daily development activities take a lot of time to establish as a culture.

1. Say what, why and for whom before how (turning how into what, don’t tell how to do it. Tell what to do for whom)
2. Build in small batches (code a feature and behaviour to get faster feedback instead of a big release) tell smaller lies! So if you get it wrong, it is not catastrophic 
3. Integrate continuously (ability to get faster feedback) good automated tests and catch bugs even before someone spends time on it to find out. Invest and save others time not yours
4. Collaborate – requires specific skills, mob programming and pair programming. Code together. The most hardest thing to get resistance. Quality goes exponentially better. We are people and not resources. It is not about how fast you type, it is all about how well you write. Less bugs and better quality means better productivity 
5. Create Clean code – c: cohesive that means following single responsibility. L: loosely coupled. Enough abstraction so that dependencies can be easily tested. E: encapsulated. Hide the how with what. Show what I’m doing but hide all the implementation about how I do it. This means freedom to change it without breaking the clients. A: assertive. Objects and entities are responsible for themselves. They are in charge of their state. We put behaviour with the data it works with. N: non redundant. A developer might have implemented the same with different way or name. Avoid doing the same thing in more then one place. We may have different mental models what a term means. So we need to have glossary discussions to make sure we are on the same page.
6. Write the test first – write a test before even writing any code OR before refactoring a legacy code. It means looking from outside in. It helps understanding what I’m doing. This is the what part of development. Statistically maintaining a code is 5 times expensive then creating it. This includes extending and fixing bugs. So we need to write code easier to change. With this you will achieve verifiable code. Gives confidence to change!
7. Specify behaviours with test – we need to know how to write good tests. So it has to be unique and not implementation dependent. So when refactoring our tests shouldn’t be broken. This helps to identify what to test
8. Implement the design the last – get something works and clean it up so that it is supportable and maintainable. Making the decision between coding and cleaning. You don’t know what is clean and dirty until to run and understand its performance. So do not optimise early. It’s much more efficient to edit and clean afterwards rather then in our head while developing.
9. Refactor legacy code (Change the design without changing the behaviour) – up until this point you have to know what the code looks like first.