Single Responsibility and Open-Closed Principle
Single responsibility means, each class should only do one thing. One of the reasons why each class should have single responsibility is because a class can be changed by more than one member of the group for different reasons. If a class has many responsibilities, the more often the class will be modified then. This can cause module incompatibility and the possibility of conflicts when the code is merged will also be higher.
Secondly, open-closed principle means, we should make our class open to extension and closed to modification. In other words, if we want to add functionality, we just need to add new lines of code without interfering the existing code. The goal is the same with the previous principle, which is to minimize the risk of generating errors from editing existing code.
Those principles are two of five of the well-known object-oriented programming principles called SOLID principles: Single responsibility, Open-closed, Liskov substitution, Interface segregation, and Dependency inversion. For more details on the other principles, you can search the internet for yourself.
More Files, More Commits
Working in a team is closely related to using a version control system like Git. One thing that complicates the work the most is the existence of conflicts in certain files caused by different versions of changes from different team members. A possible solution is to create separate files for each different class (or function related to each other). This aims to minimize the possibility of conflicts in files that are being edited by more than one programmer at the same time. Imagine if there is a file that contains many functions, and all programmers edit the same file at the same time, of course it will be very complicated and very risky for conflict.
Also, don’t be lazy to commit often. This is one of those trivial things that programmers often forget. Usually, we commit when we’ve made a lot of changes just to save time. In fact, the habit to commit little by little is a very useful thing. Because if an error occurs later, it will be very helpful in investigating the changes where the error occurred. And it will be easier if we want to go back to the previous version if unexpected things happen.
Leave it Clear, Don’t Hide Behind Comments
Sometimes we may find that writing comments in our code is something that is often debated. In some cases, comments can help other programmers or even the person writing the code easily understand what the code is doing. On the other hand, the presence of comments can sometimes be a bit problematic especially for collaborative projects.
Programmers often do not pay attention to comments when they modify their code. Or when reviewing or making changes to other people’s code, programmers sometimes forget to adjust comments about the explanation of the code regarding existing changes. This can lead to misunderstandings when one day another programmer reads the code, because there is an asymmetry between the comments and the content of the code.
Besides, many of us have the mindset that the most important thing is that the code must run successfully first no matter what. And when the code actually runs, we forget or are too lazy to tidy up or turn it into clear code. Often we choose to comment out some parts of the code instead of deleting them, for fear that they may be used again in the future. Consequently, it can raise questions in the future. “Is this code still in use?”, “When should this code be uncommented?”, and so on.
What I am trying to say is, why don’t we try to write clear code that is human readable at the first place, instead of adding comments for fear that other people won’t understand our code.
Knowledge sharing
In a project group, of course, each member has a different task. In some cases, there is usually only one person or a few people who understand the whole system. Problems will arise if the person is suddenly absent for a certain period of time or even has to leave the project. In technical terms this can be referred to as a Single Point of Failure, where there is one component which if damaged or lost will disrupt or stop the work of the system as a whole.
As a result, other members who know nothing but their own task should try to understand more about their project. Of course, this will take longer and make the project behind schedule.
Therefore, it is necessary to share knowledge between members. Common forms of knowledge sharing used in group projects are code review and pair programming. Both of these are intended for all team members to understand in general, their code, the code of other team members, and their relationships. The benefit of this is that, it reduces the room for error. Also, if one programmer is unavailable, then another programmer can make a backup.
Unit Testing
Every programmer should have the mindset that every code cannot be considered correct until it is tested. Especially if the code will be merged with other codes. Testing is very important to reduce the risk of conflicts and errors. In addition, testing will also make debugging easier because we can easily find out which part is wrong by seeing which unit tests fail.
For machine learning projects, where most programmers use Python, there are a number of frameworks available for easy unit testing, such as unittest and PyTest.
This content was originally published here.