6 min read7-minute read for SFDX developers and fans.
More than ever before, alignment between business processes and IT infrastructure is vital.
2020 forced companies to make many significant procedural changes, driven by business analysts and implemented by engineers …and not all software was ready.
Change prediction is one of the most important skills in the architect/developer tool kit, and must evolve over time. The best way to predict changes is through combining technical knowledge with our understanding of business, experience, intuition, and sometimes—basic psychology.
There is ample information on techniques and approaches for building flexible solutions. In this blog, “solution” means everything from system, API, database, code, documentation, process, and more. Our main point of focus here is separation.
Making Room for Change
Separating components and code provides us with space for implementing changes to:
- Architectural patterns
- Database normal forms
- Object-oriented programming
- Design patterns
…and many other “golden rules” created by outstanding engineers.
Separation enables simplified change implementation—with fewer errors and less effort—by organizing components in a way that is more understandable for our human brains.
In 1968, Edsger Dijkstra published the famous article “GoTo Statement Considered Harmful” which was the basis for the rule Do Not Use GoTo. Dijkstra’s motivation was to avoid spaghetti code, preferring blocks (separation) to overlapped GoTo code. Spaghetti code refers to a complicated structure with random connections where structured system changes in one place have significant side effects in another. (You never know how long the spaghetti noodle will be or where it connects to the other side.)
Separation principles also help us to organize code and support it. It is not for computers!
Machines prefer code in old Assembler format, with no concern for compiling and execution. We’re the ones who need functions, classes patterns, structures, folders, and more for organization, reducing cognitive complexity, and preventing our own human error.
Let’s talk about folders
When Salesforce introduced apex, they missed a very simple but important feature when they left out folders.
Before you protest, it’s absolutely true that simple folders for documents, images, and files cannot be used for organizing apex code in enterprise projects. (Imagine storing all your photos from a lifetime of special events, vacations, and more in a single folder on your phone or desktop …no thanks.)
But, then again—isn’t that similar to what we do with Salesforce projects? All sales and service cloud customizations, custom application code, and unit tests are stored under “classes” and organized alphabetically. It’s no wonder developers struggle.
For example:
In 2020 we assessed an enterprise client’s platform with a classes folder that contained over 10000 classes and twice that number in metafiles (because every class has two files in Salesforce). When I connected IDE and their cloned repository, scrolling through the folder in source explorer was impossible.
This is a great example of a need for packaging and decoupling. With such projects, library and domain-oriented customizations are unclear.
The good news is that SFDX projects structure supports folders.
Transforming SFDX
During a 2020 Field Service Lightning (FSL) implementation project our experience was very different. Our customization developers were fortunate to work with a very flexible customer who approved SFDX transformation company-wide. Eventually we able to add an “FSL” folder into the repository and create unlocked packages from it.
With the FSL folder, we:
- Separated functionality from other customizations
- Added a self-describing structure to identify reasons for created components
How would a self-documenting structure help you on your project?
Let’s look at a real-world example.
A project has over 1,000 fields on the account, and over 1,000 more on opportunity. Coming in, we don’t know why all were created.
- Are they still in use?
- What can safely be deleted?
- Can any be reused when adding a feature?
In hopes of maintaining some sort of clarity, developers are asked to manually document everything. If documentation is not in sync with actual implementation, it is useless …and this misalignment can happen almost immediately.
The developer wants to deliver faster to meet the deadline. The customer has another business-first priority. After a few missed iterations, the documentation is no longer accurate or useful.
Packaging
Another tool for separation is packaging—which provides a clear picture of what was created and for what purposes. With SFDX, we have had the opportunity to organize our code in unlocked (for enterprise) and second-generation managed packages for independent software vendors (ISVs).
Unlocked packages give us the ability to isolate components with or without a namespace. In practice, this means a simplified release and installation in comparison to deployment and uninstall, or deployment with destructive changes.
Fortunately, you don’t have to stop your current development process to include or make packages from the start as they can be done iteratively. (With org-dependent, unlocked packages this is especially simple.) At the same time, you can still work on sandboxes as before because these development models are compatible.
Transformation: not so painful.
Most customers believe that switching to SFDX requires that you also use scratch org. This simply is not true.
In first phase, grab everything from your sandbox in SFDX format and proceed with development. You can bring scratch orgs later. With a source-driven development model, you should commit your changes into the repository and that is all. The CI system handles the rest, with no need to select what should be deployed to higher environments.
The last year was incredibly challenging for companies that were not prepared for the drastic technological changes that COVID forced on the global marketplace. In the context of global impact (and tragic loss of life), Salesforce Development Experience is clearly not a cure-all.
But while we may like to forget most of 2020, the benefits of SFDX transformation using folders and packages with self-documentation must be leveraged as we press on in 2021.
Let's talk about your SFDX journey and how SoftServe can help you adopt a modernized and more flexible approach.
