Search This Blog

Do you know how to write the code that survives the test of time

“You have to be burning with an idea, or a problem, or a wrong that you want to right. If you’re not passionate enough from the start, you’ll never stick it out.” — Steve Jobs

Just like the paintings of Jackson Pollock, a Salesforce Developer is an abstract concept. Therefore, it is prudent for me to confirm the audience for this post. To put it very simply, if you write code, this is for you. If you do clicks and not code, this article will mean nothing to you.

With that out of the way, let's dig in. Salesforce is one of the hottest skills on the market and more and more people are moving towards the technology. It is wonderful to see new batch of developers, engineers getting into salesforce. In the last six months, I came across two instances, the first one, they had a lot of redundant code and the system was sluggish, slow and governor limits were flying off the charts. The second one had given up. They spun a brand new environment and we redoing the whole thing.

Both the instances is not a healthy scope for a project and if you have to reinvest into the whole thing every few years, you are doing something wrong. So if you are a developer who have just started writing code, you should follow this list.

1. Don't create too many relationships

The customer wants reports about a primary contact associated with an account. Let me go and quickly create a lookup on account to the contact. DON'T. (very specific example!). The more lookups and master-details you create, the more convoluted your organisation will become. At some point, your objects will be so entangled that finding where the main record (or master record) in Salesforce resides will be a challenge. We live in a multi-tenant architecture, having too many relationships to the same object will completely fork your implementation.

I'll refer to these blog posts for more information,
The world is flat- design principles for data modeling

Image result for triggers in salesforce"

2. Don't just write triggers, think!

Triggers are the original sin on Salesforce. The little bits of code, mostly harmless, that majority of time gives you the too many SOQL, or too many DML or the most coveted, heap space allocation.
If you are going to write the first trigger in your organisation, you have to think about the one after that and the one after that and so on.
Why? Because triggers will always trigger other triggers and those triggers will trigger more triggers. Read that again.
Over the period of time, triggers increase the technical debt and it is useful if you can set up some design principles before-hand.
There are many trigger design patterns in the community, you can choose one.

Image result for code comments funny"

3. Your code should have comments

This is more worrying trend that I have observed recently. Code that does not have comment is a garbage code. Your code should start with a proper class header, describing why in the godforsaken world have you decided to write the class. What is its purpose and why is it useful.
Many developers fail to do this, assuming, they will be there if things go wrong. But remember time is not kind to people who do not change. Humans will move on. Code remains. And the next developer that looks at your code that lacked comments will belch at it.

4. Always find time to learn new things

Salesforce is a evolving technology. They have conquered the market by evolving faster than their competition. Salesforce keeps adding new things and improving its interface. As a developer, you have to learn them all- the clouds, the configuration. You cannot just stick to the code because that's what you do. There will always be a better way to solve a problem. And you have to learn about it.

5. Always improve your problem solving skills 

Good developers stick to what they know. Good engineers solve problems better. A few years ago, we had ajax controls on visualforce. One of them was actionfunction. You declare an action function and you can then call that in any Java code


<!-- Page: -->
<apex:page controller="exampleCon">
<apex:form>
<!-- Define the JavaScript function sayHello-->
<apex:actionFunction name="sayHello" action="{!sayHello}" rerender="out" status="myStatus"/>
</apex:form>
<apex:outputPanel id="out">
<apex:outputText value="Hello "/>
<apex:actionStatus startText="requesting..." id="myStatus">
<apex:facet name="stop">{!username}</apex:facet>
</apex:actionStatus>
</apex:outputPanel>
<!-- Call the sayHello JavaScript function using a script element-->
<script>window.setTimeout(sayHello,2000)</script>
<p><apex:outputText value="Clicked? {!state}" id="showstate" /></p>
<!-- Add the onclick event listener to a panel. When clicked, the panel triggers
the methodOneInJavascript actionFunction with a param -->
<apex:outputPanel onclick="methodOneInJavascript('Yes!')" styleClass="btn">
Click Me
</apex:outputPanel>
<apex:form>
<apex:actionFunction action="{!methodOne}" name="methodOneInJavascript" rerender="showstate">
<apex:param name="firstParam" assignTo="{!state}" value="" />
</apex:actionFunction>
</apex:form>
</apex:page>


This method was considered the best method, until visualforce remoting came in picture. Now actionfunction is heavy, submits a form and is not realtime.

<script type="text/javascript">

    Visualforce.remoting.timeout = 120000; // Set timeout at page level

    function getRemoteAccount() {
        var accountName = document.getElementById('acctSearch').value;

        // This remoting call will use the page's timeout value
        Visualforce.remoting.Manager.invokeAction(
            '{!$RemoteAction.AccountRemoter.getAccount}',
            accountName, 
            handleResult
        );
    }

    function handleResult(result, event) { ... }
</script>

In Salesforce there are always multiple ways of doing a particular thing. The difference between an ordinary programmer and the engineer is the ability to find the best possible fit. And when you do that your code will scale and survive the test of time.

6. Be hacker first

Hacker is a term that has got a negative connotation. I can hear the hair on the arms of many information security officers raise in goosebumps as you read this. But hear me out. This does mean you try to figure out a way to break the system (or if you do, be nice to tell the system admin how to plug it), or you typing on loud music in some horrible cubic text that they did in swordfish.
Hacker is someone who is relentless in finding solutions. Don't let technology defeat you. Lightning, Apex. Java or any other language that gets thrown in your path, figure out a way to work with it. Have seen so many developers get defeated with Javascript!
Don't let that be you.

So there you have, my tips to let your code survive the test of time... What do you think about it? What is your best tip to write the best code ever? 

Let me know.

Sforce.Ninja

Comments