Front-end developer code review checklist
The checklist provides a list of questions that Pega front-end developers can ask themselves and other developers when reviewing UI changes.
The checklist is not meant to be an exhaustive list of possible questions. Rather, it is a starting point to ensure that everyone is following best practices and taking full advantage of Pega's UI features.
Sections
- Is this section using the minimum number of layouts (for example, remove layouts that wraps section includes, or layouts used only to visually group items)?
- Is this section using the latest Skin formats (for example, no deprecated formats)?
- Are layouts and sections using container headers where possible (instead of using one layout for the header and one for the body)?
- Should this section use a design template?
- If so, should it be editable at runtime?
- Does it need to be marked as a Workarea layout?
- Does the section need to be marked as a Workarea widget?
- Is this section using the latest optimized layouts and button markup?
- If the section contains a Table, can it be replaced with a Repeating Dynamic Layout?
- If not, can it at least use the Table's Optimize for mobile option?
- Can duplicate controls be combined into one control with multiple actions and when conditions?
- If duplicate layouts are using different container formats, can they be combined using a container format property reference?
- Are all guardrail warnings justified?
Harnesses
- If the harness has CSS files attached to it, should they be moved to the Skin level?
- If the harness has JavaScript files attached to it, should they be moved to a script bundle and attached to the portal harness instead?
Design templates
- What are the template's name and region names?
- Does the template's description explain how to use it?
- Does the template have the proper icon?
- Does the template have any visual styling or container formats in it (for example, it should only determine how regions are laid out)?
CSS
- Can the overrides be replaced with existing helper classes?
- Can the overrides be replaced with an existing Skin format?
- Should the overrides be converted into a new Skin format (especially if they're used in multiple places)?
- Are the overrides using mixin references whenever possible?
- Can we replace the !important flag with more specific selectors?
- If not, are there comments explaining why it is necessary?
- If the overrides are using floats or absolute positioning, can they be replaced with flexbox based styles?
- Do the overrides account for optimized layouts (for example, No references to .layout or .layout-body)?
- Do new helper class names follow naming conventions?
- Are new global helper classes specific enough to work in all cases?
- Are helper classes properly documented so they appear in the helper class picker?
- Are the selectors using helper classes instead of section references (for example,
div[node_name=""]ordiv[data-node-id=""])?- If not, are there comments explaining why?
- Can the selectors' specificity be reduced and still work (for example, .layout > .layout-body > .flex.content.helper-class > .flex.content-item to .content.helper-class > .content-item)?
- If the overrides are intended for end-user portals, does the CSS file start with "py" so that it can be overridden by customers?
- Are all CSS warnings justified?
Skin
- Is the format using existing mixins as much as possible?
- Is the format sufficiently unique enough (meaning it can't be easily replaced with another format and/or helper classes)?
- Does the format conform to the design system?
- Does the format have the correct focus, hover, and active state styles?
- Does the format's name reflect its purpose rather than its style (for example, Case details card versus White square with padding)?
- Does the format's description explain when and where to use it?
JavaScript
- Is the script stored in its own JS file (that is, not contained in a non-auto-generated section)?
- Is the javascript being loaded properly?
- If meant to be a global script, is it attached to a top-level harness, or packaged as part of a bundle?
- If meant to be a local script to a particular section, is it being loaded with the <pega:onlyonce> directive (via a non-auto-generated section)?
- Is the script tag writing inline styles to the DOM (i.e. should it be adding/removing helper classes instead)?
- If so, are there comments explaining why?
- Is the script properly unbinding event handlers to avoid memory leaks?
Check your knowledge with the following interaction.
トレーニングを実施中に問題が発生した場合は、Pega Academy Support FAQsをご確認ください。