Skip to main content
Last updated: 14 Jun 2021

smart-answers: Smart Answer flows - Development principles

Do

  • Make small improvements to the code before making even business-as-usual changes. See refactoring existing Smart Answers for some common improvements.

  • Make use of the higher-level abstractions available in the project, for example the DateRange, YearRange and YearRangeWithFixedStartDate classes.

  • Extract more higher-level abstractions where the same behaviour is being duplicated across multiple flows.

  • Model the domain of the policy/rules that make up a Smart Answer.

  • Ensure all policy logic is encapsulated in objects that are instantiated by (but separate from) the flow.

  • Ensure all presentation logic is kept in the ERB templates and associated helper methods.

  • Ensure the Smart Answer flows only contain routing (next_node) logic.

  • Iteratively develop new Smart Answers. Get a simply happy-path version deployed and build upon that in collaboration with the department and content team.

Don't

  • Don't copy the style of existing "legacy" Smart Answers (e.g. calculate-agricultural-holiday-entitlement).

  • Don't blindly follow the logic documents when creating/amending Smart Answers. This has lead to some of the problems we see in the "legacy" Smart Answers, e.g. policy logic being mixed up with flow/routing logic resulting in hard to maintain code.

  • Don't do big-bang development of new Smart Answers. See the point about iteratively developing them in the "Do" section above.