Product development guide #1

Several months ago, I’ve created this guide for my colleagues to improve development process and to avoid popular mistakes. It is not a dogma, but it should help developers with better understanding of what they are working on and how to do their work better.

General Rules

The main purpose of this manual is to improve the speed and quality of the products you develop.

1. The code must follow all the guidelines of the development community
2. The code must be readable
3. The code must be testable
4. The code must be maintainable
5. The product being developed must be easily scalable
6. The code must be written inherently high performance
7. The code must be reusable
8. We make products, not just write code. This means that we should also enjoy using the product ourselves.

Statement of Objectives

1. Tasks are taken from the tracker and only from it. If the task came in the mail or in a messenger, it must be transferred to the tracker
2. If the task is not in the tracker, it does not exist. In rare cases, the task may be described post factum, but it must be necessarily described and documented
3. The task must have a qualitative description - its purpose, incoming values, the process taking place, and what the output should be. If there is no description, the task is submitted for reissue.
4. Tasks requiring frontend development must have a design. If there is no design, the task is re-designed.
5. Tasks must have a start and finish date (planned and actual)
6. Duration of the task must be not more than 1 day. If the task is longer, it must be divided into small tasks.
7. The task must have a priority. Tasks should be performed according to the priority

Task fulfillment (daily plan)

1. Before starting work, read the task, mark your participation in the tracker
2. Find out if nothing interferes with your work, if something interferes, ask your colleagues for help or information.
3. Start a new feature following the git flow process
4. Take a standard solution-library-platform used in the company (see the appropriate section), if you can not find - coordinate with your senior technical manager to use another solution.
5. If there is a ready-tested code (check the availability of code in the library) - use it
6. Check if any of the developers on the project has written code that can be reused. Avoid duplication of functionality.
7. Write tests for the code and run them
8. Test the implemented task
9. Test functions of the application that may be affected by the work done
10. Document the work
11. Test for performance
12. (if applicable) Check for i18n compliance
13. (if applicable) Check for compliance with A11y
14. Run automatic code check - linter, profiler and so on, correct the code if necessary
15. Delete unnecessary and test data from the code, make sure there are no hard-coded configuration values, keys, and passwords
16. Remove unnecessary git branches.
17. Upload code to GitHub using pull request (PR) mechanisms, designate the technical director responsible for auditing the written code
18. Upload completed tasks to the testing and staging area (if autodeploy is not configured) as agreed upon with the technical director
19. At the end of the day, even if the tasks are not completed, upload all the code to GitHub marked wip (work in progress)
20. Check the task done in the tracker
21. If the deadline is not as expected - mark it and indicate the reason
22. Report the work done, problems encountered, and additional requirements to the project manager and technical supervisor at the end of the day for all the tasks done

Documentation

1. All technical documentation is written EXCLUSIVELY in English.
2. The style of writing should be clear and understandable, avoiding jargon expressions and incorrect abbreviations. For example, the Australian Government’s suggested style for writing documents is https://www.stylemanual.gov.au/changelog.
3. A Changelog should be written for each release, conforming to the standard https://keepachangelog.com/
4. Commits in the git should follow the style https://www.conventionalcommits.org

Additional provisions

1. The code that can be used on other projects must be saved in the archive / source code library. Solutions to non-standard problems found on forums and blogs should be saved there as well (with the source link retained)
2. If part of the project code can be claimed and improved in other projects (including by developers of other companies), an open source project should be released on the company’s account and a senior technical manager should be contacted to promote the repository
3. If some tasks are regularly repeated, it makes sense to use automation tools, for example, to make a template