8 Tips on How to Make a Developer's Life Better
Making the gray cloud grayer, let's assume that a project that came under your jurisdiction was written by several teams at different times. At first there was one team, when they went, the second team decided to do things their own way, and so on. And then the project has been passed down to you.
The worst thing about this kind of projects is the uncertainty. Work on such a project is like communicating with multiple personalities of Billy Milligan: each time it's a great mystery of what waits for you in the next line of the narrative. Each next developer stumbling upon all this horror in the source code tries to implement a new feature in another style which seems to him a better solution. And this only aggravates the situation, because before him the project was written in N styles, and from now on, it will include N+1 different styles. And it does not matter how wrong the previous developers are and how right the current one is.
Here are some rules for working with such inherited projects:
1. A separate pull request can contain either logical changes without updating the style of the code or changes of the style in the whole project at once without new features added. For example, if you do not like the mixed use of single and double quotes, make a separate pull request in which you standardize only the use of quotes throughout the entire project. But when implementing the current project task such as adding functionality, use the style adopted in the project at the time of writing the code, regardless of whether you like it or not.
2. Do not try to refactor code for which you do not have tests yet. The reason must be obvious.
3. Adding tests and refactoring the code should be placed in different pull requests. The sequence of actions is to first make sure that the code works as expected, and then check that the refactoring has not broken anything in this behavior. This is not the same thing as writing tests and changing the application's behavior in the same pull request.
4. If you feel a great need to refactor the code while fixing a bug, then you should still follow the third item of this list. First, write tests, then - refactoring, and only after that - fixes. Or, first - tests, then - fixes, after them - tests again, and then, at last, refactoring. And of course, refactoring should go in a separate pull request, and one of these sequences must be followed.
5. Use auto-formatting of the code style. As a rule, all styles are customizable and it is possible to dictate your own ruleset with the configuration file right inside the project for all team participants. This should be done, of course, no sooner than you refactor all parts of the code enough, and such auto-formatting won't change existing files.
6. Before making a pull request with +100000 and -100000 refactoring changes in the code lines, where you correct all the same type of quotes, go around your colleagues and make sure that you won't spoil somebody's life with such an update. Maybe some of them have unfinished current work, and they will need to resolve numerous conflicts after your merge. You will be much easier to resolve these conflicts instead of them.
7. Act gradually. Don't try to correct everything and everywhere at once. Start small and, let's say, make it a habit to take a small step towards standardization of the code along with the morning coffee. It won't take much time and daily small pull requests will do their thing in a couple of weeks.
8. Share your intentions with your colleagues and make sure that you are on the same page with them. If they do not want to help you in this standardization process, then at least ask them not to interfere and accept these rules. For example, if you recognize your project in the example above, just send them a link to this article and start making your lives a little better. If you do not agree with some of the statements, feel free to share the counterarguments with us.
Riter development team