Automation impact

End-to-End RPA explained
in simple words

Automation impact

End-to-End RPA explained
in simple words

AI5 – Development Standards – Part 2

AI5 - Development Standards - Part 2

Topic: Development standards
GuestRadomir Ivankovic
Recommended for: RPA developers, RPA Lead, 
CoE management

Development Standards - Part 2

About the Guest: Radomír Ivankovič – RPA CoE Lead Developer @ OLX Group, Germany

First part of Development standards can be found here: https://automationimpact.io/ai4-development-standards-part-1 

The Script of the Episode:

01:00 How does the development procedure look like
04:48 How to reuse your components – The Principles of Reusability
13:21 Where to store the components 
17:46 Naming Conventions
22:45 Configuration of the robot 
27:13 Framework customization
30:49 Code readability & Code review
36:16 Technical levels and differences between Junior and Senior Developers
42:52 Can you become a developer without university?
46:37 Development Standards 2.0
48:12 Frequent myths and mistakes
49:42 5 DO’S and DON’Ts of good development standards 

 

Following describes how the development procedure looks like. First you need to take a good look at a process to determine the “in-scope” and “out-of-scope” areas. Then you need to determine what is your transaction item. When you have SDD you can start building component by component (single component build): “Don’t be afraid to slice it as much as possible” as this will make your code more flexible & reusable. Document all assets and make sure that every part of the process works independently. If it works independently, you can reuse it later.

Reusability is a common practice. Main principle here is that you can split whatever can work independently. Anything you see that can work for another process is reusable. This practice is very useful as it will speed up your development and raise your effectivity. Radomír notes that he often uses reusable components for closing his tools. Reusability is also important for quick and responsive maintenance whenever something is happening. 

The codes can be stored in various places – TFS, GIT, SVN, Sharepoint, or shared-drive, or there is also the option to create Libraries in UiPath. Radomír’s company is working with Amazon’s S3 Bucket, which allows them to store all the codes in one folder while all the robots can access the folder so each time there is an update, the robots are updated immediately. Of course, the regression test is needed after each update to ensure everything is working smoothly. As for the naming convention, there is no right or wrong way. However, Radomir has shared some useful tips: using CamelCase and Hungarian Notation (naming convention), and naming the arguments with “in” and “out” prefix.

Technical information about the configuration of the robot is stored in the config file. Radomír’s company is using G-suite where they have two Google Drives – one for production (developers do not have access) and another one for UAT and development. The folders there are separated for each robot. 

Code readability is something you should pay attention to as you need to understand what you have created even after a longer period of time. Comments and annotations can help a lot here. The last step of the development process is the code review. After reviewing, you note everything that needs to be changed, send it back to the developer. This also helps to “grow junior developers”

What about Development Standards 2.0? Firstly, the roles will be much more segregated. On the technical leveloptimize then automate the process and check if there is a better way (API) of execution. 

As a skilled developer, Radomír also sheds light on frequent myths and mistakes. The top myth is that bots will do everything and you won’t need humans anymore. This is a mistake as humans will always be needed to control the bot and work with them (discussed more in our previous episode People’s Awareness). A big mistake Radomír mentions is the manager’s talking about headcounts what is not well received by employees.  

5 dos and 5 don’ts to ensure building good development standards:

DO

  1. Share knowledge
  2. Make deadlines not working hours (give space to developers)
  3. Use ReFramework
  4. Make as many reusable components as possible
  5. Raise awareness (who you are, what you are doing, how you are doing it)

DON’T

  1. Question someone else’s logic
  2. Hardcode values
  3. Hire seat warmers
  4. Allow using invoke code on every occasion
  5. Allow changing of Framework once it’s agreed

In the end, if you find this topic interesting, you should know that you can become a developer even without studying it in high school or college. You just need to be persistent and ready to learn, you can do it. “Practice and training. If you have a talent, that’s nice, you can speed it up a little bit. Training is everything,” as Radomír says.