Understand your code for a new org

Examining your code base can seem daunting. Especially if you’re new to an org or if your org has lots of code. But understanding how the different pieces of your org relate to one another is an essential, necessary part of identifying how to begin managing your org in more precise, meaningful units.

Type of Code	What to look for	Questions to ask
Triggers	1. Trigger patterns 2. Trigger logic	Does your org have one trigger per object? Is there business or application logic written directly in a trigger? Do triggers “hand off” logic or functionality to other classes (aka trigger handlers)?
Apex Classes	1. Naming conventions 2. Comments 3. API Version	Do Apex classes use common prefixes or even namespaces to group units of code? Do classes have similar names, based on functionality? Is the purpose and authorship of code documented in comments? Do classes have comments that help clarify function? What API versions do classes use?
Apex Tests	1. Test patterns/units 2. Code coverage 3. Test data handling	How do tests relate to other code? Does each class have its own test? Are your tests organized into functional groups? Are there parts of your code base not covered by tests? Do your tests depend on common data factories or static resources? Do any of your tests use the 'seeAllData=True' annotation, or run on an API version earlier than 24?
Lightning Components and Events	1. Naming conventions 2. Comments 3. Apex controllers 4. API Version	Do components use common prefixes or even namespaces to create groups? Do components have clear names, related to functionality? Are Lightning events scoped to be application events or component events? Are the purpose and authorship of components and events clearly documented in comments or Aura documentation files? Do components use Apex controllers? What API versions do components and events use?
Visualforce	1. Naming conventions 2. Comments 3. Apex controllers 4. API Version	Do Visualforce pages and components use common prefixes or even namespaces to create groups? Do pages have clear names, related to functionality? Do pages use Apex controllers? What API versions do pages use? Are pages used with any email templates?

These pieces help you identify patterns within the code in your org. But these techniques may not help you understand every piece of your code base. Or, if your code base doesn’t seem to be consistently organized, you may need to try other ways to discover how your org’s code is connected.

This is where the new Dependency API can help.