Bulletproof Components (Part 3): General Checklist

Cover Image for Bulletproof Components (Part 3): General Checklist

The General Checklist

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.

Code

  • 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.

Code Readability

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?

Local Testing

  • 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?

Source Control

  • 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!

Project Management

  • 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?

Conclusion

"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


More Stories

Cover Image for Add TypeScript Type Checks to RouteData fields

Add TypeScript Type Checks to RouteData fields

> Inspired by error: Conversion of type may be a mistake because neither type sufficiently overlaps with the other.

Cover Image for Script: Boost SIF Certificate Expiry Days

Script: Boost SIF Certificate Expiry Days

> One simple script that definitely won't delete your system32 folder

Cover Image for NextJS: Access has been blocked by CORS policy

NextJS: Access has been blocked by CORS policy

> CORS is almost as much of a nuisance as GDPR popups

Cover Image for Content Editor Search Bar Not Working

Content Editor Search Bar Not Working

> Sometimes it works, sometimes not

Cover Image for Don't Ignore the HttpRequestValidationException

Don't Ignore the HttpRequestValidationException

> Doing so could be... potentially dangerous

Cover Image for Tips for New Sitecore Developers

Tips for New Sitecore Developers

> Because learning Sitecore can be hard

Cover Image for Tips for Applying Cumulative Sitecore XM/XP Patches and Hotfixes

Tips for Applying Cumulative Sitecore XM/XP Patches and Hotfixes

> It's probably time to overhaul your processes

Cover Image for Super Fast Project Builds with Visual Studio Publish

Super Fast Project Builds with Visual Studio Publish

> For when solution builds take too long

Cover Image for Symposium 2022 Reflections

Symposium 2022 Reflections

> Sitecore is making big changes

Cover Image for Azure PaaS Cache Optimization

Azure PaaS Cache Optimization

> App Services benefit greatly from proper configuration

Cover Image for On Sitecore Stack Exchange (SSE)

On Sitecore Stack Exchange (SSE)

> What I've learned, what I see, what I want to see

Cover Image for SPE Script Performance & Troubleshooting

SPE Script Performance & Troubleshooting

> Script never ends or runs too slow? Get in here.

Cover Image for JSS + TypeScript Sitecore Project Tips

JSS + TypeScript Sitecore Project Tips

> New tech, new challenges

Cover Image for Tips for Forms Implementations

Tips for Forms Implementations

> And other pro tips

Cover Image for JSS: Reducing Bloat in Multilist Field Serialization

JSS: Reducing Bloat in Multilist Field Serialization

> Because: performance, security, and error-avoidance

Cover Image for Year in Review: 2022

Year in Review: 2022

> Full steam ahead

Cover Image for NextJS: Unable to Verify the First Certificate

NextJS: Unable to Verify the First Certificate

> UNABLE_TO_VERIFY_LEAF_SIGNATURE

Cover Image for Sitecore Symposium 2022

Sitecore Symposium 2022

> What I'm Watching 👀

Cover Image for On Mentorship and Community Contributions

On Mentorship and Community Contributions

> Reflections and what I learned as an MVP mentor

Cover Image for Ideas For Docker up.ps1 Scripts

Ideas For Docker up.ps1 Scripts

> Because Docker can be brittle

Cover Image for Early Returns in React Components

Early Returns in React Components

> When and how should you return early in a React component?

Cover Image for How to Run Old Versions of Solr in a Docker Container

How to Run Old Versions of Solr in a Docker Container

> Please don't make me install another version of Solr on my local...

Cover Image for NextJS/JSS Edit Frames Before JSS v21.1.0

NextJS/JSS Edit Frames Before JSS v21.1.0

> It is possible. We have the technology.

Cover Image for Hello World

Hello World

> Welcome to the show

Cover Image for NextJS: Short URL for Viewing Layout Service Response

NextJS: Short URL for Viewing Layout Service Response

> Because the default URL is 2long4me