Whistle Blowers
Vinod Kumaar RamakrishnanLightning Talk: 10 minutes
Summary
Most of the bad parts while coding goes in inadvertently during the rush hour of check-ins. I usually observe the rush hour to be close to the end of the day and the next day, the refactoring is put into back burner which grows into tech debts and makes you repay at a later stage. Along with the other devs in the team we set some simple rules in the CI to fail the build. The rules are
- More than 12 lines in a method
- NPath complexity more than 4 in a method
- More than 4 lines of code copy pasted across any file
An intentional check in to avoid these rules and send in a bad code could not be prevented; but someone in a hurry or tired individual checking in gets a hint that code could be bad. A quick introspection will lead to corrective action and things could be addressed then and there instead of carrying a tech debt. The rules above are neither comprehensive nor does this guarantee awesome code, but it has caught me and others red handed when looking for quick gains. I will list some examples of refactored code to show how simple metrics helped to keep code readable.
Short Bio
Vinod Kumaar Ramakrishnan works as an agile coach, trainer, developer with ThoughtWorks Bangalore. His primary area of interest is workplace efficiency and maintains a blog at https://vinodkumaar.wordpress.com/ which mostly reflects this. He was able to play almost all the roles outside of a typical programmer which has provided insights into every role that is involved in software development.
