Sunday, May 30, 2010
Agile Transitions is an open forum that allows community members to discuss a range of executive-focused topics, including IT governance, organization, budgeting and financing, risk management, HR issues and enterprise adoption and integration.
Thursday, May 27, 2010
Monday, May 24, 2010
I will be doing a series of webcasts starting tomorrow at 12:00 EST
I figured this timing is the best because it allows people from Europe to the Pacific to have it within "working" hours.
The first webcast will be "The Ubiquitous Language is not ubiquitous". To join the meeting come to https://global.gotomeeting.com/join/153015861. It will also be recorded and placed online (viddler maybe?) to be posted on the blog after.
I will be doing one of these every week or two until further notice. Feel free to drop ideas here in comments for future webcasts
Fluent NHibernate, a statically compiled alternative to NHibernate's standard hbm xml mapping.
Tuesday, May 18, 2010
Some reasons for asking include
- getting information from values and collections
- using a factory to create new objects
- asking objects about their state when searching or filtering
When asking though it is important not to expose the internal structure of your object. For example instead of this code
carriage.getSeats().getPercentReserved() < percentReservedBarrier
carriage.hasSeatsAvailableWithin( percentReservedBarrier )
The method hasSeatsAvailableWithin asks the question you really want answered instead of asking for the information to help you figure out the answer yourself. Or in other words you write a query that describes the intention of the calling object not just the implementation. Doing this moves the behavior to the most appropriate object, gives it an explanatory name, and makes it easier to test.
Monday, May 17, 2010
They called it train wreck because the getters are chained together like the carriages in a train. I have never heard that before but I thought it was pretty funny.
They recommended changing the code to something like this
They made a good point about the method name. They said it should say something about "what the method is for" not just "how it is currently implemented".
I ran into an example of this the other day. We trying to make a conditional more expressive so we changed this code
if (property !== "query")
var isNotQuery = property !== "query";
The explaining variable what was put in to try and explain why we needed the conditional. When we looked at the code though it didn't really add much so we changed it to this
var isNotExtReservedWord = property !== "query";
Now you can see that "query" is a reserved word so it was filtered out.
Wednesday, May 12, 2010
I used to think commenting my code was the responsible thing to do. I used to think that I should have a comment for just about every line of code that I wrote. After my first read of Code Complete, my views changed pretty drastically.
Execution – actually having the team get things done– requires people to :
- Say what they will do
- Mean it (be committed)
- Do it
Everyone likes to do #1. Only some do #2. Great teams also do #3.
Tuesday, May 11, 2010
James Shore consults and writes about high performance software development for teams who are willing to be great.
Thorough unit testing helps us improve the internal quality because, to be tested, a unit has to be structured to run outside the system in a test fixture. A unit test for an object needs to create the object, provide its dependencies, interact with it, and check that it behaved as expected. So, for a class to be easy to unit test,
the class must have explicit dependencies that can easily be substituted and clear responsibilities that can easily be invoked and verified. In software engineering terms, that means that the code must be loosely coupled and highly cohesive—in other words, well-designed.
When we’ve got this wrong—when a class, for example, is tightly coupled to distant parts of the system, has implicit dependencies, or has too many or unclear responsibilities—we find unit tests difficult to write or understand, so writing a test first gives us valuable, immediate feedback about our design. Like everyone, we’re tempted not to write tests when our code makes it difficult, but we try to resist. We use such difficulties as an opportunity to investigate why the test is hard to write and refactor the code to improve its structure. We call this “listening
to the tests”
So admittedly I don't think I understand all of this, but it gives me hope that the book will teach me more about these ideas as I go and I will learn to build better designs.
It goes on to talk about how the different types of tests fall into these categories
Running end-to-end tests tells us about the external quality of our system, and writing them tells us something about how well we (the whole team) understand the domain, but end-to-end tests don’t tell us how well we’ve written the code. Writing unit tests gives us a lot of feedback about the quality of our code, and running them tells us that we haven’t broken any classes—but, again, unit tests don’t give us enough confidence that the system as a whole works. Integration tests fall somewhere in the middle.
I am not sure what type of test you would call our tests. My guess is it would be acceptance tests. The focus of our tests are mainly on making sure the software does what we would expect it to. The focus of our tests has not been on making sure the internal structure of our code is clean.
Monday, May 10, 2010
Saturday, May 8, 2010
Wednesday, May 5, 2010
When we’re implementing a feature, we start by writing an acceptance test, which exercises the functionality we want to build. While it’s failing, an acceptance test demonstrates that the system does not yet implement that feature; when it passes, we’re done. When working on a feature, we use its acceptance test to guide us as to whether we actually need the code we’re about to write—we only write code that’s directly relevant. Underneath the acceptance test, we follow the unit level test/implement/refactor cycle to develop the feature
We have had the question come up a couple times about whether we should be writing unit tests and acceptance tests and what happens if they overlap. It seems like the book is advocating you do always do both. You write the acceptance test to guide you on whether you actually need the code you are about to write. The acceptance tests also show demonstrable progress on customer features. The unit tests support the developers by helping them write high quality code and protecting against regression failures while refactoring.
The book also recommends that acceptance tests should be end-to-end tests meaning they interact with the UI and not call directly into the code. On every check-in they
1) check out latest version
2) compile code
3) run unit tests
4) integrate and package system
5) perform a production like deploy into a realistic environment
6) exercise system through external access points by running acceptance tests
Tuesday, May 4, 2010
The catch is that few developers enjoy testing their code. In many development groups, writing automated tests is seen as not “real” work compared to adding features, and boring as well. Most people do not do as well as they should at
work they find uninspiring.
Test-Driven Development (TDD) turns this situation on its head. We write our tests before we write the code. Instead of just using testing to verify our work after it’s done, TDD turns testing into a design activity. We use the tests to clarify our ideas about what we want the code to do. As Kent Beck described it to us, “I was finally able to separate logical from physical design. I’d always been told to do that but no one ever explained how.” We find that the effort of writing a test first also gives us rapid feedback about the quality of our design ideas — that making code accessible for testing often drives it towards being cleaner and more modular.
On all the teams I have been on "Tests" have always been a dirty word. Something you do because you are supposed to not something you do because you take pride in it. I hope the book goes into more about how TDD can help your designs. I think most people I work with do take pride in their designs and are always looking to improve in that area. Seeing TDD as a technique to improve designs might be something people could be inspired by. I think it will take more evidence though than just one statement.