{"id":65,"date":"2017-01-20T22:32:49","date_gmt":"2017-01-20T19:32:49","guid":{"rendered":"http:\/\/iamakulov.com\/notes2\/?p=65"},"modified":"2017-05-06T04:23:56","modified_gmt":"2017-05-06T01:23:56","slug":"exclusive-code-ownership","status":"publish","type":"post","link":"https:\/\/iamakulov.com\/notes\/exclusive-code-ownership\/","title":{"rendered":"Exclusive code ownership (why it\u2019s bad and what to do with it)"},"content":{"rendered":"

In December 2016, a front-end developer left\u00a0a\u00a0team where\u00a0I work. Apart from other changes, this created an issue. When he was working, the project had a couple of complex modules we were developing with him together. When he left, I realized that only I am able to work with them \u2013 other two team members knew nothing about how these modules function. This is called \u201cexclusive code ownership\u201d<\/em>, and it\u2019s bad in the long term<\/mark>, so I had to start fixing this. Here\u2019s why it\u2019s bad and what to do with it.<\/p>\n

\n🖐<\/span> 🔮\n<\/div>\n

Problems#<\/a><\/h1>\n

Bus factor#<\/a><\/h2>\n

Imagine there\u2019s a complex module in your project that only you work with, and you\u2019re hit by a bus tomorrow. Will the team be able to\u00a0continue developing this module the next day? Most likely no.\u00a0This means the bus\u00a0factor of your team is 1 \u2013 that is, it\u2019s enough to kill<\/s> remove a single developer from the project to severely slow or even stop its development.<\/p>\n

\nUntil recently,\u00a0our project has been heavily relying on\u00a0a custom\u00a0front-end framework that was developed by only a single team member. No\u00a0other developers knew\u00a0its inner\u00a0parts, and only\u00a0a couple of them knew it deep enough. This meant the bus factor of the whole front-end team was just one. This, along with other issues, led us to migrate from this custom framework to React in 2016.\n<\/div>\n

Bottlenecks#<\/a><\/h2>\n

If\u00a0there\u2019s a\u00a0module in the project that you exclusively own, then, regardless of the team size, only you will be able to make changes\u00a0in it. If\u00a0tomorrow you\u00a0receive 5 critical issues related to this part,\u00a0there\u2019ll be nobody to help you. You may even slow down your team if these critical issues block them.<\/p>\n

\nWe had this problem\u00a0when\u00a0a part of our front-end infrastructure changed, and this broke builds for the whole team.\u00a0Because it was only\u00a0me who knew how\u00a0all this stuff works, I had to\u00a0fix the\u00a0problems one-by-one. If\u00a0other\u00a0team members knew this, they could\u2019ve helped me bring everything back sooner.\n<\/div>\n

Leaving is hard#<\/a><\/h2>\n

If\u00a0once you decide to\u00a0leave the project, you\u2019ll have to transfer all your unique knowledge about how these parts work to other team members.\u00a0Depending on the knowledge size, this can take\u00a0significant time, and it still\u00a0will be less effective than if other members had real experience with the code.<\/p>\n

You create risk and slow down delivery<\/mark><\/p>\n

What to do#<\/a><\/h1>\n

Documentation and maintainability#<\/a><\/h2>\n

You have probably heard this advice for a lot of times, but it\u2019s never bad to repeat it again.\u00a0Make your code documented and maintainable. This includes\u00a0code cleanliness, inline comments, and external documentation.<\/p>\n

It\u2019s your choice how\u00a0much to document the code. I usually try to make it self-documenting<\/a> and add comments\u00a0only if the purpose of the code or the decisions behind it are still unclear. Also, remember that self-documenting code is better than comments, and comments are better than external documentation<\/mark>. People occasionally forget to update the comments and often\u00a0forget to update the external documentation, so the only up-to-date source of information is code.<\/p>\n

Commit messages#<\/a><\/h2>\n

In my experience, writing detailed commit messages is very underestimated.<\/mark> I\u2019m sure that one of the best ways to share your code knowledge is to include it into your commits.\u00a0Once you commit something, it stays in the history forever, and\u00a0tools like git blame<\/em><\/a> help you to\u00a0easily\u00a0find\u00a0which commit changed the specific\u00a0lines. This means that\u00a0even if you leave the project, the other developer\u00a0that will work with the piece you\u2019ve written will be able to git blame<\/em> the code and see why you made this or that change.<\/p>\n

What to write in a good commit message?\u00a0Well, this\u00a0is one of the examples from my project I like (I wrote this so I like it, pretty obvious):<\/p>\n

\"\"<\/p>\n

Look, this commit includes:<\/p>\n