I updated my clean code cheat sheet.
This time there are just minor changes:
- Principles: mind-sized components
- Class Design: do stuff or know others, but not both
- Maintainability killers: tangles
- Refactoring patterns: refactor before adding functionality, small refactorings
- removed duplication regarding one test asserts one thing
- TDD principles: Test domain specific languages
- fixed a bug in the ATDD/TDD cycle (run all acceptance tests)
If you miss something or think that there is something just plain wrong, please write a comment below.
Link: Clean Code V2.4
cross-post from http://blog.bbv.ch/2013/06/10/legacy-code-and-now-what/
Every day is a ground hog day. It is eight o’clock in the morning. You come into the office, look at the Scrum board of your current project and pick the next task of the user story with the highest priority. You sit fully motivated in front of your computer, open up your favorite IDE and start to implement the task. But wait! Something is wrong! First, you have to fully grasp the code you tend to put the feature into. But there is a lot of code in that area, which needs to be understood, analyzed and put into context with the feature you are implementing. You start drawing a sequence diagram of what is going on in that code but the more you dive into it the more confusing it gets. The motivation decreases, frustration chimes in. Maybe someone in your team can help you understand the code. You call your colleague, who immediately sits down with you trying to help understanding. Minutes later your friend has no clue either and tells you to “just freaking hack it into the code”. Despite feeling a bit dirty you have no other chance than to hack it. The feature has to be completed better yesterday than tomorrow! But you are a hero, aren’t you?! You can do it! The motivation comes back and finally you get the task done and the feature you are working on is ready to be demonstrated during the sprint review.
The sprint review starts, your product owner and your team members are gathered around the demo computer. You are first to show your new feature to the product owner. The feature works and fully impresses your product owner. Now, it’s your team mate’s turn to present the feature he has been working on. He starts presenting, but suddenly… BOOOM… the application crashes. Your colleague almost freaks out because he wanted to receive a pat on the back from the product owner, too. He blames you for killing his feature. The product owner gets angry and suddenly starts complaining about your team making more mistakes than pushing out new features. Your team mate finally says what your team always had in mind: He demands a rewrite of the whole software because you have reached a state where you cannot add any new features without severely damaging old ones. But guess what! Your product owner demands more features nonetheless. And he wants them now!
Do you recognize the situation? Let us analyze what happened here.
There is an updated version at http://www.planetgeek.ch/2014/11/18/clean-code-cheat-sheet-v-2-4/
It took me about one and a half year to update my cheat sheet about clean code and TDD.
But now, it’s here.
The cheat sheet has grown quite a bit and now contains principles, patterns, smells and guidelines for
- clean code
- class and package design
- TDD – Test Driven Development
- ATDD – Acceptance Test Driven Development
- Continuous Integration
I had to re-layout the sheets because maintenance became a nightmare (yes, very ironic).
Download: Clean Code V2.2
This work is licensed under a Creative Commons Attribution 3.0 Unported License.
Feedback is highly welcome. Please write a comment below.
Update V 2.1: thanks for your feedback
- added + and – for DOs and DONTs to make it easier to tell them apart
- added a creative commons Attribution 3.0 Unported license.
Update V 2.2:
- changed the colours to be better distinguishable
This is the presentation I gave at the .Net System Event by bbv Software Services AG in Lucerne in June 2012:
Lately, I wrote quite a lot of acceptance tests. I simulate that the application is started-up and perform all features requested by our customer to make sure that they work as expected. In order to make these tests fast so that they can be run on every commit to the version control system, I simulate all interaction with the environment of the application: views, database, file system, registry, share point and so on.
To get the most out of these acceptance tests, I want to fake as little as possible. And here comes the Rebind feature of Ninject into play. I can bootstrap the application as in production and then replace all components interacting with the environment by simple calls to Rebind.
These are the slides along with some comments from a presentation I gave lately in the bbv .Net System boot camp – the yearly education week of my division in my company.
Once upon a time, Agile Software development came to our software development country.
Like a monster, Agile software methodologies scared the hell out of us. Suddenly, we had to find ways how to build software so that we could keep up with the high rate of change, just-in-time requirements and a sacrificial offering – a product increment – every two weeks (our Sprint length).
The way we were used to build software was not up to this task. We were used to dig a big hole of new functionality and to build something great over months. The structure of our source code and our engineering practices were no good to match the Agile monster.
So we had to come up with some new “weapons” to stand a chance: