Upload
mike-subelsky
View
4.219
Download
0
Embed Size (px)
Citation preview
All bugs are ultimately process failuresOur systems should reject bad changes
and enforce quality automatically
Have more meetings• Make decisions
• Hash things out
• Explain your plan
• Brainstorm
• Write pseudocode
• Make diagrams
• Sharpen understanding
I, Mike Subelsky, heartily endorse meetings
IIF they entail decision-making, brainstorming, mentoring, conflict, fun, excitement
Set smaller goals you can actually achieve
We need more milestones, hard deadlines, “forcing functions”
Goal
• Strategic objective that helps STAQ grow
• Increases revenue or reduces costs, or both
• Expressed as a single sentence, completely in business terms, associated with a deadline
• “Charge customers for use of custom connections by 12/01/2015”
Epics• Major, high-level initiative to help achieve a Goal
• Complex effort encompassing changes to multiple codebases
• Expressed in business terms, in terms of user capabilities, with a deadline
• “Users can view, create, update, and delete custom connections on their own by 11/15/2015”
• Constantly reprioritized as the project deadline approaches
Push back• AMs/TAMs should always push us to deliver our best,
advocating for customer
• We should push back when real constraints exist
• Helps everyone be more creative
• Helps clarify priorities
• 80% / incremental solutions often good enough
• Resist the urge to dive in and save the day
Refactoring & maintenance cycles
• Count on about a week of fixing and polishing major features post-release
• After an epic or major project finishes, we do this anyway; let’s plan for it
• Good time to handle chores, smaller feature tickets & bug fixes
- https://en.wikipedia.org/wiki/Single_responsibility_principle
“…every class should have responsibility over a single part of the functionality provided by the
software.”
- https://en.wikipedia.org/wiki/Single_responsibility_principle
Responsibility is “…a reason to change…a class or module should have one, and only one,
reason to change.”
Use the staging server
• https://staging.staq.com
• https://sites.google.com/a/staq.com/staqnowledged/home/infrastructure/staging-server
Fork the app
• Good for testing database changes
• Need someone to try & document this
• https://devcenter.heroku.com/articles/fork-app
• May need to fork multiple apps in concert
• Heroku addon attachment feature pretty cool
Lint Ruby and JS Code
• Rubocop
• ruby -c after every save
• Let’s make this a git pre-commit hook
• brew install jsl
Keep writing tests• Unit tests: 100% coverage
• Usually no need to test explicit string contents
• Integration test: all major subsystems
• Including failure modes
• Acceptance test: most features, important failure modes
• Smoke test: engines/gems integrated into apps
Keep Classes Small
• “One screenful or less”
• Not counting documentation
• Almost no private methods
• There’s always a better way, look for a hidden object
You are only done when…• Documentation written (YARD tags + wiki)
• Unit tests written to 100% coverage
• Integration tests covering important subsystem interactions
• Acceptance tests covering important features and failure modes
• Code reviewed by a peer