Setting up a front-end development project

For more than a dozen years of working in web development, I have been all around this business. I worked on distributed and cross-functional projects, in teams of 3-4 people to teams of 50+ people. Lately, in the main, I was forced to perform the functions of a front-end "plumber", which basically means if something goes wrong, there I am. Raking the accumulated cases and trying to make it work, I involuntarily asked myself: "How to simplify this process?". As a result of suffering and other non-trivial steps I created my so-called "Web Dev road map". An experienced can consult with it, while a newbie as a starter's guide. Anyway, first things first.

What about the legacy? What's in my hands?

According to my personal experience, the first thing to start with is understanding the level of code "excellence" you have to deal with. I got projects with polished business process, but they still didn't work right. Over time, it was clear that evaluating a project by its technology stack, architecture, mobile development process and other fancy things was not optimal either. I suppose you now started thinking what a nonsense I'm writing here. However, all described cases is my real personal experience, which I share, but it is up to you to take it into account or not. In fact, to analyze any code, it is better to start with the following steps:

1. Check your repository. Its type (SVN, Git or Mercurial) is the matter of personal preferences. Primarily, you should pay attention to access to the repository, who has it and which rights they are granted with. First of all, check that there are no "ghosts" in the repository. That's not okay if they have been found, because it`s not only security breach and it also means that the project hasn't been properly maintained.

2. Calculate the number of branches in the project. If the GitFlow is used incorrectly, there will be more than 5-7 branches (dev, test, uat, prod, etc.). However, this is not an ultimate truth, as this may also means that these branches are introduced for the project versioning (releases). In this case, you need to understand if they are being used or not. If the branches are not touched for over six months, then they are not needed.

3. Read comments in the project to analyze what they say. If you see comments like "If there are 100+ people in a class, then I will come and apologize personally", or "I don't know why it is here, but the whole thing just would not work without it," or "this is a long-way workaround, but we can't avoid it", or the most frequently used "delete", and then huge chunks of commented code? If that's the case, I'm deeply sorry. Do not even expect to find any code review in such a project. Cursing and poor lexis in project comments means a deal. Professional developers do not do that and can't accept that from others. I advise you to pay attention to console.log and debugger, if any. Existence of console.log is not so scary itself because it's only going to spam to the console which won't always be open for a client. While the debugger presence can lead to errors or what's worse - non-operability of the whole application.

4. Explore the style of code. I had a project written in Angular, which looked pretty nice from the first sight. Though after a deeper look the project occurred to be written under the React guideline, which was a pain honestly. Some of you might ask, what's the problem? In fact, of course, "it's nothing", but every framework has its standards (because it's a framework) and it was developed by the creators for a reason.

5. Check the project build configuration. To start with, you have to find out if it's the same for all branches or have some nuances. It's a bad if it is the same, because in that case debugging code gets to production.

6. Check the use of external libraries and relations to them. It is desirable to understand clearly what is used and why. In my opinion it is not perfect, if the project is large and there are many third-party dependencies in it, because this will obviously entail updating issues and all kinds of conflicts. According to my experience it's better to write individual components which don't depend on external libraries for larger projects. Generally, there are two types of external libraries. The first ones, the so-called auxiliary, include lodash, ramda, moment etc. The second ones, the so-called libraries of limited features. These include calendars, dropdowns, etc., - they will bring cause in future.

7. Check project for using of automation. Everyone knows that it's strange to create builds and deploy them in manual mode in the IT era. There are plenty of tools, such as Jenkins and GitLab, which can do the automated job for you on the market these days. They will eliminate the issues of the old build on the test branch, and ensure that there is always the latest build.

8. Test availability is not critical, because not all of them are equally useful. In my opinion, if there are integration tests, it's cool. But if they are absent, it would be good to understand why and what to do about it.

Once you checked the listed points, you can define your further strategy on its further development.

What to begin with?

In order to build interaction within the team, you need to figure out who is in charge of what. If you got to lead some part of project, I would advise you to start with meeting the rest of the project leaders. You need to understand what is generally going on with the project because you will be its important part. Suppose you have a big project. You become the leader of the front-end development and you get to know three more leaders: of the back-end development, QA and analytics. That's just an example, but here is what you might what to ask your colleagues about:

1) Learn about their issues and bottlenecks. This will allow you not to run across the same restrictions when you will plan your work.

2) Find out their plans. You can create synergy if moving into the same direction to achieve the ultimate project goal. For example, you'll need back-end assistance in moving to FULL REST API or generally you'll need to build trustful relations with QA in order to develop a great product.

