Introduction to Open Source Best Practices
Introduction to Open Source Best Practises
As a Computer Scientist, a researcher, and a programmer I am always interested in improving myself and my code. I recently came across the Interoperable Design of Extreme-scale Application Software (IDEAS) website which hosts a lot of different talks and webinars. One that I looked at recently is Open Source Best Practises (see below).
My notes can be found here.
My synopsis of this webinar is as follows
The main question we should always be asking ourself is “what does it mean to be better”
- We as programmers want to serve and enhance the overall software development workflow.
- When developing software it should compute the correct answer within a certain level of confidence
When looking at this video I believed that they covered three main points. Version Control using Git, Continuous Integration (CI), and Code Quality. Version Control using git is something that I learned much of when in college. From forking and branching to merge and pull requests; git is a great tool to have. When using git it allows the users to track changes and create separate branches for feature development. Using version control is good because it gives you a chance to go back if you make bad changes and see how the code has grown over time. I would recommend using gitlab.com as their continuous integration and user interface is much better than GitHub and they allow unlimited private repositories.
Looking at open source code it is beneficial to contribute to them because it gives you a chance to improve your coding skills. Furthermore, it allows us to be better known in the community and have people recognize our work. This, in turn, is good for resumes and introducing us to better software practices. One of the basic software practices that should be used is code styling, every language as a specific style and format for it. Moving forward once the code has a good foundation you should start writing tests for the code. The types of testing are as follows:
- Unit-testing: tests the specific output of a single function
- Integration testing: tests the output of multiple functions
- Regression testing: ensures that once a bug is fixed, it stays fixed
- Smoke testing: Sanity test for the whole system
- Acceptance testing: Edge testing/ does it fail when it is supposed to
Now that we have the code and know that it is running well for this version we can implement continuous integration. Every time a change is made the code will run the tests that have been designed and let you know if any of them fail. This is good because it can be used to check the code, display the results publically, develop trust in the package you are developing and deploy the service.
One of the things I am not very sure of is the section on code quality, once I understand I will write more about it!