Why some projects disappear after the departure of the programmer from the company
Often, the fate of a digital product worries not only the company that owns it, but also the specialists who directly participated in its development. For many programmers (and the beeline cloud team is no exception), the project they have a hand in is not just a set of code, but a real brainchild, the fate of which does not stop worrying even after leaving the company. We have translated an article for you that will help ensure the long life of your venture.
The article will discuss one of the main reasons for the demise of the project after the departure of the programmer. A few practical examples from real life will help you avoid such a situation.
Have you ever wondered about the fate of a project you worked on in a company?
Personally, I always inquire from former colleagues about the condition of my “child” and whether it is still supported.
And the thing is not selfishness at all. My desire to know that the project in which I have invested so much time is developing and serving its purpose is quite logical.
Recently, I had to participate in a code refactoring. I want to talk about the reasons for its implementation.
Thus, I will mention the topic of the article: the reasons for refactoring.
Of course, my personal opinion should be related to your experience and how your company works on structuring and supporting projects.
The programmer’s duty in writing the code is to use all his abilities in it as much as possible. And to emphasize not only the functionality, but also the convenience of further support, focusing on the long-term perspective.
What leads to the decision “the project is subject to refactoring”
The answer is not written on tablets. There are many reasons for this verdict.
Based on my own experience, I will try to tell about some of them.
You focus only on making your code work
Nothing wrong with getting it to work as intended. After all, this is the main task.
The problems start when there is a need for new features. As with any living thing (and we can consider our system a living thing), evolution in the project is inevitable.
Thus, the code must be ready to change and grow according to new tasks and needs. And if not, then it is doomed to be refactored or, even worse, abandoned.
A disorganized project with confusing names
Reading code shouldn’t be torture. However, navigating through packages and folders in some projects is not at all easy to understand, just terrifying.
A project in which dependencies are mixed or poorly structured can be marked with 100% certainty as “refactoring in need”.
When organizing code, I try to put myself in the other person’s shoes. Is the structure of my modules and packages easy to follow? And if I go on vacation, will my colleague be able to easily figure it all out and replace me?
It is difficult to answer unequivocally. People have different ways of thinking, and every programmer has his own approach to work.
Lack of documentation or its low quality
This is exactly about me.
I already wrote that I am always interested in the fate of my project, even if I left the company. One of the reasons for my interest is concern that I haven’t paid enough attention to documentation. It always seems to me that it could have been done better.
Code documentation can be approached in different ways. Creating complete end-to-end documentation that shows how the system works as a whole would be the best solution in my opinion.
So that another programmer can work on the project (after you leave the company or just your colleague), do not be lazy to provide the code with comments – this is a rule of good tone.
Some tools allow you to create documentation based on comments in the code.
Hard-coded values and no data structure
Sometimes it is quite possible to rigidly prescribe some values.
But when a project is stuffed with them, it’s terribly difficult to scale it without fear of breaking something.
If you don’t know what this is about, I’ll try to explain.
Hardcoding – forcing a variable to have a specific value instead of providing it dynamically.
username = "yanick_user" # hardcode value for username
role = "admin" # hardcode value for role
It is wrong! What if the username changes? Or will it simply be disabled after the user leaves the company? What if I need to change my account type?
You will have to enter the code every time! Now imagine a nightmare scenario where there are cascading dependencies.
Everything can go wrong at once.
username = os.getenv("USERNAME")
role = os.getenv("ADMIN_ROLE")
Another very important point is a well-thought-out data structure. Understanding the importance of data structure can greatly help in writing code.
By having a clear idea of what data your system will handle, you will make it easier for yourself, the interpreter, and those who will work on your project.
if args.get("some_key") == "admin":
user = args.get("user_key")
I don’t know about you, but for me this is very difficult code to understand. What are args here? Is it possible to get other keys from args? Which one is mandatory?
In Python, using the data class (dataclass), it is very easy to describe an object if you know its structure:
from dataclasses import dataclass
Now you can reorganize the previous do_something function and simplify its execution:
ADMIN_ROLE = os.getenv("ADMIN_ROLE")
def do_something(args: Myclass):
if args.some_key == ADMIN_ROLE:
user = args.user_key
Disdain for tests or the complete absence of such tests
And hitting the target. About me again.
To be honest, I started writing tests honestly only after I moved to my current employer.
Now I practically understand the importance of writing them. This kills two birds with one stone. First, we check the functionality of the code, and secondly, we get an excellent guide to using the system and interacting with it. If possible, do not ignore writing tests.
So how do you keep your project from fading?
The question is difficult, and maybe someone will be able to answer it better than me with 100% certainty.
One thing is certain – if you take into account my recommendations based on your personal experience, you will be on the right track.
Yes, I’m not infallible, but I always try to follow best practices in system design.
I periodically look into PEP (Python Enhancement Proposals) and read suggestions for improving Python. There is always an opportunity to learn something new and interesting. Python is a rapidly evolving programming language and I try to keep up with the times.
Maybe you will remember something from your personal experience? Maybe this will help someone avoid the “Requires refactoring” black mark.
More practical stories for solving IT challenges:
In order to develop high-quality and secure applications, the company needs to find a suitable way of finding and eliminating vulnerabilities. To choose it, you can evaluate different testing methods according to four criteria: implementation complexity, impact on software life cycle time, and false positive and false negative triggering.
We share a comparison article with visual graphs to help you decide which tool is right for you: SCA, SAST, DAST or IAST?
Migration from foreign software to Russian often becomes a problem for large companies with a large number of business processes and data. We tell you how to implement such a transition. Inside – useful recommendations for those who are new to migration.
How to deploy CRM in 7 steps?
CRM helps the company to lead customers from acquaintance to building loyalty, without losing information along the way and automating part of the process. We tell you how to implement a CRM platform in 7 steps so that employees do not stop using it.