3) What they would like to receive from your team. Which means - collect wishes and rationale behind them. This will help you see how to change communications and business processes in order to increase the overall team performance.

4) Calculate the approximate deadlines for the project. This will help to set priorities right.

Now you should know what you're in for. You can start planning all necessary actions.

Keep calm and code

At first, you need to establish a good transparent process of setting tasks and achieving results. In order to move ahead and achieve the main project goal you should follow the following rule: it may not work perfectly, but it least it works. This is a case when it is better to focus on the result and not dive into the nuances. Otherwise, you can get bogged down in unnecessary actions and not get the result, despite your efforts.

Below is my personal plan, which I try to stick with. You can make your own plan with a different order of points, but the points, I guess, will be same.

1. Delete all excessive branches. This will allow your new employees not to get confused with the new project, and for you too - when you keep too many other things in mind.

2. Set up automation of builds and deployments. This will let you not to waste time updating the branches manually. Once and for all.

3. Set up build configuration for different branches. For example, for production you need to delete unnecessary elements, such as comments, consoles and debugs.

4. Delete irrelevant accounts, if any.

5. Set up linters that to standardize your code.

6. Introduce code review which will allow you to see what was committed and to make necessary edits.

7. Link your repository with your bug tracker (Jira, Redmine) in order to see what was done on each task, and which commits relate to it.

These are the first steps that can be your basis for work. Having set up the routine work, we should build the process of creating, executing and collecting reports on the project tasks. I adhere to the following plan:

1. No task - no commit, commits are forbidden without specifying the task. It is also forbidden to include several tasks in one commit.

2. All tasks must go through their life cycle:

• Creation which includes deadlines estimation and prioritization
• Assignment to the developer
• Start of work
• Sending to the code review
• Sending to QA
• Testing
• Reopening or closing a task.

3. All tasks should be initially assigned only to the team lead, who will distribute the workload. This is critical because the team lead needs to know the current status of the project and should be able to report on the project without distracting developers from coding.

4. While building the task life cycle, it's important to monitor that tasks only get reopened if new requirements arise or a bug is found while testing this task. It's important that tasks don't get reopened due to the fact that the bug is reproduced or some of requirements have not been initially considered. To keep this working, you have to talk to the QA team lead and explain the need to explain this rule to their subordinates. (I hope everyone knows that such agreements should always be supported by a letter with the CC'ed Project Manager.) This will allow you to effectively track performance of your employees.

These simple steps will allow you to get tasks clear and structured, but this is far from over.

There's always room for improvement

So here we have a coherent workflow to efficiently complete tasks without unnecessary distraction, though the "perfect" legacy code is still there in the project. In order to solving the problem of improving the project quality and increasing work efficiency requires you to figure out what is exactly wrong with that code. I would take the following steps for this purpose:

1. Employ some code analyzer such as Sonar. It will show how much copy-paste and other trash you have in the project.

2. Move the copy-paste to individual modules or components. If your knowledge is not enough to solve these problems, it would be great to ask for the Technical Lead advice.

3. Agree with the Back-end Team Leader to integrate Swager, for example, if it has not been utilized in the project yet. This tool will allow you to test API methods and improve the productivity of debugging your own code.

4. Analyze the project architecture and find out its bottlenecks. Colleagues from the adjacent department can be very helpful in such tasks.

5. Evaluate external libraries and the relevance of the technology stack in general. You should find out how much efforts it may take to get rid of third-party dependencies, and how difficult the update process can be.

6. Run a load testing and performance testing. These procedures will allow you to know which pieces of code are not optimally written and where some refactoring is needed.

7. Identify the elements that need integration tests. This will avoid misunderstanding during the development process.

These easy actions may help you achieve a good update and optimization of the application. All the described above is pure planning and doesn't require much work. Collecting details about the project will help you estimate the complexity of the project and development and maintenance in terms of technology and code.

As a conclusion

These recommendations don't take much time as it may seem. According to my experience, this can be introduced in just a month (though there may be some unpredictable obstacles, of course) with a proper tech competence in software development. I intendedly avoided specifying technologies and/or describing specific solutions. Each project, from a monitoring solutions to an online store, has its own unique characteristics and terms, but the details listed above exist to one degree or another. All in all if you are seeking for a professional service, it's better to hire virtual team. I wrote this article to support people who vaguely imagine where to start their front-end development journey and point them in the right direction.