Recap of Learnings and Tips
Concepts:
- TDD
- Design Pattern - Singleton
- Design Pattern - Abstract Factory
- Design Pattern - Builder (+ Fluent interface)
- Getting over SObject creation restriction through JSON serialization
- Design Pattern - Empty Object (Null Object)
- Design Pattern - Visitor
- Design Pattern - Iterable
Practices:
- DO: Change the Salesforce directories/folders to your liking. The root directory can have whatever name you want and there are not many restrictions after that. Only a few metadata types have restrictions around how to name their parent folder (for example, any LWC must be under an lwc directory, but it does not matter where or how many lwcdirectories you have). For more info around the structure and restriction see: https://developer.salesforce.com/docs/atlas.en-us.sfdx_dev.meta/sfdx_dev/sfdx_dev_source_file_format.htm
- DO: Commit after any meaningful change. I suggest committing after writing any passing test (or after any of your manual tests pass) so that you can always have a way to revert back to a place where the system was working, in case something breaks.
- DO: Use the package.json scripts section to automate any repetitive tasks and scripts. For example, create a script that automates a new environment creation as follows: creates a new scratch org, pushes the source code, assigns any necessary permission sets, and imports data.
- DO: Write unit tests so that they check one use case at a time. Don't be afraid to copy-paste the test setup code and have some repetition around it. This is fine in unit tests as long as everything continues to be short and readable.
- DON'T. Overload methods using flags. Prefer distinct methods with descriptive names instead.
- DO: Refactor early and constantly. Don't let the solution get too complex before refactoring since that will be too much work, and you won't want to do it for fear of breaking something or because of the excuse that "it already works"
