#OMRS2020 Internship is almost over. We are at the end of the period of tasks, but the time for a summary has not come yet. We’re here to share with you the accomplishment of one of the participants.
We are extremely proud that a participant in our program took up this topic in the OpenMRS community and decided to highlight a serious problem in the OpenMRS code. Namely, it is about improving the code by making it clean, shortening and removing unnecessary lines, as well as using the latest and best techniques adequate to the programming language.
So, let me tell you a story…
Łukasz is one of our interns of this year #OMRS Internship edition. He presents himself as a soldier, network administrator, programmer passionate, amateur runner and devoted blood donor. But we could say he is one of our most active interns and a person we could be proud of. His work is really impressive, his code is on a high level and many people from the OpenMRS community are thankful to him for his work and dedication. But what he has done with a simple tool and how he used it for his own usability is really great. None of the rookies in the OpenMRS’ community has ever done that.
Łukasz at first had problems with OpenMRS’ documentation as it’s too long and hard to understand language. It takes him time to understand the most important facts and gather knowledge to be able to do tasks. With some help from the community and with his hard work and many hours spent on boring documentation he overcame troubles and now with success is doing tasks.
Unnecessary tools or missed chance?
OpenMRS is using a few programs which have an aim to make your code better, more transparent and well readable. If you want to make your code the best as you can you should use available tools and with guidelines from them start improving the code. In theory, everybody before releasing their code should check if their code meets basic requirements, but in practice, almost nobody does that. And in the results code is lower quality than it could be, there are more errors and bugs and often it could be less messy and shorter than it actually is.
Łukasz shows his work under this post. In his task he describes why this issue was created and what he wants to do. There is also a list of sub-tasks which were created with the main task. All of them include improving current code by simplifying it, cutting unnecessary or not important/ not useful elements.
The Intern has done a great job. He has to spend many hours analyzing the code, but at first, he has to learn how to use the tools like SonarQube. I’m very impressed by his work and we have at least only one month before the end of the Internship. For sure he surprised us with many things and discovered new possibilities to make his work greater.
Like a typical story, it has a good ending, because Łukasz has achieved the required level of programming. The conclusion it gives is that we should not give up the path to success despite many difficulties encountered. Remember – every effort will be rewarded.