No one sets out to create crufty code, but too often the pressure to "push it out the door and we'll fix it later" gets the best of us all. Before you know it, it's three projects later, the sun is still shining and you're still getting a paycheck. So where is the incentive to go back and clean under the rug?
Poor core quality isn't just a developer problem, either. It bleeds into team moral, deters decision agility, and ultimately prevents team members from getting into flow.
Quality code isn't something that requires a complete rewrite either (which is likely impossible), but can be accomplished with style guides, code reviews and a devotion to team investment time.
The pressure to ship will always be there, but starting (or maintaining) projects with an agreed upon foundation alleviates developers and designers from making potentially hundreds of decisions each day. This leaves room for the decisions that actually matter.
Learn how to transform your team, regardless of your position, into a lean, mean standards machine. Develop a multi-tier style guide, workflow and practices that focus on knowledge and consensus building. Eliminate the mundane decisions and allow the team to focus on its craft.
2. @nickdenardis #psuweb
Nick DeNardis
Minimalist. UX crafter. Speaker. Realist.
Computer scientist. Library scientist.
Wayne State University
Director of Digital Communications
TEDxDetroit, HighEdWeb MI,
Laravel Detroit & Refresh Detroit
Organizer
Amateur hardwood floor refinisher
5. @nickdenardis #psuweb
Simple
☐ Creating software is hard
☐ Lots of unknowns
☐ Client changes over time
☐ Changing technology
☐ Growing expectations
☐ Time constraints
☐ Money constraints
☐ Turnover/student workers
☐ Team moral
☐ Development environment
☐ Training
6. Developer
A developer executes. Their
talents often focused to a single
area. Without need for the “big
picture”.
Engineer
An engineer designs and plans.
Always aware of the “big
picture”. With talents in many
areas. An engineer can assume
the developer role. But an
engineer’s core focus lies with
architecture.
16. @nickdenardis #psuweb
Code reading 101
Pick a function/library/file < 50 lines of code. Set aside 2-3 minutes per line
Try to build and run it.
Don't focus on the details early.
Make sure you understand all the constructs.
Now that you've got a good idea about most of the constructs, it is time to
do a couple of random deep-dives.
There were undoubtedly things in the previous step you were confused
about, so this is the perfect time to go and read some tests.
No tests you say, sounds like the perfect time to write some.
21. @nickdenardis #psuweb
What to review in a PR?
• Everyone brings something to the table
• Single responsibility principle
• Naming
• Tests should cover QA, it’s not a reviewer’s
responsibility
• “Leave a place better than you found it” ~ Girl Scouts
22. @nickdenardis #psuweb
Authoring a pull request
• Small atomic changes
• Should take at least 10 minutes
• Provide two paragraphs of context
• Only link to `Fixes #1337` as a command
23.
24.
25. @nickdenardis #psuweb
Reviewing a pull request
• Ask, don’t tell
• Negativity bias in written communication
• Foster a technical discussion
• Never use the word “just”
• Be positive
28. @nickdenardis #psuweb
SOLID Principles
Single Responsibility
a class should have only a single responsibility
Open/closed principle
should be open for extension, but closed for modification
Liskov substitution principle
objects in a program should be replaceable with instances of their subtypes
Interface segregation principle
many client-specific interfaces are better than one general-purpose interface.
Dependency inversion principle
Depend upon Abstractions. Do not depend upon concretions.
32. @nickdenardis #psuweb
Sandi Metz
• Your class can be no longer than 100 lines of code.
• Your methods can be no longer than five lines of code.
• You can pass no more than four parameters and you
can’t just make it one big hash.
• When a call comes into your (Rails) controller, you can
only instantiate one object to do whatever it is that
needs to be done. And your view can only know about
one instance variable.
33. @nickdenardis #psuweb
Resources
• Sandi Metz - Refactoring
https://www.youtube.com/watch?v=8bZh5LMaSmE
• Eye tracking original
https://www.youtube.com/watch?v=VtuO9un2Vyg
• Eye tracking refactor
https://www.youtube.com/watch?v=Jc8M9-LoEuo
• How big should a function be?
http://cleancoders.com/episode/clean-code-episode-3/show
• Rules for good software development - http://gist.io/4567190
38. @nickdenardis #psuweb
PSR-2 Standards Highlights
• Code MUST use 4 spaces for indenting, not tabs.
• Opening braces for classes MUST go on the next line, and
closing braces MUST go on the next line after the body.
• Opening braces for methods MUST go on the next line,
and closing braces MUST go on the next line after the
body.
• Opening parentheses for control structures MUST NOT
have a space after them, and closing parentheses for
control structures MUST NOT have a space before.
67. @nickdenardis #psuweb
Kaizen
• Good processes bring good results
• Go see for yourself to grasp the current situation
• Speak with data, manage by facts
• Take action to contain and correct root causes of
problems
• Work as a team
• Kaizen is everybody’s business