Product Excellence
Best Practices
Update: 10/2018
@greenido
GreenIdo
Goal
Create a baseline that developers could follow and be in
a quality level with regards to product excellence:
1. Testing
2. Code reviews
3. Static analysis
4. Health: availability, resilience, etc’.
Product Excellence
Product Excellence is
a culture, not a checklist
Tests
1. It’s FAST – The tests should run fast in order to encourage developers to
use them constantly during the development process.
2. Stable – The test doesn’t break often. You wish to minimize the
false-positive ratio as much as you can. This is why you need ‘small’ tests
that are encapsulated and give you a clear sign on what is working (or not).
3. Easy to read, maintain, run and understand.
4. Catches Bugs! When a test fails it’s most probably a bug.
5. Does not impact customers.
6. Automated.
Code Reviews
...and the best part?
We don’t have a style guide.
(You might want to have one for your team)
Code Reviews - Benefits
● Accidental errors (e.g., typos) as well as structural errors (e.g., dead code, logic or
algorithm bugs, performance or architecture concerns) are often much easier to spot
for critical reviewers.
● Legible code is more reusable, bug-free, and future-proof.
● Committers are motivated by the notion of a viewer who will look over the change
request: the committer tends to clean up loose ends, consolidate TODOs, and
improve the commit.
● Sharing knowledge: Reviewers may possess knowledge about programming
techniques or the code base that can help improve or consolidate the change.
● Consistency in a code base makes code easier to read and understand.
Static Analysis
Why?
1. Helps identify potential software
issues during development.
2. Helps to detect code that needs:
simplification, readability,
testability etc’.
3. It also improves communication in
the development team and helps to
produce high quality code.
How?
1. SAAS option like Sonarsource
2. SpotBugs – part of your build/dev
process.
3. Many other options to use linting
extensions/plug-in so you will catch
many issues during development
time.
(!) Low Effort → High ROI
How?
If you want to build a ship,
don't drum up the people
to gather wood, divide the
work, and give orders.
Instead, teach them to yearn
for the vast and endless sea.
Freedom and
Responsibility
Highly Aligned, Loosely
Coupled
In our case, it’s a
spaceship.
What is the level
of quality you will
tolerate?
How?1. Have a good coverage of your code.
a. ~70% with unit tests which are ‘small’ tests that run fast
and encapsulated
b. 20% for integration tests
c. 10% for UI (or end-to-end) tests.
2. ROI - A good coverage to effort ratio.
3. Make sure you have:
a. Unit tests
b. Integration tests
c. Functional tests / End-to-end tests
d. Performance test
4. It’s all automated and part of your build process.
5. You can also divide the world of ‘test type’ to S/M/L.
How?
1. When you have an issue with production → You creating a test to cover it in the
future.
2. Learn from your (and others!) history.
3. Build a process of debriefing after each time something happened (or almost
happened) and create a test that covers this case for the future.
4. You can test in production but think carefully if it’s the right thing to do for your
specific case.
Can you use Mocks, Stubs?
High standards are contagious
Bring a new person onto a high
standards team, and they’ll quickly
adapt.
The opposite is also true.
Thank you!
@greenido
GreenIdo

Product Excellence Best Practices

  • 1.
  • 2.
    Goal Create a baselinethat developers could follow and be in a quality level with regards to product excellence: 1. Testing 2. Code reviews 3. Static analysis 4. Health: availability, resilience, etc’.
  • 3.
    Product Excellence Product Excellenceis a culture, not a checklist
  • 4.
    Tests 1. It’s FAST– The tests should run fast in order to encourage developers to use them constantly during the development process. 2. Stable – The test doesn’t break often. You wish to minimize the false-positive ratio as much as you can. This is why you need ‘small’ tests that are encapsulated and give you a clear sign on what is working (or not). 3. Easy to read, maintain, run and understand. 4. Catches Bugs! When a test fails it’s most probably a bug. 5. Does not impact customers. 6. Automated.
  • 5.
    Code Reviews ...and thebest part? We don’t have a style guide. (You might want to have one for your team)
  • 6.
    Code Reviews -Benefits ● Accidental errors (e.g., typos) as well as structural errors (e.g., dead code, logic or algorithm bugs, performance or architecture concerns) are often much easier to spot for critical reviewers. ● Legible code is more reusable, bug-free, and future-proof. ● Committers are motivated by the notion of a viewer who will look over the change request: the committer tends to clean up loose ends, consolidate TODOs, and improve the commit. ● Sharing knowledge: Reviewers may possess knowledge about programming techniques or the code base that can help improve or consolidate the change. ● Consistency in a code base makes code easier to read and understand.
  • 7.
    Static Analysis Why? 1. Helpsidentify potential software issues during development. 2. Helps to detect code that needs: simplification, readability, testability etc’. 3. It also improves communication in the development team and helps to produce high quality code. How? 1. SAAS option like Sonarsource 2. SpotBugs – part of your build/dev process. 3. Many other options to use linting extensions/plug-in so you will catch many issues during development time. (!) Low Effort → High ROI
  • 8.
    How? If you wantto build a ship, don't drum up the people to gather wood, divide the work, and give orders. Instead, teach them to yearn for the vast and endless sea. Freedom and Responsibility Highly Aligned, Loosely Coupled In our case, it’s a spaceship. What is the level of quality you will tolerate?
  • 9.
    How?1. Have agood coverage of your code. a. ~70% with unit tests which are ‘small’ tests that run fast and encapsulated b. 20% for integration tests c. 10% for UI (or end-to-end) tests. 2. ROI - A good coverage to effort ratio. 3. Make sure you have: a. Unit tests b. Integration tests c. Functional tests / End-to-end tests d. Performance test 4. It’s all automated and part of your build process. 5. You can also divide the world of ‘test type’ to S/M/L.
  • 10.
    How? 1. When youhave an issue with production → You creating a test to cover it in the future. 2. Learn from your (and others!) history. 3. Build a process of debriefing after each time something happened (or almost happened) and create a test that covers this case for the future. 4. You can test in production but think carefully if it’s the right thing to do for your specific case. Can you use Mocks, Stubs?
  • 11.
    High standards arecontagious Bring a new person onto a high standards team, and they’ll quickly adapt. The opposite is also true.
  • 12.