Skip to content

5-b.5-create-developer-guidelines.md

Latest commit

 

History

History
37 lines (32 loc) · 2.6 KB

5-b.5-create-developer-guidelines.md

File metadata and controls

37 lines (32 loc) · 2.6 KB

5-B.5 Create Developer Guidelines

Developer Guidelines should be a document that describes the rules how one specific project should be developed. Those rules will be unique for every project, but below you will find a few recommendations that should be included.

Above all, this should be a living document - continuously updated by the developers throughout the implementation phase, based on the insights and experience gained during development. Adherence to the guidelines will be a lot better, if they include the feedback and consensus of the development team.

For a starting point, the developer guidelines should include:

  • Any rules derived from governance and compliance
  • adherence to #modular-designand #design-principles
  • Recommended patterns, like
  • Validation rules
    • What kind of validation should be performed on the inputs.
    • For example, a backend should never trust the frontend to provide valid inputs. Instead validation must be performed (again) on the backend. Otherwise there might be a threat vector for malicious actors.
  • Error handling
    • how errors should be handled consistently across the application
    • what information is returned via the api
    • what information is to be logged
    • usage of error codes
  • Logging Guidelines, provide guidelines on
    • what information to log
      • It is useful to have a unique identifier (uuid / guid) that groups log messages belonging together. An example would be a correlation id identifying an unique REST request.
      • In addition, it has proven valuable to define a "logging context". The logging context contains information that will always be logged with every message.
    • what log level to use when doing so
    • describe a consistent way of logging error scenarios
  • Design Guidelines for Components, like
    • Separation of Business Code
      • Code that implements business rules should be separated from code that implements technical details (REST communication, Persistence Access)
      • This way the code stays more flexible and is easier to debug & maintain
    • Usage of Layers

      • Layered approaches are helpful to separate the business code from technical code

      • Example: