7

A month ago my company asked me to build a small demo of Apex/Visualforce, to proof-of-concept the idea that we could have an interface inside of Salesforce, for the data we make available to 3rd parties as an API. We assumed we would eventually release this as a managed package, via the Salesforce App Exchange.

I started out writing Apex and Visualforce code in my text editor. With my web browser, I would login to my developer account on Salesforce, then open the Developer Console. To move my text to Salesforce, I would copy-and-paste it from the text editor to the forms provided in the Developer Console.

That worked okay when I only had 6 or 7 or 8 files. But now I have 30 files and the number will continue to grow. My project is getting unwieldy.

To keep the files organized, on my own local machine I adopted a directory hierarchy that's been common for years in MVC frameworks such as Ruby On Rails:

app: 
    controllers 
    models 
    views 
tests:

This works locally, but I'm still transferring the text in these files to Salesforce via copy-and-paste.

I know some companies spend millions of dollars to customize Salesforce. I know there are some very large Apex/Visualforce projects out there. How are these typically organized? What tools do developers commonly use to interact with Salesforce.

  • If you're using a IDE, try looking into mavensmate, or use the Force.com Migration tool. Regardless of what tools you use for deployment, your organization will be mostly the same, with each type of metadata in their own folder. – battery.cord Oct 26 '16 at 17:54
12

There are many IDEs that work well for Salesforce development in general, whether you are developing an Apex Class to use as a controller, a Visualforce Page, or any number of other development tasks. Some of the most popular:

Once you select an IDE, the most common files are organized as follows:

  • src
    • classes
    • components
    • pages
    • static resources
    • triggers

These folders correspond to the Metadata API types.


It was only just announced at Dreamforce 2016 and is still a work in progress. However, keep an eye on the Salesforce DX tooling. It will bring a source control driven approach to developing for Salesforce.

  • Anyone out there who wants to add links or other editors, feel free! – Adrian Larson Oct 26 '16 at 18:03
  • The Welkin Suite, Visual Studio Code, Brackets – o-lexi Oct 26 '16 at 20:16
  • 1
    It's a wiki. Feel free to edit. – Adrian Larson Oct 26 '16 at 20:28
4

The Metadata API used in most IDE's for Salesforce and in the Ant tooling has a fixed directory structure that is the natural one to adopt. It divides artefacts up by component type so for example tests and non-test classes are in the same directory; a naming convention such as adding a "Test" suffix to test classes is conventional there.

So I suggest you pick a development tool and use that to pull and push your code and components; it will (almost certainly) use the fixed directory structure. Do also hook up to a version control system too.

For very large projects you can consider dividing the work up into separate managed packages but that introduces a lot of pain so should only be done after careful consideration.

| improve this answer | |
4

Using Salesforce DX and DX packaging (also called Packaging 2.0), you will be able to organize your repository into packages that can be independently installed and upgraded. This means that your source and your orgs will be organized into logical units. This will be the way forward for most developers. You might want to take a look at the Salesforce DX trail for more information.

| improve this answer | |
0

You'll also probably want to use source control. Git is the defacto standard for Salesforce devs, and there are lots of open source/public repositories on Github that can be useful learning tools. I also use GitLab as essentially a backup remote for personal projects since it's free for private repos.

Here's a good thread about using git: Do Salesforce developers use Git? How?

| improve this answer | |
  • 3
    I disagree there is any "de facto standard" for Salesforce devs. I have seen quite the gamut. – Adrian Larson Oct 27 '16 at 1:00
  • For which other source control systems does Salesforce Developer Relations publish a cheat sheet? – Thomas Taylor Oct 27 '16 at 1:06
  • 2
    I didn't know there was one for Git. That said, my first three years on the platform we used Subversion. – Adrian Larson Oct 27 '16 at 1:08
0

The folders are already organized like this

classes
components
pages
static resources
triggers

These folders correspond to the Metadata API types (as stated in the wiki answer)

So all the classes are in the same forlder

classes

In big projects we prefix the class name to organize that

Examples :

  • utility classes always start with UTL_ and so on ...
  • Test classes have the same name that the classes they test with Test appended at the end
  • ...
| improve this answer | |
0

I use JetForcer, it has the best performance. I switched from Illuminated Cloud to JetForcer because IC was slow on larger projects

| improve this answer | |
  • Do you mean Illuminated Cloud by IC -it would be easier to understand if one of the entries was the full name rather than just initials? Thanks – Dave Humm Nov 21 '17 at 14:13
  • What was the perf bottleneck and where? UI or backend? Laminated Cloud has lots of interactive smarts that can slow down older computers. – dzh Nov 22 '17 at 14:22
  • @DaveHumm yes, I'm sorry, I've corrected – Liudmila Likhovid Nov 22 '17 at 18:28

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.