I compiled a reference of principles, concepts, methods and so forth on architecture in agile software development.
If you are a software architect or developer, this is for you.
Clean Architecture V1.0
Comments about what you like or your opinion on the topic are very welcome.
Many thanks to for making this blog post possible.
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
How do you build your Visual Studio solution, verify your coding guidelines and execute tests?
What steps do you take when adding a new project to your Visual Studio solution?
Living in the past
Let me summarize my past experience. I have tried several different approaches, all of them involved build scripts, and Visual Studio Project Templates or manual editing of *.csproj files. I don’t like any of the approaches. Why? I will show you some drawbacks of this kind of build definitions.
- you have to learn a scripting language
- you try to solve problems which you would solve in your preferred .NET language with less effort
Visual Studio Project Templates:
- making up-to-date versions available to all team members is a PITA (pain in the
- update your templates and you still have to update all previously existing *.csproj files manually
- if you change your build process (e.g. enable StyleCop) you have to release and distribute a new version of your templates
Imagine the unimaginable
This is the presentation handout for a presentation I gave at the bbv Techday 2013. Special thanks to Jeffrey Palermo for supporting me. Chopping onions usually makes you cry. This is not the case in software architecture. In contrary! The onion architecture, introduced by Jeffrey Palermo, puts the widely known layered architecture onto its head. Get to know the onion architecture and its merits with simple and practical examples. Combined with code structuring by feature your software is easy to understand, changeable and extendable. Turn your tears of sorrow into tears of delight.
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 conference Basta! in September 2012.
Before we can talk about Agile quality assurance, we have to make a step back and take a look …
… at the goals of Agile software development. Our Agile quality assurance strategy should support these goals:
In my current project, we do a lot of refactoring to keep the source code as simple and understandable as possible. This involves a lot of renaming of classes and moving classes between namespaces to structure the code in a better understandable way (here is explained how we structure our code). Sometimes, this results in unit tests not renamed or moved along with the production classes they test.
Therefore, I wrote some NDepend queries that show us these misplaced or misnamed test classes.
cross-post from bbv blog
When software projects grow both in age and size the developers often struggle with the structure of the code. It gets more and more difficult to find the class you have to change for a new requirement. In this post, I’ll show you how we organize our code and how we derive our structure directly from the requirements.
Some time ago, Patrick Smacchia (NDepend lead developer) offered me a NDepend Pro license to play around. NDepend is a tool providing a lot of features. The feature that impressed me from the very start is visualizing dependencies. Not just dependencies from classes to classes, or assemblies to assemblies; no from everything to everything. Like for example all assemblies that use somewhere the method Foo of class Bar. It works for assemblies, namespaces, types, methods and fields.
But, what’s all this fuss about?
Keeping a code base and its design as simple as possible over a long period of time is very difficult. It happens just too quickly that we loose the overview of how things are sticked together. And this is the moment when NDepend with its quick and easy dependency visualization comes to the rescue.