They’re here – you now have nine days to write your apps
Microsoft really is trying hard to get everyone on the latest and greatest .NET framework! Guess that we will have to take the plunge and use 4.6 now, and we have only just started using 4.5.1
….. oh well !
The .NET Fundamentals team announced in a blog post last week that support for .NET Framework 4.5.1 and older will be ending in 2016.
Nice article that i found about using SOLID to break the CRAP cycle. From experience i know how important this is!
Domain-Driven Design claims that it provides a strategy for building applications that will grow and evolve over time without collapsing under their own complexity. It does that by upsetting some conventional wisdom.
I recently found this really nice icon site, thought i would share it with you.
Search through more than 3600 free icons. IconsDB let’s you customize and download icons. Browse icons by category. Download as ico, icns, png, gif or jpg.
Source: Icons DB – free custom icons
Its been quite a while since I posted anything; I changed jobs, started working with a different language (besides C#) and had to mentor a new team of developers.
Joining the new team of developers had its challenges mainly getting them to understand and implement the concept of agile and sprinting. They had previously been used to the typical waterfall style of development and moving to a looser form didn’t come naturally.
The one thing that I still have not managed to get across to certain members is the fact that you only address current concerns, you don’t leap ahead 5 to 10 months in time and say what ‘might’ be required because the next sprint may totally change the development landscape throwing all your plans out of the window.
It can lead to some quite frustrating conversations, and I sometimes have to suppress the argument with “okay, make a note of those thoughts in an email to us all so that we have them for when we need them”. I’m not trying to dismiss the ideas, far from it, I just want them to focus on the tasks in hand, who knows, we may want there idea later!
Good to know that there is a dedicated community for PRISM. Its a great framework, I’ve been using it for the last 5 years and its made life so much easier being able to compose the User Interface as separate components and inject them where needed.
It would have been nice for Microsoft to continue development of it but i understand what they are trying to achieve through handing it over to a dedicated community.
Fingers crossed that PRISM continues to grow and mature, and lets hope that they make integration with other IoC Containers such as Unity and Castle Windsor a lot easier
The .NET blog (AKA: dotnet blog) discusses new features in the .NET Framework and important issues for .NET developers.
So a few guys here at the office have been reading a book called “Clean Code” where it says that the preceding ‘I’ on an interface name is just a distraction, gives too much information and that the book author doesn’t want users of the code to know that they are talking to an interface.
I say, “why?”. My option is that it gives a clear indication of the indented use of the object. The author also says that he prefers prefixing the implementation of the interface with “imp” ….. so lets get this straight then;
This is bad
Interface : ISomeObject
Concrete Class : SomeObject
and this is good
Interface : SomeObject
Concrete Class : SomeObjectImp
Personally I think that the example that shows the ‘good’ code is wrong, all that he is doing is moving the distraction from a simple ‘I’ to ‘Imp’
Given the two examples above, I know which I think is the clearest.
You may remember a few month ago that I wrote a post about agile software development. One important part of the agile process is being able to get the software tested in a timely fashion. Typical software development strategies say that you deliver the finished product to the tester at the end of the development process; this has several floors:
1) When the product is handed over its the first time that the testers have seen it. Most testing teams think of themselves as customers, meaning that they will be looking at the product with a critical eye. They will pick fault with everything; this is a good thing as it allows us to create a better product.
2) When the test cycle ends the development team may have a large collection of bugs that need to be addressed
3) When the test cycle ends the development team has moved on to something else and the memory of the inner workings of the product have faded.
Points 2 and 3 are very important especially to management. One way to address this in an agile environment is to embed either one or two testers into the agile team.
What does this give us:
1) The testers can see what the developers are up to during the design phase
2) The testers can provide input during the design phase about things that they would test in certain scenarios
3) The developers gain an insight into the things that the tester will be looking for
4) When UI is being considered the testers can give input regarding usage and how they would test it
5) Data validation can be fleshed out with the testers giving valuable input regarding edge cases that they may try
6) The management can see development and test working together to a common goal
The fact that the testers can provide input into the development process is a big win as they will be able to contribute more and more in each scrum iteration.
The goal of each scrum is to try and deliver working software at the end of each iteration. Having an embedded tester means that you can start to provide them with very early alpha releases of the stories that are being delivered.
They can test and advise you of changes in an ad-hoc fashion, they can build up a series of tests that they will perform on the final release code and all the time they can keep the development team informed about what tests they are planning to perform on the code.
This has the effect of making the development team more aware of any potential issues in the code which should lead to fewer bugs being reported at the end of the iteration.
The continuous feedback from the ‘smoke testing’ can feed into the unit tests that the development team create to test the logic of the code being written. The acceptance tests can also be included into the unit tests so that you know that the final acceptance tests will be covered.
When the general testing is complete the only thing that may cause your software to fail is destructive testing where they aggressively test the product in a way designed to cause it to fail with the aim of seeing how the code reacts and what exceptions are created. This can also impact the user experience in a negative way if the product falls flat with huge exceptions / crashes etc…
As a developer, how can you build a good relationship with your testers? Its not as hard, some testers are technically minded, some aren’t. The important thing to remember is that you need to exchange knowledge, as long as both of you are exchanging the knowledge and understanding what it means in the scope of the project life-cycle you can work more effectively as a team.
You may find that the information that the testers are providing to you are either too light on detail, in this situation Its worth spending a little time showing the testers how to effectively collect information for you to use, this could be using 3rd party tools to get information / data. An experienced tester will know quite a few tricks and techniques that they can use to get you information that adds value to the bug report.
Some tools & utilities that I commonly use are:-
– Fiddler Http Debugger Proxy (http://www.Fiddler2.com)
– Log4Net (http://logging.apache.org/log4net/)
– Windows Event Log
– PSR (Problem Step Recorder – build into the Windows OS)
Fiddler is a very effective tool as it allows you to see traffic between and application and a remote resource such as a web service. We find that in conjunction with Log4Net it is possible to get a very good idea of what is occurring in the application during each web request.
PSR is a great tool for capturing a users actual movements, key presses and mouse clicks, it saves the data as an .mht file which you can open in an browser window. It captures the screens and embeds them into the .mht file.
Remember, there is no I in team, communication is key.
The dreaded code review, they are a time consuming unnecessary annoyance that stop us from developing software, right !
WRONG, they are integral to a software quality process. Without a code review strategy any code that you write has the potential to destroy the project. A code review should be something that’s embraced by all developers as it allows you to get another persons perspective on the code.
Most developers work very closely with the code and start to feel very protective over it when people start to suggest changes or say that its just not right or doesn’t resolve the task / bug that it was written to resolve.
In software development you cannot afford to get protective over the code that you write because the code you write on a Monday may be code that someone else is changing on a Wednesday.
Code reviews can be performed in a number of ways, there is the totally independent review where the person who is reviewing the code simply takes the code changes that you have committed to a local source code repository (such as a local GIT repository) and comparing that against the previous check-in’s and to see if the code looks sensible and matches the bug / task brief. The feedback that they give will either be positive; i.e. “the code changes look sound, should be committed” or “sorry, this failed the review because of XYZ please correct this and resubmit for review”.
The independent reviews can be quite harsh as the person who is reviewing the code doesn’t know you, doesn’t care about any issues outside of the code. Getting responses like “what on earth were you thinking!” or “This is utter rubbish” can really get you down, but hopefully with comments like these your reviewer would leave some constructive comments detailing why they think that and maybe even giving an example of how they would have done it.
The review is a two way learning process; you may learn something during the review which will influence the code you write. On the other side you may get comments like “this is pure genius” or “cool code!” which may mean that you have managed to teach the reviewer something that they can take away and implement in their own code.
Another type of review that may occur is where a colleague sits next to you and reviews it as you explain the solution to the problem; they will want to see a suite of passing unit tests, code differences and explanations as to why you implemented it in that way. These reviews, in some respects can be more difficult to deal with as you will know the person. In this type of situation its difficult to tell a person that you know and have worked with for a while that the code is just no good, its also very difficult to hear if your the one being told.
I’ve had this happen to me, being told the code is no good is the beginning of a constructive discussion. My first response when told this was “Ok, so explain to me why and then suggest an alternative solution to the problem”
Assuming that the reviewer has a valid point and there solution is viable you can adjust your code accordingly. Remember that software development is a continuous learning process, know one knows everything and one way that you can extend your knowledge is through processes like this.
The following checklist is something that i think is a good basis for a code review.
- Does the code have comments on the classes / methods / properties and are spellings correct
- Do variables have bad names, do they use abbreviations
- Has code been duplicated, has a method been written elsewhere that does the same thing
- Are null values handled correctly
- Are input arguments being checked (for ranges, for nulls etc.. )
- Are calls to external assemblies correctly trapped with try.. catch blocks
- Does the logic make sense
- Have unit tests been created/modified to cover the code
- Do all unit tests for the solution pass
- Could the code be optimized
- Are there any bad design practices being used
- Does the code meet the coding guidelines of your organisation
- Is it possible for a method to return a null value, does the consuming code handle that
- Does the code contain any logging information, if so does it expose any potential security risk
These are a few examples of things to look for, they are pretty basic so everyone should be able to follow them quite easily.
Here are some things that i try and do when i write code to make the whole development process easier
- Use meaningful variable names, it doesn’t matter if they are long as long as they are not stupidly long and they explain what they are being used to hold
- Avoid using the term “Temp” when naming anything because it wont end up being anything temporary will it
- Avoid using the variable name retVal
- Avoid calling classes / methods “Helper” or “Manager” unless they really are dedicated to managing something
- Try not to create static variables / classes these are very difficult to unit test and are the firsts sign of a “code smell”
- Check arguments as the first step in a method, throw ArgumentException, ArgumentNullExceptions or ArgumentOutOfRange exceptions where appropriate
- Comment all your properties / methods / classes
- Try not to put comments in the body of the code, it looks messy. Your code should be self documenting
These are a few things that i do, it would take a long time to write all of my considerations down but this should be a good start for anyone looking to
In the end its up to you to make your code cleaner and understandable as it will make maintaining it at a later date easier and will make code reviews more meaningful.
I hope that this article has helped you in some way with your code reviews
A lot has been written about software development methodologies, which ones are good, which ones are bad and which ones are just plain ugly.
I guarantee that if you have been developing software for a while that at some point you will have encountered the waterfall model. The waterfall model was a fairly good model it defined the steps in the software development life cycle but it wasn’t very good at iterative development.
The waterfall model didn’t lend itself very well to changing requirements without a lot of pain which generally manifesting itself in specification alteration, agreeing changes with product owners, development and architectural design.
Other models started to appear which tried to address the shortcomings of the waterfall model; The V-shaped waterfall model was one of them, it tried to address the process boundaries in the requirements, testing and delivery phases of the project, but it was still unsatisfactory.
Along comes Agile. Agile provides a way to allow the project to flow and embrace change as it happens (and change WILL happen).
A lot of people think that using Agile is a way for developers to avoid writing specification, to avoid the rigors of quality control ultimately bringing chaos into the organisation. This assumption couldn’t be further from the truth.
There are a number of ‘flavors’ of Agile, the one that I will focus on is called Scrum. So what is Scrum. Put simply Scrum is a process where you divide up the work that needs to be performed into epics, stories and tasks. A scrum consists of ‘sprints'; a Sprint is just a period of time where the developers work on the tasks allocated with the aim of having all tasks / stories implemented by the end of the sprint.
We use a scrum board to help us manage the tasks so that we can visually see what state the project is in. At its most basic the scrum board will consist of the following columns:-
- To do
- In Progress
- In Test
Typically columns A and F wouldn’t be show but are implied. The backlog is the location for all the epics / stories / tasks before they are moved into the To do column.
Typically a sprint will last between two and four weeks ending in a sprint retrospective and a planning meeting.
During the retrospective meeting the team should reflect on the work that was done and assess how they think the sprint went; what went well, what didn’t go well and why, what have the team learnt, what problems occurred and how could they have been avoided.
During the last few days of the sprint the team members should be looking at the backlog of tasks / stories and assessing how long they think it will take to execute the tasks. When the planning meeting starts the team should look at the backlog and add the tasks that they are planning on delivering into the ‘To Do’ column of the scrum board.
Now I’ve given you a brief introduced you to the Scrum board lets take a look at Epics, Stories and Tasks which we will place onto our Scrum board.
An epic is a high level description of a requirement. You will probably have a business requirement for some functionality that needs to be added or a change request that needs to be implemented, each business requirement can be considered an epic. An epic can consist of one or more stories.
An example of an epic could be:-
‘Application’ X should be able to connect to server Y and request data Z every 60 seconds and write the response to a file
A story is a one aspect of an epic. A story describes what is needed at a slightly lower level. Using the epic example described earlier lets try and break this down into one or more stories. What do we have to consider when reading the epic;
- what protocol will be used to communicate with the server Y; will it be HTTP, HTTPS, UDP, TCP
- will the ‘Application’ be a standalone EXE or a windows service
- should the polling be configurable
- when we write the response to a file what security considerations do i need to think about; will we have write access to the location
- is the location that the response is written to configurable.
- is the request asynchronous or synchronous, what happens if the responses overlap if the one request takes a long time to complete
- should request be allowed to timeout
- is the server end-point configurable
I’m sure that you could break this down even more but lets take those and try and create some stories. For now we will assume that we have the answers we require to the questions above.
- The ‘application’ will be a windows service
- It will use the HTTP protocol
- The file location will be configurable
- The folder the file is written to will have write access for the network service account
- The polling time will be fixed at 60 seconds
- The server end-point will be configurable
As a service i want to create a HTTP connection to Server Y
As a service i want to connect to server Y every 60 seconds
As a service i want to store the response from server y in a file
As a service i want to be able to configure the server end-point post installation
… etc …
As you can see these try and describe the requirements but they are not complete. We will now break down these stories into tasks and this is where we need to actually separate the tasks into:
- nice to have
- wish list
‘Basic’ tasks are the ones that we will implement in order to get the minimum functionality in place.
‘Advanced’ tasks are the ones that build on the ‘basic’ tasks and introduce more functionality
‘Nice to have’ tasks are the ones that we will implement if all advanced tasks are complete
‘Wish List’ tasks are the ‘Bells and Whistles’ tasks that will make the project shine
Lets take Story 1 and see what tasks we can break this down into.
As a service i want to create a HTTP connection to Server Y
– Connect to server Y using a synchronous web reference
– When a connection cannot be created the service should throw an exception
– Connect to server Y using an asynchronous web reference
– When a connection cannot be created the service should write the exception to a log file
Nice to have
– When an exception is thrown details should be written to the system event log
– The server end-point should be configurable
– Allow the web reference to be injected using IOC so it can be reused by other classes and modules
When we create our tasks we wouldn’t include all of the tasks on our scrum board, we would only initially add the ‘Basic’ tasks and associated stories. The idea being that we should move the tasks from the left hand side of the board to the right hand side of the board during a single sprint; implement a ‘straight-line’ solution that, when committed to source control would mean that we have a solution that builds and does the basics.
All the tasks on the board should have the same priority so any developer should be able to pick up any task and begin work. When you have a series of stories it makes sense to make someone a story ‘owner’, this means that they are responsible for:-
- Writing any supporting documentation
- Understanding the requirements
- Managing the implementation of the tasks between developers collaborating on the story
- Developer testing the story
- Making sure it passes any user acceptance tests that have been defined around the story
- Demonstrating the story at the end of the sprint.
The next article will look at:-
The enhancing the stories with ‘Advanced’ and ‘Nice to Have’ Tasks
Please check back soon