HOME | Blog | YouTube | LinkedIn | About Me         || Calculators    | SoftEng/Tech Posts    | Code/Scripts

Thursday, October 22, 2015

Checking in your code? When? Stubbing out?

Number 1 thing I tell fellow developers on my projects is:
Pretend that after you check in your code (even though it is isolated in your project branch) that I will take your code and put it in production right away.
Then ask yourself if that code will break existing behaviour of your existing sites/applications. If the answer is "Yes", then you should not have checked in that code in the form it was in.
Addressing all the issues as you are coding instead of dealing with them during merging your branch back into main trunk is the right thing to do.
Basically the question is:  Pay me now or pay me later?
I'd rather pay with the right mindset before you even write a line code. Obviously the mindset is not good enough; you need unit-testing and integration testing to make sure it truly does not break existing functionality (smile) . Some of us have been calling this "stubbing out your code" and more recent buzz word would be "feature toggle".
What are some typical examples? 
Let's take the most simple example. You are writing a brand new method that nobody is going to use yet and you want to check in your code because it is in good shape. Basically this code is stubbed out by default; you can't break any existing functionality. 
Let's consider another example. Let's say you are asked to introduce a new feature called "RankCustomer" on ONLY one of your sites called Site A. You implemented all the functionality and you also prepared the code that invokes this RankCustomer module in your order processing methods that are shared by multiple sites. Let's say you check in the code in this shape. What would happen? If I pushed this code to Production environment, all the sites would attempt to call RankCustomer module and it would break right away and cause a Severity 1 issue. Let's say RankCustomer module needed some certificates/keys installed and if I push the code without the certificates/key installed, it would break production. So how would you check in this code properly? You would introduce a flag in your code for this feature. If this flag is NULL (not existent in config file) or explicitly set to FALSE, the RankCustomer module would never be called. This means that if you literally take that compiled code to production WITHOUT even pushing any config files or installing any certificates, it will never be invoked in production. That's how stubbing out works. 
This mindset is something that needs to be preached during any project; that's how issues are prevented and over time this just becomes natural when you work with your teammates longer. You just take care of each other.

Almir

#coding #programming #code #programmer #softwareengineering #softwaredevelopment #featuretoggle #continuousIntegration 


No comments:

Post a Comment