6

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.

Improve this question
1
  • 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
    Commented Oct 26, 2016 at 17:54

6 Answers 6

Reset to default
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.

Improve this answer
3
  • Anyone out there who wants to add links or other editors, feel free!
    – Adrian Larson ♦
    Commented Oct 26, 2016 at 18:03
  • The Welkin Suite, Visual Studio Code, Brackets
    – o-lexi
    Commented Oct 26, 2016 at 20:16
  • 1
    It's a wiki. Feel free to edit.
    – Adrian Larson ♦
    Commented Oct 26, 2016 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
  • 3
    I disagree there is any "de facto standard" for Salesforce devs. I have seen quite the gamut.
    – Adrian Larson ♦
    Commented Oct 27, 2016 at 1:00
  • For which other source control systems does Salesforce Developer Relations publish a cheat sheet?
    – Thomas Taylor
    Commented Oct 27, 2016 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 ♦
    Commented Oct 27, 2016 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
3
  • 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
    Commented Nov 21, 2017 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
    Commented Nov 22, 2017 at 14:22
  • @DaveHumm yes, I'm sorry, I've corrected
    – Liudmila Likhovid
    Commented Nov 22, 2017 at 18:28

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .