Tristan Hudson, Software Developer at Ribbonfish, reflects on his journey transitioning from working with Microsoft and .NET to Salesforce. 

“Having primarily learnt and worked on .NET and .NET Core projects, recently I have had to adapt and transition to Salesforce. With over 150,000 companies using Salesforce, it was only a matter of time before I would work with the world’s biggest CRM system. Here’s my journey.

The first nuance I already had deep in my mind, before even beginning the transition was moving away from such a hand-holding, great Integrated Development Environment (IDE) like Visual Studio. When accessing the organisation’s code you can either start coding using the in-built developer console, or using their Command Line Interface or CLI which simplifies development and builds automation when working with your Salesforce org, and there are extensions of Visual Studio Code on the Market Place that enable you to use CLI to communicate with Salesforce. I would most definitely recommend the latter. When creating new projects with Visual Studio, we call them “solutions” and each instance of salesforce is an “Org”, but these are just terminology changes to deal with.

Being brand new to a language can be daunting, especially a proprietary language like Apex that one would not have encountered anywhere else in the coding “stratosphere”. However, one of the best resources Salesforce offers for anyone new to the platform is Trailhead. Regardless of whether you are an Administrator or a Developer, Trailhead is a free learning resource to help enhance your knowledge. There are even modules guiding developers who have a .NET background to pick up Apex, the object oriented programming language Salesforce uses to allow developers to execute flow and transaction control statements.

At first glance, syntactically there are a lot of similarities between C# (the programming language on the .NET platform) and Apex. Getting started writing the first few methods and functions was quite simple and trouble-free. Other aspects of Apex and Salesforce in general don’t quite translate with such ease.

I’m a huge fan of using Entity Framework – the object relational mapper (ORM) that allows .NET developers to work with a database and SQL Server as the database as it eliminates the need for most data access code. I’ve used them for all .NET projects I have led. Using LINQ (Language-Integrated Query (LINQ) is the name for a set of technologies based on the integration of query capabilities directly into the C# language) and Lambda (function comprising code, associated dependencies and configuration) means your code can stay relatively clean whilst maintaining it’s easy to read nature.

Salesforce uses Salesforce Object Query Language (SOQL), an adaptation of SQL with many similarities. To interact with data held in Salesforce you use Salesforce’ Data Manipulation Language (DML). Whilst I may be set in my ways, Salesforce’ SOQL and DML are relatively easy to pick up but do come with some obstacles. As Salesforce is a cloud-based multi-tenant platform, developers can not be allowed to make expensive calls to the database “willy-nilly”. This is where limits are enforced to encourage developers to use best practices to ensure their code runs efficiently and doesn’t have detrimental effects on their org. Ensuring all data manipulation language (DML) calls are run on lists of objects, instead of single instances of objects where possible will help avoid these limits being reached.

The most impressive thing I have noticed with Salesforce so far, is how much is available “out of the box” and doesn’t require code to perform. Many layouts and user interfaces can be created using what they call “Clicks over code”. Where in .NET you must create your layout, design your theme and handle all your user’s experience, Salesforce handles this with its Lightning Design System. As of the Summer ’15 release Salesforce also implemented a process builder, which is a point-and-click tool to let users automate business processes. It becomes quickly apparent that Salesforce was designed to allow for heavy configuration without the need of a developer.

Having worked on a few smaller projects, my biggest pet peeve was rapidly becoming the ability to debug my code. Visual Studio’s ability to pause execution and navigate objects to see where values may or may not be getting set is a luxury Salesforce does not replicate. Within your Apex code you are encouraged to use system debug messages, that get output to a log when your code is run. This means numerous lines for numerous outputs, which makes the task of debugging infinitely longer than its .NET counterpart.

The Salesforce platform is more restrictive than that of a custom .NET Solution, but with reason. Salesforce encourages a test-driven development approach and enforces at least 75% of your code to be covered by test classes. This doesn’t eradicate bugs or human error, but does ensure your code is working as you would expect it too before shipping it off to production.

So far, the transition has been challenging, with many pros and cons brought around by having such a better understanding of .NET. However…

The journey continues…”

Tristan Hudson is a Software Developer at Ribbonfish. He is an experienced .NET developer who has designed and developed multiple systems in .NET for clients, including eCommerce solutions and image repositories. Tristan has developed multiple integrations with existing legacy platforms in real time to ensure data accuracy and has worked with Cyber Security teams to ensure that all applications conform to a high level of security standards. Prior to working at Ribbonfish he was System Support Analyst at Macmillan, so has a strong understanding of the publishing sector.

Read about the talented Ribbonfish team and how we work to deliver our clients’ goals here