Skip to content

Development Guidelines

Jump to bottom
FABIANO Serge edited this page Jan 31, 2022 · 34 revisions

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 which will depend on each others
  2. Schedule a short technical meeting with me before starting a new big task
  3. Check the error logs in production at least once a week and after each deployment; Report me the issues you found
  4. Translate texts and maintain all i18n files + provide english translation for unknown languages
  5. i18n translation occurs once a week and is handled by the responsible people (native speakers)
  6. After a big task, if you wait for a PR code review, pick up a new small task or fix an existing issue or enhance the Unit Tests / documentation or check the error logs in production
  7. Do not copy/paste the code blindly, understand the purpose of every line of code you reuse
  8. Test every line of a complex code in the debugger! Never think that it will 100% work in production!!!
  9. Code provided in Pull Request and bug fixes must be tested and backed up by a Unit Test
  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 block of code that are not self-explanatory to help code reviewers understand the purpose of it
  14. Avoid tree of i18n in json doc (wrong: chargers.popup.error.title, right: 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 of users, charging stations...
  17. Develop with production in mind: multiple instances of the same server, limited Memory/CPU, use of Locks to synchronise tasks...
  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
  20. Follow the logic in place, don't reinvent the wheel (Handling of HTTP calls, DB requests...)
  21. The code must be as beautiful as the UI and both should seek for the 'WOW' effect from the end-users!
  22. Request only the necessary fields from the database (use of MongoDB $project statement), same for REST endpoint
  23. Maintain the REST endpoint documentation in the open-api-standard.json file when you 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
  26. Check your MongoDB requests with the explain() method -> Should use an index on big collections
  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 standard case when you create interface, constants... (Pascal Case: MyInterface, Camel Case: myVar...)
  30. Keep your branch or pull request up to date with master-qa on daily basis + retest the conflicted 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 and provide Unit Tests with the different User's roles (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/fix any errors/warnings showing up
  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 local 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 a corresponding issue in GitHub
  44. Opened conversation 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 applied (performance issues); Only filters are allowed before sort/limit
  46. Use decimal.js lib to manipulate any numbers that will be persisted; Check Utils.createDecimal()
  47. Keep in sync the common application types from ev-server to ev-dashboard and ev-mobile (ServerAction, Authorizations...)
  48. Whenever the REST endpoint is changed, update the e-mobility-oas.json file (used by Swagger)
  49. Do not check error messages returned with the REST endpoint but only HTTP code, same in the Unit Tests
  50. For any new REST endpoint, use the new routing framework (cf. GlobalRouter)
  51. Validate all your HTTP requests with a JSon schema (sanitisation, type and structure checking)
  52. Try to always update partial data of an object in MongoDB: create a new saveXXX() method (eg. ocpiData, billingData in Transaction)
  53. Do not expose sensitive data in GitHub issues (user name, email...) - Blur your screenshots
  54. Every Asana task should be linked to a GitHub issue you started (copy the GitHub issue link into the Asana task)
  55. Draft Pull Request has to be put in 'Dev cross-review' pipeline
  56. Avoid heavy data processing in NodeJs to not kill the event loop
  57. Understand the merge of the Git conflicts of your PR after a sync with master-qa and do not merge blindly
  58. Check your GitHub and Asana tasks once a week and update/close them
  59. Check the performances of your latest development with perf logs in the console or with Clinic Doctor, BubbleProf and Flame (cf. Wiki)
  60. Unit Tests should always be reentrant: should be run several times with the same outcome without recreating the context
  61. Do not apply eslint rules on your PR, this can introduce too many changes. Create a new PR dedicated for this.
  62. When you add a constraint in the UI, this has also to be enforced in the backend
  63. Do not stack a potential technical debt when you can solve it in few hours or a day: simply fix it!
  64. Check for circular dependencies in the backend with the command 'npm run build:dev'
  65. Method signature should always have the mandatory parameters it needs to accomplish its purpose
  66. Learn by heart the FABIANO's Golden rules
Clone this wiki locally