Instant feedback for programmers
As an architect, its not just enough if I look at the code architecture of a project, I have to architect the scaffolding too for creating a good programming environment. Take for instance a building site, even before building a structure you must have the site made. Water facility, toilets, and temporary shelters for the workers must be there, the site must be marked where to excavate, where a foundation must be laid and so on. It quite similar in software project.
One good thing about construction is its visual, w can see if a brick is laid right or its jutting out visually. even slightest deviation of a straight wall construction can be found out with a plumb line, a truly a miracle invention indeed! With code some errors might be there which are not visually identifiable. It may be easy to look or inspect a building, but to inspect code is not so intuitive.
So part of a building a great scaffolding for code is to set up reporting tools that report you visually about code quality and other things. This is how we had done code mostly:
As a developer we would have pushed code to source code repository, this would have been staged and tested by tester and it would have been deployed to production if things are okay. There wasn’t much emphasis given to code quality and other things.
Maintaining code quality, and checking that the code this release did not break the code of last one was hard, and it was avoided and ignored until it was really necessary. Or we took the convenience of saying to us that we will do it in free time and that had never happened.
Thankfully we now have tools to run our tests, so we can automate tests, see how our code adheres to programming best practices (code smells), we can see how much of our code is tested. So this is how our new way of coding should be:
when the developer pushes the code, these tools that do Testing, Code Smell Estimation and Test Coverage must pull the code and must do their job. Their output should be instantly available to the programmer as a very visual report, if all reports are okay, then we must go on for staging deploy.
Once staging deploy is done it is the job of manual tester to test it, if the manual tester is okay, then we must goto production deploy. In the production deploy we must gather as much performance metic as possible and the programmer an tweak his or her code to improve.
If all these are followed religiously then we have a good chance of creating a better software.