I’m just laughing my @$$ off at this one:
AntiPaste, because Pasting Code Is Harmful
I couldn’t have said it better myself. If I could remove Ctrl+C/Ctrl+V from the keyboards of every junior developer the world would be a better place. Though this solution might be a bit extreme, the lesson it’s trying teach is well worth learning.
Just a quick update on where I’ve been the past few days. I have been coding up some additions to the library and migrating some existing code to it. I’m working on preparing a end-user deliverable to go open source and some of this is supporting code. I should have the changes published out in the next day or so.
Recently I’ve been following Roy’s ISerializable blog’s series on test-case reviews:
Test Review #1 – NerdDinner
Test Review #2 – ASP.NET MVC
Test Review #3 – Unity
They have been fairly informative and full of insight into Roy’s view of proper testing. One thing he keeps commenting on continues to strike a nerve of mine. Roy clearly believes that a single assert per test is THE way to go. My problem is I still fail to see his reasoning here. He has stated in all three videos that this is a bad idea since all the asserts after the first failure will not execute. OK, this is true; however, isn’t the goal to make it all pass and if so why does it matter? Even if the arrange/act of the test is only 1 or 2 lines, I would be livid with a developer that copy/pasted those lines into 20+ functions just so he could have a single assert per test. Doesn’t that make it unmaintainable? Doesn’t spreading this across 20+ methods make it hard to read?
What are your thoughts? Do you write a single assert per test? How much duplication of code do you then suffer?
I seem to find myself talking with developers that seem to have some fixed notion of agile development. They speak like it’s an implementation of XP (eXtreme Programming), or TDD (Test Driven Development), or some other fairly concrete methodology. Maybe it’s just me, but I really think this misses the whole point?
In my world, agile development is simply the practice of being prepared to change. When you apply this generic statement across the entire development process you start getting a picture of what I’m talking about. It’s not just about test cases, refactoring code, or any other concrete thing. It’s a mindset that adapts across everything you do.
Why do we write unit tests for our code? So we can change it.
Why do we use interfaces instead of class names? So we can change it.
Why do we use DI (Dependency Injection) or IoC (Inversion of Control) to some? So we can change it.
Why do we design as needed only what is needed? So we can change it.
Why does a release not have a fixed set of features? So we can change it.
Being an agile developer is about recognizing one of life’s truths: “Things change”. We expect it, plan for it, adapt to it, and ultimately embrace it in everything we do.
PS: Have you noticed being adaptive to change is also a great skill outside of work ;)
I couldn’t have said it better myself. This is an old topic for Jay and I have to credit him for bringing continuous integration into my own life many many years ago. Back in November he wrote a post about builds “Building Software Is Easy“. He captures the main point, it’s all too often ignored by development in favor of what is believed to be simple solutions.
These ‘simple’ solutions often involve generation of master ‘solution’ files in VS.Net and are horrible to maintain. Projects fall off radar as soon as they are removed, some never get added in the first place. Inter-project dependencies can also become issues that have to be carefully hand-crafted at times between projects. All this speaks nothing about deployment, configuration issues, testing, version control, and build-time dependencies. To say it in one sentence: “These ‘simple’ solutions fall short in every way”.
Ask yourself the following:
I’m not suggesting you write a massive hierarchy of makefiles or one giant NAnt script. This is a problem that can be solved. What it requires is development effort, time, and dedication.
The comment on the post linked above strikes me as more funny, Julian Simpson writes:
My new theory is:
If it’s available from an IDE, developers will take it on. Hence, you can convince Java developers to have a go at an Ant build because there’s usually IDE support. NAnt? Nope, there’s no native support in Visual Studio.
I find it hard to get .NET developers working on the build. Java developers will approach it. I don’t think they’ll refactor build files unless there’s a plugin.
She is probably right here. It’s not fun work, it’s not challenging, it’s not glamorous work, it’s just work.
I’ve seen these issues many different times and solved them many different ways, some worked well, others did not. Recently we are using some C# to crawl the projects and load them with the Microsoft.Build API and enforce the configurations that way. Seems to work well for us in manipulating all the little settings needed correctly and consistently build. We use another tool I wrote some time ago to actually do the build. Yes we again crawl the entire directory for C# Projects, topo-sort the dependencies, and invoke the build programmatically. Of course you could just as easily output a NAnt file or some other script to run the build once you know what to build and in what order.
Regardless of your solution, you will have to put some development time into it if you want the build to solve problems … or … you may be happy with your build being a problem?
I’ve been reviewing a lot of blog sites lately reguarding testing and unit test practices. One I ran across this morning entitled “Extract and Override refactoring techinque” caught my eye on Taswar Bhatti’s Blog. Don’t get me wrong here, I tried to read this objectively and understand where he was coming from; however, I am [...]
This is the one, the only, the quintessential rule to programming. AKA, the KISS method (Keep It Simple Stupid) is, to me, words to live by. From the implementation of a simple class to the design of a complex application you constantly have to keep this in the forefront of your mind. Far too often I [...]
Well it’s only been a week since go-live and things are progressing. Not as fast as I’d like, but good enough. I’d thought I’d give a roadmap of things to come. Sections comming soon: – Coding – Building – Testing These should be obvious. The not-so-obvious are projects to come. Here they are: – CSBuild [...]
Found an interesting post over on ISerializable – Roy Osherove’s Blog that outlines a few of the things that should be considered when designing software component interfaces. To re-summarize and add my own two cents worth here they are in my own order of importance. Resilience – (the best single-word description I can come up with) [...]
Not that I personally feel strongly about this, but some like to have a help file to browse. I am much more partial to C# and test-cases as documentation; however, this was really quick effort thanks to Dave Sexton’s work on DocProject. It greatly simplified the entire help-building process into something easy and repeatable thanks [...]