Skip to content

Latest commit

 

History

History
27 lines (14 loc) · 1.62 KB

development-principles.md

File metadata and controls

27 lines (14 loc) · 1.62 KB
Raw

Smart Answer flows - Development principles

Do's

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

Dont's

  • 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's" section above.