Do: * Focus on primary function category first. I divide my naming of assets first by a general category: service, module, terminal, browser. Service denotes s

Do: * Focus on primary function category first. I divide my naming of assets first by a general category: service, module, terminal, browser. Service denotes structures intended for transfer across a network. Module is a poor name to describe a major library artifact such as an object contains methods and properties for a single focused feature set file system or text messaging. Terminal describes lesser resources that live only on the terminal. Browser describes lesser resources that only in the browser. * Document naming conventions by an architect or committee outside the dev teams. Don’t: * Do not associate naming by team or people identify. Doing this erodes reuse between teams and creates broken silos. People come and go but problems with the code will be there forever. * Don’t name things by technology stack. Developers can become religious about particular tools and often that happens because they build tech debt around certain tools they don’t want to escape from. The goal is to deliver a product that solves a problem which in turn generates revenue. Thinking in terms of tools is not thinking in terms of solution delivery. Something I am painfully learning the hard way on a personal project is applying services independently of transmission scheme. For example service data and handling at all end points should work identically regardless of using http, sockets, or something else. Doing, and naming/organization of assets is a major part, can lower processing on transmission related overhead by as much as 33%. That is an amazing performance increase because it is purely incidental to just applying a code reorganization to increase scale and lower maintenance.