Development Guidelines

= UNDER CONSTRUCTION =

Getting Started

Purpose

This Developer Guide is dedicated to developers working on the e-Mobility project It’ll help you to understand how to implement new features, the coding styles to follow, the design choices we’ve made so far.

Prerequisites

Development environment is setup correctly.

Golden Rules

Find below the golden rules that you have to go through for each PR:

1. Do not stack several big PR in parallel on the same topic (eg. Car, Smart Charging...)
2. Schedule a short technical meeting with me before you start a task
3. Check the logs in production after each deployment and report to me before opening an issue
4. Translate texts and maintain all i18n files + provide english translation for unknown languages (check same number of lines in all files too)
5. Full translation in all languages occurs once a week and is handled by the responsible people (native speakers)
6. Pick up a Small task, fix an Issue, enhance the Unit Tests or perform a QA test in the case you have finished your main task
7. Do not copy/paste the code blindly, understand the purpose of every line of code you use
8. Test each line of your code in the debugger!
9. Code provided in Pull Request must be tested up by a Unit Test (create a new issue)
10. Provide a short test case in your issue when moved to QA pipeline so anyone can test your feature
11. Learn from your mistakes, be proud of them and do not make them again
12. Do not mix implementation of different issues in one PR: 1 PR -> 1 Issue
13. Comment your code if necessary to explain choices that are not self-explanatory
14. Avoid tree of i18n in json doc (chargers.popup.error.title -> chargers.popup_error_title)
15. Each front-end screen should trigger 1 or 2 calls max in the backend to retrieve and display the data
16. Always think big, your code must scale: millions users, charging stations...
17. Develop with production in mind: multiple instances of the same server, limited Memory/CPU, use of Locks...
18. Keep the code readable, simple, self-explanatory (naming of classes/methods/vars) and try to avoid lengthy methods
19. A Class/Method should be done for one and only one purpose (deleteUser() should not create a user, a Car class should contain only ca related method)
20. Follow the logic in place, don't reinvent the weel (Hanlding of HTTP calls, DB access...)
21. The code must be more appealing than the UI which should give the 'wow' moment to the users!
22. Request only the necessary fields from the database (use of MongoDB $project)
23. Maintain the REST endpoint documentation in the open-api-standard.json file when you create/change a REST endpoint
24. Keep both Response Time and Data Volume low in the REST/OCPP/DB endpoints
25. MongoDB requests should be returned by REST service without further data processing (use MongoDB $project)
26. Check your MongoDB requests with the explain() method -> Should use an index
27. Don't forget to move your task to the right pipeline when you have finished your work / requested changes
28. Check authorisation and use canChange...(), canDelete...() to check authorizations instead of isAdmin(), isBasic()
29. Follow the case standard when you create interface, constants... (e.g. interface is Pascal Case: MyInterface, variable in Camel Case: myVar...)
30. Keep your branch or pull request up to date with master-qa on daily basis + retest the merged parts
31. Don't break Angular module dependencies: transactions depends on shared module but never on charging-stations
32. Use only relative path imports in TypeScript
33. Test your implementation with different user's profiles (Basic, Admin, Demo, Site Admin)
34. Check Tenant's component to enable/disable features in the front-end and the backend
35. Maintain your absence in the shared calendar when you plan to be OOO (Charge-Angels holidays)
36. Test the front-end with the debug console opened and check and fix any logged errors
37. When you have finished your implementation run throught the golden rules before creating a PR