The cost of your application is probably one of the crucial things you’re considering during the planning stage. Sometimes small tweaks can decrease the overall cost of the application if you make the right decision. There is always space for improvements and it’s always a good time to make a change for the better. I'll try to give you some details about which things you should have in mind whenever you build your frontend, what should be avoided, and what you can do to make the development process cheaper.
To understand problem we need to analyze the reasons. It's no surprise that the cost of your frontend is just development time multiplied by the hourly rate. The article could end here, but this is not the reason why some projects are expensive and others are cheap. So I’ll try to walk you through the factors which depend on the time spent by developers on building app.
The factors mentioned above can decrease/increase the time your frontend developers spend on tasks. Being aware of them and taking care of them in the correct way can ensure you will be satisfied with your savings. But there is most important question. What you can do as a frontend developer to reduce app cost?
Don't be afraid to hire tech lead who will choose the best technologies and tools for your project. The wrong tool can cost you a lot of extra work or even require a migration to another technology which can meet your requirements.
It should be granular, consistent, correctly split into folders, and easy to extend. Whenever we build a project, we need to think of how it will look for not only in weeks, but in years.
In the above example, the project structure (Vue, Typescript, Vuex, Vue-router) has four main subfolders in the src directory:
components - contains UI elements in separate folders
static - contains data which doesn’t change (for example list of panes to display and iterate over)
store - contains Vuex logic and is split into folders of modules
views - contains Vue-router pages
Other configuration files are not included in these folders. This kind of structure is easy to understand and extend.
If you haven’t described project practices in this file, change this! Every project needs to have a source of truth which could tell other frontend developers about best practices, project configuration, structure, and other stuff to avoid misunderstandings in the team. What should be included here? Everything people ask about. Assume that people may not know about many things and that everything should be described in depth. https://github.com/matiassingers/awesome-readme has examples of good README files.
It’s not a common approach, but I saw plenty of times when a few guys knew everything and others not much. It's not healthy - knowledge must circulate around the team.
There are plenty of tools which could help you to achieve this goal: IDEs (prettiers, code formatters), server CI tools (Travis, Jenkins, code climate), linters (eslint, tslint), precommit/prepush tools which analyze your code and block everything that doesn’t follow project code conventions.
Use shortcuts, extensions (IDE and browser), set a daily focus time for developers when they won’t be distracted, automate repetitive processes, minimize distractions, don’t forget about your health - take a short break every hour to freshen your mind and sleep well.
Be lazy in positive way. Do you see something in your code that could be reused? Don’t hesitate to do it! It saves lots of time.
A frenzied pursuit of deadlines can cause the quality of the code to go down. So take care of the quality of your code, do code reviews carefully. Bad quality code is harder to change or debug.
It doesn’t mean that more is better. We could test almost everything, but it wouldn’t be the correct approach (except if it's a medical application which mustn't fail). Especially when the requirements are dynamic. Correct testing means that every crucial part of data is covered by tests and is stable. Also, a part of bug fixing should be writing proper test to avoid future problems. Testing also gives you better insight into code and the application.
There are a plenty rules which could be an article. In short it’s: self-explanatory code, DRY, module patterns, avoid unnecessary comments, clean code from console.logs and unused code/folder/files/resources, use correct code indentation, make the code as good as possible and don’t wait for a refactor (it’s harder to debug and it’s a way to get spaghetti code), use developer tools, ES6/ES7, frameworks, CSS preprocessors and code conventions, organize code in dedicated folders. There are many more techniques to make code leaner and more friendly, which I encourage you to learn.
An external library which can allow you to store your UI components separately. It helps maintain bigger projects and stay DRY. Whenever I joined projects, I spent too much time finding components which I could use to save my time. This is exactly when Storybook comes to the rescue!
This is a phenomenon where developers choose technologies based on current trends. It especially refers to the frontend world where we have plenty of new technologies and new stuff. Technical decisions have a crucial impact on creating and maintaining a project. Therefore, try to avoid implementing unproven solutions that may hinder your work. Here you can find an amazing article about HDD.
We’ve covered what makes up the cost of an application and what you can do as a Frontend Developer to reduce the cost of your app. Every point refers to an action which can save your time, make your job easier, makes you more satisfied, and protects your project from being inaccessible to new team members. A happy developer who can easily find any data in his project is a productive developer. Remember that it is always a good time to introduce quality changes. I wish you luck with that goal!