When extending OOTB behaviors, it is important to keep upgrades in mind. Always apply customizations in the /apps directory and either overlay on top of the corresponding nodes in the /libs directory or use sling:resourceSuperType to extend the out of the box behavior. While some modifications may be needed to support a new AEM version, the new version should not overwrite your customizations if this practice is followed.
This will allow for the site to maintain a more consistent look and feel and simplify code maintenance. When a new template is needed, make sure to extend from a shared base template so that global requirements such as clientlib inclusion can be coded in one place. When a new component is needed, look for opportunities to extend from an existing component.
By defining which components can be included in each parsys on the page, the consistency of the look/feel of the site can be controlled. By restricting access to the design on pages, “super authors” can be allowed to modify the allowed components per page without developer intervention while ensuring that the other authors follow the corporate standards.
SOLID is an acronym describing five architectural principles that should be adhered to:
Striving for compliance with these five principles should result in a system that has a strict separation of concerns.
SOLID is a commonly-used concept in object-oriented programming and each element is widely discussed in industry literature.
This is just a short summary presented for awareness and you are encouraged to familiarize yourself with these concepts in more depth.
The Robustness Principle states that we should be conservative in what we send, but be liberal in what we accept. In other words, when sending messages to a third party, we should completely conform to specifications, but when receiving messages from a third-party, we should accept non-conforming messages as long as the meaning of the message is clear.
Spikes and test code are an integral part of any Agile software implementation, but we want to make sure that they don’t make their way into our production code base without the appropriate level of oversight. As a result, it is recommended to create spikes in their own module.
Data migration scripts, while production code, are usually only run once at the initial launch of a site. Therefore, as soon as the site is live, this becomes dead code. In order to ensure that we don’t build implementation code that depends on the migration scripts, they should be implemented in their own module. This also allows us to remove and retire this code immediately after launch, eliminating dead code from the system.
Apache has published style conventions at https://maven.apache.org/developers/conventions/code.html. It is best to follow these conventions, as it will make it easier for new resources to come up to speed quickly.