A Fresh Start - What would you do differently a second time round?

A few additional things stand out from the retrieved material that may help make a fresh start easier to live with over the next decade:

• Keep using namespaces and databases with clear administrative separation, not just for globals vs routines, but as a broader design principle for maintainability. [1]
• Adopt a meaningful naming convention for environments and database roles, for example distinguishing DEV, QC, UAT, and PRD, and also whether a database is for data or code. [2]
• Consider separating stream data into its own database with global mapping if you store large %Stream properties that are rarely accessed. [2]
• Prefer persistent classes for application data instead of hardcoding direct global access, because that gives you schema, indices, SQL access, and safer long-term maintenance. [3][4]
• Design your global structures clearly up front and avoid ad-hoc key layouts if you do use globals directly. [4]
• Ensure persistent classes have appropriate indexes to support query requirements, and use indexes as part of the initial model design rather than adding them reactively later. [1]
• Make automated tests part of the foundation from day one, using %UnitTest. [1]
• Build in performance verification habits early: use the SQL query optimizer/query plan for SQL, and use tools such as ^PROFILE and ^TRACE to identify bottlenecks. [1]
• Review security at the architecture stage, including resources, roles, and application security, rather than treating it as a later hardening step. [1]
• Keep documentation and code comments maintainable from the start, using UDL or Studio-style comments so future developers can work effectively. [1]
• If you expect scale or distributed growth, evaluate early whether Mirroring, Sharding, or ECP are needed as part of the design. [1]

On your existing list specifically:

• Separating globals and routines is described as still recommended. One reason given is that the global store is a fast-changing database tied to mirroring, journaling, ECP, and sharding concerns, while the routine database should change rarely and be under special control. [2]
• Consistent class naming aligns with the convention that classes use capitalized word starts, for example CountryOrigin. [5]
• Search tables fit with the broader recommendation to ensure persistent classes have appropriate indices and to think about query needs up front. [1]

If I had to condense the strongest additions into a “second time around” checklist, it would be: define naming/environment conventions early, model data with persistent classes and indexes first, separate rarely used stream content if relevant, put testing/performance/security in place from the beginning, and design for operational separation and future scale. [1][2][3][4]

Sources: