- [Instructor] We've been discussing theory and practice
of testing and code quality.
How does that apply to what you're working on?
Let's admit the truth to ourselves.
There's no such thing as a perfect codebase.
It's okay to say that
because software that we're working on is always changing.
Improvement is always an option,
and I'd like to give you some ways to make it happen.
When improving an existing codebase,
start off by setting achievable and reasonable goals.
Documenting every single function
and updating every package in an afternoon,
not going to happen.
Part of the goals should include metrics.
An example goal is 70% code coverage
on a particular component.
So the project doesn't drag on forever,
have a timeline that you can work towards.
It can be as easy as "by Friday" or a multi-step process.
Do some research into how you'd like to improve
based on your needs.
This might include tooling or different approaches.
Finally, write a plan.
It doesn't have to be long.
It should state what you want to do and how.
It'll be good to refer to as you go along.
Here's some things to try.
Consider focusing on choices that improve code quality.
The less arbitrary, the better.
It's good to get team buy-in,
which means involvement and transparency.
That includes collaborating on coding standards,
including voting if that helps.
Sometimes, you won't get everything that you want,
but it's better to make a decision
that's good for the group's needs.
Write brief but accurate documentation
because reading a novel is hard.
Finally, be open to trying alternative approaches.
There's always more than one way to do something.
Here's some things to avoid
when attempting to improve code quality.
First of all, avoid trying to do too much at once
because it's disruptive, messy, and annoying.
The expression, "Rome wasn't built in a day" comes to mind.
Don't fixate on making tools happy
because they're arbitrary measurements.
Avoid being pedantic, meaning too concerned
with literal accuracy and formality.
I know that particular point is ironic
coming from a course like this, but do try.
Do not demand compliance to a set of rules
and instead find ways to work together.
If people don't want to work together,
no code quality guidelines are going to to help.
Finally, avoid the not invented here attitude.
You won't learn anything by staying in an insular bubble.
Are you starting a new project from scratch?
Establish positive code quality guidelines from the start.
That can include a README that describes expectations.
Figure out what your preferred tool set is and document it.
When starting a project,
only include the utilities you need.
It's always easy to add a module
and it's hard to remove one.
This means avoiding excessive boilerplates
that try to solve every problem.
Boilerplates can be good, but they're not a panacea
that cures all ills.
Above all, make it easy for a developer
working on the project to be successful.
To quote Steve Krug, "Don't make me think."
Of course, code quality is a good thing
and something to strive for.
Don't forget to make great software while you're at it.
A perfect codebase that nobody uses
is less important than an imperfect one many people use.
Is there anything else you can do to learn more
about testing and code quality?