Using custom Salesforce project structure to boost productivity
When I’d just moved from .NET to Salesforce development I was shocked. I opened one of our projects that had been being developed for about 3 years and first thing that I saw was a list of classes with names like “AAAACoreLogic”, “AAATestHelper” and my eyes were like o_O. The purpose and importance of classes is defined by prefix letters and their number in the class name – am I really in 21st century and working with such a progressive thing as Salesforce? This was not the only problem that I’ve experienced (later I opened a Force.com IDE and had a lot of other shocking situations), but this was the most strangest thing for me. I spent the first few days looking for good IDE’s – was thinking that our Salesforce development team was just too lazy to find another IDE which supports this. I guess you understand how wrong I was.
It is pretty clear that SFDC wants us to use “out-of-the-box” functionality or add new logic using a configuration-only approach, while Apex and Visualforce development is treated as an exceptional cases and there shouldn’t be more than some dozens of classes, pages, and triggers. This vision doesn’t match much of what we’re seeing today – there are thousands of SFDC-based projects with hundreds or even thousands of classes, very complicated architecture, and lots of different smaller projects in large organizations. We do not understand how it is possible to work comfortably with at least 30 files in a project which can’t be grouped nicely in folders based on their purpose as well as we don’t understand how it’s possible to keep a highly development performance with tools that don’t care about the needs of developers – this why The Welkin Suite life was started.
Starting from the very first Technical Preview version, The Welkin Suite provided developers an ability to group and structure their code in whatever way they wanted - grouping different types of files in one folder, even including files that are from Static Resources, which may be stored in totally different folders not related to the original Static Resource structure.
Let’s go through some of the ways of how a custom folders structure can help us be more productive while developing for the Salesforce platform.
1. Separating totally different parts of the project
It’s a common situation when a small company starts using Salesforce for only Sales, but later on when they understand the benefits of having all the information about their customers or employees in the same place, it starts adding new areas of logic to the same org – Customer Support, Human Resources, and so on.
If you want to navigate easier in your code you may have to create different projects for the different parts of the functionality in some other IDE or you can just create one project in The Welkin Suite and structure the code in the way that is best for you after you clearly see and understand what stands behind each class, page etc.
However using only this approach won't help with huge projects where each sub-application may consist of hundreds of components and navigating in such projects will still be a pain. This why we recommend using this approach in conjunction with a few other ways of structuring your project which will be described below.
Benefits of such a project structure organization are:
- Significantly reduces the time spent looking for application-specific components
- Once a file is opened, its position in the project structure will be clearly visible in Solution Explorer and it will be clear if it's app-specific or something that's used across the system
Best suited for:
- Huge projects with multiple separate sub-applications
- Projects with lots of region-based code/functionality
- Organizations with public sites/communities, especially when there are multiple sites/communities
2. Grouping feature-related components together
Grouping files by type, as proposed by Salesforce, is good for storing data; but is not great for productive development. This doesn’t make much difference for projects with less than 20-30 components in total, or in situations when a developer is working only on some constant set of components (e.g. ClassA, ClassB, PageC, ObjectD) - they're just always opened in his editor. From the other side if a developer faces a big project, which he's not familiar with, and (to make the example even worse) he needs to find some bug in this big feature - he'll spend a significant amount of time searching for the related components and scrolling through the Solution Explorer when switching between them instead of fixing bug itself.
The best option to make development life easier from my point of view is to group all the related project components together and get rid of type-based grouping just like it has already been done with in most popular development platforms like Java, .NET, and many others. This, as well as some design decisions like using TriggerHandler pattern, will help making the project structure more self-descriptive and will reduce the amount of time that is wasted during on-boarding and development processes. Also having such an option may force a better project design creation according to theSingle Responsibility Principle.
Benefits of such a project structure organization are:
- A self-descriptive project structure, which eliminates the need to maintain documentation, at least for features-related components
- Reduces the amount of time required for project on-boarding for existing projects
- Significantly reduces the amount of time spent on locating files in a project’s structure during development
- Forces Single Responsibility Principle usage in development
Possible showstoppers:
- Very "integrated" project design (e.g. "God Objects" all over the code)
Best suited for:
- Any projects
3. Grouping closely related "functional blocks"
Even if a project is grouped by features, there may still be some parts of functionality that is split in multiple components - the best example of this is a Visualforce page with multiple extensions and a bunch of Static Resources which are related to it.
In order to make life easier it would make sense to store such files all together in a folder. In The Welkin Suite, it is possible to store files from Static Resources in separate folders that are not related to the initial Static Resource's structure (while in the SR itself, they'll be organized as previously), so even if different files from one Static Resource are used by multiple pages or features - they may be located where ever you want without breaking anything.
Benefits of such a project structure organization are:
- Makes the project structure even more descriptive
- Reduces the amount of time wasted while working on closely coupled project components
Best suited for:
- Projects with complicated logic and good technical design
4. Moving tests aside
In some cases, it may make sense to move tests to a separate branch of project hierarchy to make navigation in "useful" code easier - this can be done on all levels of hierarchy and their combinations:
- On a root level - all tests are separated on the highest hierarchy level and may be structured by their own rules
- On any subsequent level - "application" (if any), "feature", "functional block"
Benefits of such a project structure organization are:
- Increases visibility of "useful" code in project structure
- Allows getting rid of "Test" prefix or suffix if needed
Best suited for:
- Any project
Ok, how can this be done?
Check our 'Customizing the Project structure' article in TWS Documentation to find out how a project structure can be easily customized in The Welkin Suite.
Worth mentioning
Unfortunately Salesforce itself doesn't support a customized structure, and there's currently no way to save your great folders structure in SFDC org. This why the project’s structure is stored in the ".sfproj" file, so while you're working with the same The Welkin Suite project you'll get the same structure. If you want to share your structure with other developers - you can share the whole project folder with them. But keep in mind that your credentials (encrypted) are saved in the ".sfproj" file and if you don't want to share them - open it with any text editor and remove your credentials from the XML nodes named Login, Password, and Security Token.
If you're using any version control system like Git or SVN – all of your team will already have the same project structure.
Share your ideas with us
We are currently looking for creative ways to save a project’s structure in Salesforce organizations itself, so all developers will be able to use it, but we are not sure yet where the best place is to store it so it doesn’t bother the other developers or organization administrators. Please let us know what you feel would be the best place in the org to store such info. Drop us some words in the corresponding feature request topic on our forum.
If you have any comments or suggestions of how else custom folders can improve performance - join our discussion and share your thoughts and experience.
If you'd like to read something specific - let us know, and we'll try to write something useful and interesting.
Vladimir Gubanovich
Just FYI, the "Getting Started" link on the "Ok, how can this be done?" section is broken and gets to a 404 page.
Hi Fernando,
Thank you for bringing this to our attention.
I've updated the redirect link to TWS documentation, so now you can find all the information about an ability to customize your project structure.
Have a nice day!
Regards,
Kate