Bulletproof Components (Part 3): General Checklist

Index

This checklist is applicable to both front end and back end development. These items are applicable to software development and project management in general. However, they are specifically tailored for Sitecore projects.

• Are you missing any null checks?
• Do you have any unused:
  • Using statements?
  • Variables?
  • Properties?
  • Methods?
  • Less code means fewer points of failure. Be careful when removing code, however. Even if your IDE is telling you that something isn't being used, it's possible that it is being used in a way that's undetectable to the editor, such as if a Sitecore item references it.
• Do any areas of your code require future work?
  • Consider marking them with comments in this format: TODO: Initials - Notes.
  • IDEs have built in support for managing these types of comments.
  • Remember to add a card for it or to mention it to your project manager.
• Does your code have any existing TODO items that require your attention?
• Do your file names conform with the existing standards and requirements? (CamelCase, dashes, etc).
• Did you check all of your loop statements for edge cases?
  • Less than 0, 0,1, more than one, even, odd, etc.

Poor code readability is common in Sitecore projects. Unreadable code is a liability. We all know we should write readable code, but few of us actually do. Readable code reduces the mental effort required for other developers (or future you) to work on the code, so let's get passionate about writing readable code!

• Remember that good code reads like English.
• If you have any logic whose purpose isn't immediately clear, why not make a named variable out of it?
• Do you have any boolean variables that can be named more descriptively?
  • Start your boolean variable names with modal verbs such as "is", "was", "should", or "can".
  • Ex. isVideo instead of video.
• Do you have any if else statements?
  • Nested loops?
  • Nested ifs?
  • Can they be flattened?
  • Can you add guard checks or invert the logic to avoid logic nesting?
• Is your code neatly and consistently indented?
• Does your code have unnecessary white space?
• Does your code have unhelpful comments?
  • Can the comments be removed in favor of more descriptive and readable code?
• Can you use a linter or automated code review tool to enforce some of these standards?

• Do you have any cases where elements will be excluded / hidden due to fields not having values?

  • Have you tested all variations of optionality?
  • Do the absence of optional elements break your design?

• Have you handled the case of long content being added?

  • Short content?

• Have all of the component style variations been tested?

• Did you test your component in all of your supported browsers?

  • Is your component fully responsive on all supported browsers?

• Did you test the component on a real mobile device?

• Did you verify that the final product of your component is valid HTML?

• Does your component need to be WCAG compliant?

• Have all your changes / files / items been added to source control?
  • Oftentimes we forget to "Save All".
  • We also forget to serialize our items.
• Are you keeping your commits small?
• Are your commit messages adequately descriptive?
  • It's not just the what… It's the "why"!
• Are you carefully reviewing each commit to ensure you're not making any unintended changes?
• Did you make a change that affects another individual / team?
  • If so, let them know!

• Does your component meet all of the definition of done requirements?

• Does the final product match the design?

• Have you made it easy for other developers to pull and run your code?

  • Ideally, your items should be deployed automatically via your item serialization tool of choice so the installation does not need to be done manually.
  • The more you can automate the item deployment process the better. When considering how your items will be deployed, imagine someone else has to rebuild an entire environment using your source code.

• Have you ensured that all of your items will be deployed before testing begins?

• Were any changes made to your component by another team that needs to be incorporated into the work you have done?

• Did you provide a link to where your new functionality can be reviewed?

• Did you update the sprint / kanban board and notify the appropriate individuals?

• Do the QAs and content authors understand:

  • How can it be tested / used?
  • Where can it be tested / used?

• Did you provide an instructional video or demo of the functionality? Screen recording videos are great because they can be referred to at any time.

  • There are many free screen recording tools that allow you to easily create and share videos on the cloud with no post processing required.

• Has the testing team been made aware of any changes that could result in regressions?

"Hours of QA churn, troubleshooting, and context switching will certainly save me minutes of due diligence."

An ounce of prevention is worth a pound of cure. These checklists will add some overhead to your processes, but hopefully by now you can see the value.

Advanced developers will not rely on the QA process to ensure the quality of their components. Even before a component is pushed to QA, a developer should understand:

• The assumptions of their component
• The limitations of their component
• The issues and bugs affecting their component

The seasoned developer would also preemptively communicate those points to the relevant parties prior to handing the component off.

QA time is precious. It should be a time to identify real issues… Not the minor items that the developer should have remembered (or better yet, automated) in the first place. To consistently take care of the common issues is to free up QA resources. This makes you look good and it allows QAs to focus on finding real bugs.

Bulletproof components build trust at every level of the development and delivery process.

Thanks for reading.

-MG