Future work on EnforcerNG
Recommendation: Further work on profiling the enforcement of zones is required!
A decision was taken to re-factor the entire database layer in March 2014. Here are some suggestions for how the re-factor could be done:
- There has been some discussion on the developer list as to why and how the re-factor should be done. It is recommended that design documents are added to this page describing from an architectural basisthis page is used to hold design documents as the re-factor moves forward. It would be helpful from an architectural and knowledge sharing point of view if the following documents were created:
- the architecture of the system immediately prior to the re-factor and the
- the proposed design for the re-factor and the reasons for it
- the actual design after the re-factor
- It is also proposed that a review team of at least 3 developers is involved in the re-factor as it progresses. This is to reduce the risk of
- a single developer making design decisions in isolation
- ending up with a component that is only well understood by a single developer, which is clearly a risk for the project
- sufficient documentation not being produced
- It is recommended that as many regression tests as possible are enabled before the re-factor is done to provide as much automated regression testing as possible
- It is also recommended that the benchmarking tests are improved and re-run as each of the stages of the re-factor are completed to ensure that the previous levels of performance are met or exceeded.