Best way to conduct code reviews?

In most software development projects, code is stored in Git, and code reviews can be easily conducted in a lightweight fashion using GitHub pull requests.


With Appian there is no easy or intuitive way to do this. The only way to review code (that we have found) is to review the object in its totality. For expressions and interfaces you can manually comb through the Version history, pick out the prior definition, and run it through a text diff tool locally, but this is tedious, and doesn't allow collaboration as easily. For process models, it is impossible, which is another reason we try to make our models as small as possible and do everything in SAIL.

 

Has anyone built a tool for enabling efficient and collaborative code reviews, or is this just generally accepted as a limitation of the Appian product and an impediment to generating high quality code?

  Discussion posts and replies are publicly visible

Parents
  • I think code reviewers should check whether the process has been designed as per the best practices proposed by Appian. They should make a checklist of the best practices in both process model design and Interfaces and check if these best practices have been implemented. Ex: Checking the performance view for the UI(Interfaces). It should be as minimal as possible say less than 100ms to avoid bad end user experience. For process models, check for security, archieval settings,alerts configured and if a new field is added to the UI, u need to consider how the existing instances work without breaking up.
    We did built a code review tool, some time back which checks whether the best practices have been followed in the process and generate a report by uploading the package into the tool.
Reply
  • I think code reviewers should check whether the process has been designed as per the best practices proposed by Appian. They should make a checklist of the best practices in both process model design and Interfaces and check if these best practices have been implemented. Ex: Checking the performance view for the UI(Interfaces). It should be as minimal as possible say less than 100ms to avoid bad end user experience. For process models, check for security, archieval settings,alerts configured and if a new field is added to the UI, u need to consider how the existing instances work without breaking up.
    We did built a code review tool, some time back which checks whether the best practices have been followed in the process and generate a report by uploading the package into the tool.
Children
  • Appian Employee
    in reply to ashokv

    Per Ashok and Christine, there are two levels of reviews - code structure and best practices/design review.

    For the former, there is no easy way to do it - SAIL could be maintained in git and potentially diffed. From there, things will get progressively more challenging all the way to process models which at this point have to reviewed visually. As Christine noted, change logs with peer review are the best way in this situation.

    As for design reviews, we have best practices checklists for each stage of a project. Additionally, I always start my review with teams running Appian Health Check, which checks for many items on the best practices lists and focusing on the flagged risks. It is incredibly useful - at some point teams include it into the delivery cycle and only escalate items that they are having a hard time resolving.

  • Hi Ashok,
    Can you provide more details on the tool built for code review. Is it shared in community?
  • A Score Level 1
    in reply to sahithip120
    Hi,
    The Code review tool is not shared to the community. It needed some changes, the last time I worked on it 3yrs ago, but it was handy tool though. You can try building ur own by reading the XML tags of various components of Appian export package.