Explain how the Five Second Rule for code review works. | |
The five second rule is the concept that if you can't understand the intent of a line of code or method in 5 seconds | |
then it is likely that item is too complex, and needs to be broken down into more easily understandable components. | |
Knows why comments lie, and how to write self-documenting code | |
The phrase "comments lie" refers to the fact that because comments are not a part of the working application, | |
they are never tested, reviewed, or used in production. Because of this, as bugs are found, or enhancements | |
are made, the functionality is verified, but the comments are never validated in any consistent way. Thus, |
When visual design changes are made - it's exceedingly difficut to validate design changes automatically, especially when they don't impact the functionality.
Usability - if usability is important (it always is), an automated test won't tell you if you've made some changes that hurt it (like creating a div that hides buttons or links - the machine tests are not going to realize this)
Feature: shopper shops | |
As a shopper | |
I want to a decent shopping experience | |
So I can buy a ton of stuff easily | |
Scenario: add to cart | |
Given I am on a PDP | |
When I click Add To Cart | |
Then I should see this product in the minicart |
Writing the code you want to see is all about making your code focused on the application's functionality, not on how you want to build it. Many times as developers we want to get right to writing the code, because we have some idea of how the application can be built. If we instead start by documenting what the application should do - via tests - we will write code that is focused on the functionality. Our code design will more closely model the functionality, instead of how we thought it should be built before we started considering what it would actually do from a user's perspective.
Explain how "convention over configuration" allows us to be more productive as a group.
Convention over configuration gets all the basics out of the way. All the tiny decisions like "how should I organize my project file structure" that could involve a lot of thinking (how do I future proof this?) are already made - by convention. We learn the same, single convention, and then we all follow it. This means when we switch projects, or start new, we don't spend a lot of time figuring out basic context - we can get right to the heart of the functionality we are working with. Another higher level example is akin to the shopping cart platform. Assume we are building a transactional ecommerce website. If we start with an off the shelf product that has a home page, PDP, cart, checkout - the basic stuff is already done for us. There's no reason for us to rethink this very straightforward thing that thousands of people have already built. This lets us move right to the interesting parts - customizing it for our busine
for run in {1..6}; do shuf -i 1-6 -n 5 -r|perl -ne 'chomp;print' | xargs -I pattern grep pattern diceware.wordlist.asc; done |