Code
Like architecture, code, which in this context refers to both the computer language used to develop a solution and also the tools used to code that language, does not significantly affect many of the practices a software development team could implement. Some development tools offer better support for integration with automated builds, project management tools, and other DevOps processes; and some provide better ability to write unit tests for the code than for others. In addition, the steps to deployment are not the same for some languages, especially when comparing languages that need to be compiled to those that are just non-compiled scripts. While the element of code doesn’t greatly affect most practices, it is the single element about which every other element revolves. The aim of every element is to help construct code to be implemented as part of the solution.
How much custom code do you (you organization or department) have?
- We have none
- We occasionally build some apps in low code/no code
- We have some code in a traditional coding language we occasionally need to modify
- We keep one person busy full time mostly writing code and supporting apps
- We have several developers coding our apps
- We have a team: coders, product owner(s), and maybe even dedicated tester
- We have multiple teams because they work on different products, or loosely related products
- We have many teams working on the same large product
- We have many teams working on many unrelated products
Considerations
- The more custom code you have the more you need to invest in processes and tools for developing and maintaining and testing code along with growth of developer training.
Good Practices
- Readability first
- Small, focused functions
- Consistent naming
- Clear error handling
Anti‑Patterns
- God classes
- Copy‑paste programming
- Hidden side effects
- Overuse of global state