Best Practices for UiPath Development
Often when learning new development technologies, commonly agreed-upon best practices are told to the student at the very end of the learning process. Why? I think it’s helpful to lay out some best practices from the very beginning of the learning journey, to lay a solid foundation. Even if the student doesn’t understand them all at first, over time she will come to understand them more and more, and by the time she has mastered the technology, they will be second nature to her. Here are some of the common best practices which can be incorporated by the aspiring UiPath developer:
- Write not just for the computer, but for humans. Write descriptions for the project and each workflow as to its purpose and what it should return; give variables meaningful names; be clear with annotations and renaming of activities; log the progress of execution. It’s worth the time to leave breadcrumbs for yourself and other developers. In a few weeks, months, or years, when you have to revisit the code, you’ll be surprised how much you’ve forgotten, and you’ll thank yourself.
- Use a Flowchart or State Machine layout in main.xaml. Invoke other workflows as needed. Main.xaml is the front page, the map of the journey, and it should be easy for a human to follow and understand.
- Keep workflows small and testable. Recommended size is under 5MB.
- Use a TDD approach for individual workflows as much as possible as detailed here.
- Surround workflows with Try/Catch and handle exceptions. When an exception is encountered, the logs should detail everything that is needed to know as to what went wrong and where.
- Use credential storage responsibly. Use Orchestrator or Windows Credentials, never inside the workflow itself.
- Clean up your messes. Close browsers and apps at the end of the process, delete unused code and remove unused dependencies before publishing. Be a good developer citizen.