Top things I do on every software project
Every software project is particular and has its own features, but in general there are things that are common across the industry! In this post I would like to mention things that in my opinion are a must and that I am currently following whenever working on a project. The priority of the list is not given by the order as it would largely depend on the project size, team size, priorities, milestones and timeline. Depending on the project some of them will have a bigger or smaller role.
The following are the points I find very important and do in every project, which is something I recommend to you as well!
As a general concept, it’s not that important which Version Control system are you using or going to use; Subversion, Git, TFS or many others, the important thing is that the source code is versioned. Advantages of versioning the source code are many, and just to name a few:
- Facilitates Team Communication: Everyone in the team is able to see the work or others.
- Secure Access to Source Code: Not everyone should be enabled to commit or change the code, or some parts of it.
- Capture File History: Every file change will be captured and hopefully browsable.
- Baseline Trace Ability: It is possible to create snapshots of code to a given moment in time.
- Automated Merge Capabilities: It usually offers a streamlined way of merging changes made by other team members.
- Ensures no one Over-Writes Someone Else’s Code: Because everything is tracked, usually the system will make sure to avoid overwriting other people work.
It is highly recommended to keep the version control system on a separate server and to keep backups
Continuous Integration is extremely useful especially when several people work on a project (but it is not limited to it!). Being able to build and integrate the work of the team frequently (continuously, daily, nightly, …) gives a big advantage. Continuous Integration tools usually offer several functionalities among which are building the software (primary role), enabling testability automation, team notification, monitoring, etc.
Being able to execute automatically Unit and Integration Tests, deployments, packaging, etc; enables the team to be more productive (by avoiding repetitive work) and to spot problems early in the development phase.
However, don’t forget that setting up the server (which again is recommended to run separately) will often need some initial setup time!
Build via command line
This is one of those things that will come automatically, especially if using or planning to apply Continous Integration. Being able to run the compilation of the project without opening the IDE gives several advantages. Once the command line building is enabled, sky is the limit. Usually what I do in almost every project is to enable, via command line build the packaging (usually zipping the outcome), building installers, running unit or other kind of tests, checking code coverage, checking standards and eventually deploying the outcome either to a development environment or to a server.
Two big advantages to mention is that once the build procedure is built, we automate and standardize the process, which hopefully results in a greater quality.
I generally use a combination of MsBuild and batch files to achieve this. The project structure usually looks similar to:
- build: everything needed to build a project
- libs: any external or internal library (often redundant if nugget is used)
- src: source code goes here.
I have already mentioned automatic deployments in the continuous integration and command line build sections. Being able to deploy the software automatically in any of the environments will generally save you a big amount of time (proven!). Deployment is one of those repetitive things that is error prone and time consuming, so why not automate it whenever possible.
You might use a simply copy commands to achieve this, or WebDeploy if you use IIS.
Tests and Coverage
Code without tests looks “naked” and therefore a good set of tests is not an option. While I am a supporter of Test Driven Development (TDD) often is not possible to follow fully the methodology and to be “pragmatic” toward certain decisions. In order to save time and to have a good behavioral tests, I like to have (at least) “good” integration tests that have a high code coverage. A program with high code coverage has a lower chance of containing bug than a program with low code coverage, however there is a catch: Code Coverage and tests are two different things! Code coverage tells which code has been touched by the test suite, but is the test that should be written in a way to carefully test a given feature. A good thing to do is to agree with other team members on a certain level of code coverage that would suite the project needs!
I find that Dependency injection is one of those basic techniques that is a must to know to every developer. Dependency Injection enables writing maintainable, testable and cohesive code. DI will repay you back through the project lifetime, especially as the project evolves and becomes more complex. There are many frameworks that enable you to write DI: Autofac, Ninject , Spring.NET, StructureMap, Unity or others.
I hope that we share the same set of processes, and for sure there are many other things we do on a daily basis. Do you have your own set of processes that you follow? Please suggest it here!