Development Guidelines

Golden Rules

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

1. Do not stack several PRs in parallel on the same topic or depending on each others
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. Check if the front-end adapts correctly to the giant iPad resolution (1063 x 1546) that we have at SAP Mougins entrance
38. Do not write anything on the disk
39. Do not use methods in Angular HTML template expect for event handling
40. Avoid mixing several statements in one line (break it down into several to ensure readability)
41. Keep your PR as small as possible. Split into several ones if necessary.
42. When new open source is added to the package.json, check the license which should not be restrictive (MIT...)
43. Always link your pull request to its corresponding issue in GitHub
44. Conversation opened in GitHub during a code review can be only closed by the person who created it
45. Avoid doing lookups (join) in storage classes before sort/limit is processed (performances), only filters are allowed
46. Use decimal.js lib to manipulate floats that will be persisted: Utils.createDecimal(meterValueWh).minus(lastConsumption.value).toNumber()
47. Keep in sync the types from ev-server to ev-dashboard and ev-mobile
48. Use the new RESTful endpoint for new backend API
49. Whenever the REST endpoint is changed, update the e-mobility-oas.json file (used by Swagger)
50. Do not check error messages returned with the REST endpoint but only HTTP code
51. For any new REST endpoint, use the new routing framework (cf. GlobalRouter) and validate your HTTP requests with JSon schemas
52. If you need to update partial data of an object in MongoDB, create a new saveXXX() method to update that data
53. Do not expose sensitive data in GitHub issues (user name, email...) - Blur your screenshot
54. Every GitHub issue should be linked to an Asana task (copy the GitHub issue link into the task) and properly assigned and tagged
55. When you have finished your implementation run through the golden rules before creating a PR