Upgrade to Pro — share decks privately, control downloads, hide ads and more …

What is quality code? From cruft to craft

What is quality code? From cruft to craft

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.

Nick DeNardis

June 22, 2015
Tweet

More Decks by Nick DeNardis

Other Decks in Education

Transcript

  1. @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
  2. @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
  3. 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.
  4. @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.
  5. @nickdenardis #psuweb Resources • http://devchat.tv/ruby-rogues/031-rr-code-reading • http://www.codenewbie.org/podcast/ep-2-coding-like-a-boss-w-brian-douglas • Reading code

    talk - https://www.youtube.com/watch?v=mW_xKGUKLpk • http://bloggytoons.com/code-club • http://www.slideshare.net/saronyitbarek/reading-code-good • http://www.codewars.com/ • http://www.skorks.com/2010/05/why-i-love-reading-other-peoples-code-and- you-should-too/ • http://www.readingcodegood.com/
  6. @nickdenardis #psuweb Code Review 1. Knowledge transfer 2. Increased team

    awareness 3. Finding alternative solutions to problems
  7. @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
  8. @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
  9. @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
  10. @nickdenardis #psuweb Resources • http://research.microsoft.com/pubs/180283/ICSE %202013-codereview.pdf • http://blog.codeclimate.com/blog/2013/10/09/ unexpected-outcomes-of-code-reviews/ •

    Does it need a +1? 
 http://harvesthq.github.io/fias/ • Harvest code reviews
 https://techtime.getharvest.com/blog/code-reviews-at- harvest
  11. @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.
  12. @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.
  13. @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
  14. @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.
  15. @nickdenardis #psuweb Resources • http://www.php-fig.org/psr/psr-2/ • https://en.wiktionary.org/wiki/bikeshedding • http://www.nngroup.com/articles/the-power-of-defaults/ •

    http://blog.codinghorror.com/the-power-of-defaults/ • https://github.com/waynestate/web-guides • https://github.com/bbatsov/ruby-style-guide • https://www.drupal.org/coding-standards • http://isobar-idev.github.io/code-standards/
  16. @nickdenardis #psuweb Editorconfig # http://editorconfig.org root = true [*] indent_style

    = space indent_size = 4 end_of_line = lf charset = utf-8 trim_trailing_whitespace = true insert_final_newline = true [*.md] trim_trailing_whitespace = false [makefile] indent_style = tab
  17. # pre-commit.sh git stash -q --keep-index ./run_tests.sh RESULT=$? git stash

    pop -q [ $RESULT -ne 0 ] && exit 1 exit 0 ln -s ../../pre-commit.sh .git/hooks/pre-commit Symlink in your hooks Stash before running
  18. @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