ariejan/devroom.io
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

Update typos in posts

Browse Source
This commit is contained in:
Ariejan de Vroom 2014-05-09 10:08:39 +02:00
parent 88f6dd6e70
commit 6900905efe
1 changed files with 37 additions and 93 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

120
content/posts/2014-04-04-dealing-with-technical-debt.md
View File

@ -12,54 +12,29 @@ summary: |
note: |
This is a cross-post from my original post a <a href='http://blog.kabisa.nl/2014/04/04/dealing-with-technical-debt/'>blog.kabisa.nl</a>.
---
The rails project I'm talking about is over three years old and has seen
commits from 27 developers in that period. These developers were both
co-workers, freelancers, off-shore developers and designers of different
levels of expertise.
The rails project I'm talking about is over three years old and has seen commits from 27 developers in that period. These developers were both co-workers, freelancers, off-shore developers and designers of different levels of expertise.
## Technical Debt Inventory
Needless to say, as most projects of this size and age, this one has plenty of
technical debt. Let's make an inventory.
Needless to say, as most projects of this size and age, this one has plenty of technical debt. Let's make an inventory.
<img src="/img/20140404-01.png" class="center bordered" />
<img src="http://blog.kabisa.nl/wp-content/uploads/2014/04/20140404-01.png" class="center bordered" />
**The test suite takes approximately eighty minutes to run.** These are all
RSpec tests, including features. Luckily we can split the entire suite up
into smaller parts using Travis, but still the entire thing takes about
fourty minutes.
**The test suite takes approximately eighty minutes to run.** These are all RSpec tests, including features. Luckily we can split the entire suite up into smaller parts using Travis, but still the entire thing takes about forty minutes.
The main cause for these slow specs is a lack of understanding about how to
write _good tests_. For example, testing if search and pagination works,
someone thought it fine to create fifty ActiveRecord objects in a before
block.
The main cause for these slow specs is a lack of understanding about how to write _good tests_. For example, testing if search and pagination works, someone thought it fine to create fifty ActiveRecord objects in a before block.
These big offenders are easily remedied. Others are a bit harder, as
some specs require an ellaborate tree of models to test functionality.
These big offenders are easily remedied. Others are a bit harder, as some specs require an elaborate tree of models to test functionality.
**This project has no cucumbers to discuss and review features with
Product Owners.** These cucumbers would have been awesome to discuss
features both with product owners and team members. But at the start of the
project cucumber was deemed _too much hassle_ and Rspec feature specs were
used instead.
**This project has no cucumbers to discuss and review features with Product Owners.** These cucumbers would have been awesome to discuss features both with product owners and team members. But at the start of the project cucumber was deemed _too much hassle_ and Rspec feature specs were used instead.
The main issue now is that the line between features specs and unit specs
is a thin one and people often mistake one for the other. This is probably
one of the reasons so many specs create many models and make the entire
suite slow.
The main issue now is that the line between features specs and unit specs is a thin one and people often mistake one for the other. This is probably one of the reasons so many specs create many models and make the entire suite slow.
**There are parts of the code that are not well tested - or not at all.** This
is a dangerous one. Because, from the start, nobody monitored test coverage or
did proper code reviews, there are patches of code that are not well tested,
and there are some that are not tested at all.
**There are parts of the code that are not well tested - or not at all.** This is a dangerous one. Because, from the start, nobody monitored test coverage or did proper code reviews, there are patches of code that are not well tested, and there are some that are not tested at all.
There are various factors to why this happened, but lack of pair
programming, code review and pressure to finish a product have resulted in
this.
Pressure to finish a product has led to to cutting corners in code quality and test coverage.
**Lots of smells and lots of noise.** All the points above indicate there
is a certain amount of technical debt in this project. Another pointer are
_code smells_. To name a few I've seen over the past few months:
**Lots of smells and lots of noise.** All the points above indicate there is a certain amount of technical debt in this project. Another pointer are _code smells_. To name a few I've seen over the past few months:
* Long methods
* Conditional Complexity
@ -74,54 +49,38 @@ _code smells_. To name a few I've seen over the past few months:
* Train Wrecks (or Message Chains)
* Feature Envy
All of these found their way into the project, sneaking in besides our best
efforts to pair program and code review almost religiously.
All of these sneaked their way into the project.
## Why does this matter?
The product we ship works. Although the specs take a long time to run, and
there are some code smells in there, the suite is actually green and we
have confidence the product works as expected.
The product we ship works. Although the specs take a long time to run, and there are some code smells in there, the suite is actually green and we have confidence the product works as expected.
So why complain about technical debt? In my opinion as a software
craftsman, softare should
So why complain about technical debt? In my opinion as a software craftsman, software should
1. work
2. be clean and readable
3. allow for change
4. be well tested
Well, the code works. But clean, readable, easy to change and well tested are
debatable.
Well, the code works. But clean, readable, easy to change and well tested are debatable.
Responding to change is still possible, but it's a bit more painful than
it should have been. There are some untested patches of code that we would
really would like to see tested. And of course, code should be readable and
easy to understand. We don't always have these things and it's holding back
progress sometimes
Responding to change is still possible, but it's a bit more painful than it should have been. There are some untested patches of code that we would really would like to see tested. And of course, code should be readable and easy to understand. We don't always have these things and it's holding back progress sometimes
## So, you have some Technical Debt on your hands
Recently two new developers joined this project and they immediately asked
the right question:
Recently two new developers joined this project and they immediately asked the right question:
***What can we do to make this project better?***
In my opinion, as a software developer, this is the one magic question.
What can _you_ do, right now, to make this project _better_.?
In my opinion, as a software developer, this is the one magic question. What can _you_ do, right now, to make this project _better_.?
Besides the fact that you ask yourself what you yourself can do, there's
another important component in that question: _better_.
Besides the fact that you ask yourself what you yourself can do, there's another important component in that question: _better_.
It's not about fixing all the things. It's about improving the things you
touch just a tiny bit. Over the course of a few weeks or months these small
improvements start to add up and really make a difference.
It's not about fixing all the things. It's about improving the things you touch just a tiny bit. Over the course of a few weeks or months these small improvements start to add up and really make a difference.
It's often called the _Boy Scout Mentality_. Leave things behind in a better
state then how you found them when you arrived.
It's often called the _Boy Scout Mentality_. Leave things behind in a better state then how you found them when you arrived.
So, although the projects works fine, we as developers are now constantly
improving the code and specs we touch.
So, although the projects works fine, we as developers are now constantly improving the code and specs we touch.
## Eliminating Technical Debt
@ -142,41 +101,26 @@ made quite a dent.
The overall objective is this:
***Whatever you do, leave it in a better shape than you found it in. This
goes for code, documentation, specs, whatever.***
***Whatever you do, leave it in a better shape than you found it in. This goes for code, documentation, specs, whatever.***
When implemting features or changes, we use a few simple steps to help us
along:
When implementing features or changes, we use a few simple steps to help us along:
* **Is this code I'm about to change well tested?**
If not, fix it now. Update those specs to be more efficient, handle
the edge cases you see popping up right now. Write cucumbers.
If not, fix it now. Update those specs to be more efficient, handle the edge cases you see popping up right now. Write cucumbers.
* **With your improved specs green, refactor the existing code**
Your new specs suite is fast and elegant. Use it to refeactor the
existing codebase to make change easier.
Your new specs suite is fast and elegant. Use it to refactor the existing codebase to make change easier.
Congratulations, you have just made your life much easier. Note that you have
not written a single line of code yet for you new feature or change. But the
cleaning up you just did will greatly benefit you and the time it takes to
write this feature.
Congratulations, you have just made your life much easier. Note that you have not written a single line of code yet for you new feature or change. But the cleaning up you just did will greatly benefit you and the time it takes to write this feature.
* **Write specs for your change or feature**
This is quite easy now, as it should add nicely to the changes you made
in the first step.
This is quite easy now, as it should add nicely to the changes you made in the first step.
* **Implement your features or change**
Because you refactored most of the code smells out in the second setp, you
should be able to easily change your code.
Because you refactored most of the code smells out in the second step, you should be able to easily change your code.
These are four easy steps to minimize technical debt in your project.
You should not wait until you hit the technical debt limit of your project.
Minimizing technical debt is just as important as writing tests. It should
be a team priority from _Day 1_.
You should not wait until you hit the technical debt limit of your project. Minimizing technical debt is just as important as writing tests. It should be a team priority from _Day 1_.
Minimizing techincal debt is not all too different from doing proper
test driven development. It requires rigorus discipline and skills. And just
like with tests, you will not handle that technical debt after this crunch
period.
Minimizing technical debt is not all too different from doing proper test driven development. It requires rigorous discipline and skills. And just like with tests, you will not handle that technical debt after this crunch period.
Next time you open a project, ask your self, _"How can I leave this project
in a better state than I just found it?"_
Next time you open a project, ask your self, _"How can I leave this project in a better state than I just found it?"_