Usha: Hi.
It's wonderful to be here with you guys today.
I'm Usha, I'm a software developer at Neuro-ID.
Neuro-ID delivers real-time behavioural prior to Neuro-ID I was a software developer at
Salesforce.
My experience developing on large-scale at Salesforce, I'm going to talk to you about
how you can build clean code at your organization.
Let me start by asking some questions around clean code.
What is clean code?
Clean code is code that is easy to understand and easy to change.
It's a set of principles introduced by Robert Martin in his book, Clean Code.
How many of you have heard of clean code?
Awesome.
So why do we need clean code?
Clean code -- most organizations today use product management, that means the product
is continuously evolving.
To support this, the goal on which the product is built on needs to change easily.
In other words, it needs to be clean code.
If you are at all familiar with this kind of programming, then you guys need clean code.
So having naming conventions and formatting rules is a big part of clean code, but it's
not just that.
You can have standards around how your code is implemented.
You can implement clean classes with solid principles.
You can cleanly use third-party software services so that they're easy to upgrade and easy to
migrate away from when the time comes.
You can have effective error handling that is specific to your application and is consistent.
And there's much, much more that you can do.
So if you think all this is great, how do you introduce these practices?
Do you buy all the developers in your team a book and call it a day?
That's a great start, but I don't think that's the entire solution.
To introduce clean code, you need to build a clean code culture in your organization.
You need to set in motion a continuous learning cycle for clean code.
The continuous cycle has four parts to it.
First, you need to take small learning steps.
Then document them.
And force these steps that you've taken and you need to select a new champion.
Let's take a look at all these steps up close.
The biggest hurdle for any team to adopt clean code is the constant time crunch that we are
under.
So you need to make sure that the learning happens in small incremental steps.
Let's take a look at how you come up with these small steps.
First, start by being the clean code champion.
Clean code champion is responsible for the learning cycle until the new champion is chosen.
Then making things easy for others is extremely hard.
It takes a lot of time.
Spend time with your codebase, try to understand and find patterns in the code that deviate
from clean code principles.
Make a list, identify four easy wins that you can implement.
These can be as simple as: Changing the way comments are made.
Fix how the method names, or just introduce single responsibility principle.
Now, once in my team when we wanted to introduce clean test practices, the first easy win was
to make sure every test had only single reason to fail.
And once we had that, once developers got used to t we slowly built upon it.
Next, set up a periodic clean code learning meeting.
This is the stage where your entire team sits together and learns the easy wins that you've
chosen.
Make sure that the learning meeting is at least months -- at least a month apart, so
that it doesn't eat into the development time.
Nobody needs more meetings and delivering the product is our main priority.
Make sure the meetings are set at least a month apart.
I want to throw a word of caution here for teams working on large codebases.
Don't be disheartened that your existing code does not follow these principles.
You have to make a start somewhere.
Make sure that all the new code that you're adding follows these principles.
Now that you have your easy wins, let's look at documentation.
When I say documentation, most of you are rolling your eyes, because documentation has
a problem.
Nobody reads it.
But documentation has its merits.
[laughter] Let's see how we can make documentation interesting.
Make sure that your documentation is skimmable.
Because when a reader lands on a documentation page, they're looking for specific information.
Make it easy for them to find it.
Next, like Neha said, add DRD blocks to your documentation.
When a developer jumps in, they don't want to know all the details.
They just want to know what the principle of the code that you're trying to talk about
is and find out quickly.
* Next, document with practical examples.
If you're documenting a single principle, do not use parking lot, please.
Use something that exists in your application architecture.
Again, there are a lot of tools in the market that help you with clean code.
Leverage them.
If you want to introduce formatting rules, don't write them in a documentation, put them
in a configuration so that developers can apply them in their IDEs.
Take a page out of Google's handbook.
In 2006, Google wanted to introduce best practices for unit testing.
They made pamphlets out of those best practices and put them in their bathroom stalls.
They called this, testing on the toilet.
Skimmable documentation with unabashed advertising is the best way to run any successful campaign.
Education needs reinforcement.
Let me say that again: Education needs reinforcement.
[laughter] The best way to enforce any rule is by following
it.
Lead by example.
Make gatekeepers part of the code review process to make sure that all the agreed-upon clean
code principles are being followed by the code being submitted.
Encourage healthy discussion about different approaches.
Make sure that you choose the best approach based on its merit and if you cannot decide
which is the best approach, the easiest one to win -- sorry, easiest one to implement
always wins.
Again, leverage tools like sonar Qube to remove the human conflict from enforcing.
The last part of the learning cycle is crowning a new champion.
By bringing in clean code, you're trying to introduce a change in behavior.
But nobody likes change.
By making different team members responsible for clean code, you're empowering them to
effect change.
This also benefits your cause by bringing in more diverse perspective.
Crowning a new champion happens in the periodic clean code learning meetings that we've set
up.
During these meetings, make sure that you review the existing rules that you have in
place.
See what worked, what did not work.
Recalibrate your strategy.
Now, it's time to present your easy wins.
Make sure team understands the easy wins, using the documentation that you have made.
Make sure it's -- it makes sense.
And talk about how you're going to enforce these rules.
Next, choose a new clean code champion who will be responsible for the next leg of the
learning cycle.
With this, you have successfully set in motion a continuous learning cycle for clean code.
This will help you build a culture of clean code.
In conclusion, when it comes to best practices like clean code, following test pyramid or
best logging practices, culture-building and education go a long way.
Thank you.
[applause]