This folder contains various guides to help those working in software development, both generally and in support of our standards.
- Choosing between a mono repo and a multi repo
- Choosing packages
- Continuous integration
- Developer workflows
- Docker guidance
- Java auto-format with Eclipse
- Kubernetes
- Mobile application guidance
- New starters
- PL/SQL auto-format with TOAD
- SQL Prompt
- Style guide for standards
- Using AWS session manager
- Using unmanaged devices
- Version control guidance
For most developers the primary activity they will carry out is writing code.
This is some general guidance to consider when going about it.
Writing clean and maintainable code is much easier when it's clear which components belong where. The architecture should take into account potential expansion. The SOLID principles provide an example of this approach.
Follow secure coding standards where available to avoid potential security vulnerabilities.
To help the reader understand what is going on, classes, methods, functions, file names and folder names should all be self-explanatory
This may include modern IDEs with plugins that support the developer with capabilities such as pre-defined code snippets, debugging, unit testing, security hints, 'linting', specification checking and annotations.
Understanding code becomes more difficult when different coding styles used by different developers mix and intertwine.
Security issues can arise when one code component incorrectly assumes another has taken responsibility for an action. For example, when validating potentially malicious input at the border of your application. One way to achieve this is to have a comment block at the top of every method or function.
Keep secrets such as passwords and private keys logically isolated from the core code base. This will help prevent them being checked in to public code repositories. Hard coding credentials in source code is bad practice.
Performing effective review becomes more difficult when large changes are made with each commit. Small and clearly labelled commits simplify the review and roll back process.
It should be clear who has authored a code change, and strong authentication controls should be used to do so. It should not be possible to falsify the code's author or its review status.
Encourage a culture that does not accept complicated, confusing or insecure coding practices. Peer review helps prevent such issues being incorporated into your code base. Feedback helps support education within your team. Using pull requests and comments is one way to achieve this.
When multiple team members are working on the same code base, there should be strong and regular communication channels between them. The aim here is to avoid the following scenario: 'I thought you were securing that component!'. Keeping teams physically close to one-another, or providing real-time chat channels are two ways to achieve this.
Clear and concise documentation should support your product. This may be as a result of self-documenting code, code comments, or supportive material. Documentation should be kept up to date, as a system evolves. Old and out-of-date documentation is difficult to trust and could be damaging for security if it's interpreted incorrectly.
Developers and other team members may come and go over the life span of a product. To ensure adequate knowledge of the product is maintained, provide good support and documentation to new team members. After all, who will fix security vulnerabilities left behind by previous developers?
Checking for errors at the point of a call and handling them immediately means that your code doesn't continue running in a potentially unstable state. This will make your code more robust and secure.