Another project and lots of new learning

The project I am working on currently has reached its final stages and this time i decided to write down the major learning’s and shortcomings i could improve on next time.

1. Git work flows: This time around we stopped following the highly inefficient every_one_push_to_master( thats not a work flow at all :P) approach to a pull request work flow. Every developer forks his own version of the code and maintains his code on his own repo, giving a pull request whenever a feature is complete. Also a central repository to which the pull requests where given had two branch, Development and master. Development is where the development build code resided and master with the production code. The advantage of following a Pull request work flow is

– It reduces the chances of rubbish code being pushed into build branch as  the developer will have a look at the code changes before every request

– Also with one guy having permission to merge the pull requests( our case it was the team lead) there is a possibility of  code review on the fly.

Future scopes: Proper usage of tags in build versions.
2. Unit Tests:

Unit test must be one of the most underrated practise in software development. Trying to explain to a “Non Believer” that Unit tests are a must is almost impossible, “Its rubbish” was the thoughts i had before actually trying out unit tests for my code. The advantage of catching a error in code in one part due to change somewhere is probably the best advantage. Also Tests give you confidence on the code you have written and also the entire project. Now you can hear me saying “yea the module is done and unit tested and iam sure it will work”
Future scopes: Try to write Test driven code rather than code first and test later

Documenting code and API’s is probably the hardest job ever. It a sucky job but the fact is that some has to do. We did it in a worst way possible, we used Google sites for our docs 😛 and ended up with a blob of unmaintainable crap. As of now we are in a process of brainstorming some elegant solution for this, probably something using Jekyll so the documentation will remain part of  the code.

Re-factoring is a lie, you will either have no time to do it or the code will be running a critical feature that changing that code will be dangerous. Working on a project for around 3 months, i re-factored only one class, which i did putting in extra time at work.

Moral: the only way to re-factor your code is to write good code in the first place.
5.Murphys Law

Things will go wrong and it will go horribly wrong,  the important thing is to foresee it early and be prepared for it.