Skip to main content

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
Labels:

Comments

Post a Comment

Popular Post

The unofficial guide to become a Certified Salesforce Administrator (ADM 201)

In my attempt at maximum certifications in 60 days, I completed Salesforce Certified Administrator exam on February 11th 2013 So you have decided to ramp up your career and take certifications in your hand. Good choice. It is also likely that this is the first time you have heard of Salesforce, certification and since your company has a vision of you completing the certification you have decided to do it. At this stage it is likely that, You have done extensive googling. You have received countless brain-dumps. And you have received plenty of advise from different types of users which ranges from Admin certification is easier than making coffee to Admin certification is tougher than building a rocket-ship to fly off to the moon. The purpose of this guide is to give you a clear understanding of what to expect when you are expected to become Certified Salesforce Administrator. To bring sense to all the things you have seen so far and to clearly explain what to do and what
72 comments
Read more

Some PDF tricks on Visualforce: Landscape, A4, page number and more

The beauty of Visualforce is simplicity. Remember the shock you received when you were told the entire page renders as PDF if you just add renderAs=PDF to the Page tag. For those who thought I spoke alien language right now, here is the trick, to render a page as PDF, we add a simple attribute to the <apex: page> tag <apex: page renderAs='pdf'> This will render the entire page as PDF. Now, say we need to add some extra features to the PDF. Like a page number in the footer or we need to render the page in landscape mode. Faced with this problem, I put on my Indiana Jones hat and went hunting for it in the vast hay-sack of the internet (read: googled extensively). Imagine my happiness when i found a big big page with many big big examples to solve the problem. The document I am referring to is from W3C, paged Box media . Long story short, I now possess the ultimate secret of rendering the page in any format I want. So here are few tricks I learned from the p
17 comments
Read more

The Basics of writing a Apex Trigger

One of the most important and common asked question on Forums and everywhere is how do I write a trigger. Coding in Apex Trigger is like going to a dentist for a root canal, you keep dreading the moment until you realize it is actually not going to hurt you. If you plan to write an Apex Trigger this quick guide will help you doing so. The first and foremost rule in writing a trigger is to remember the oldest suggestion given to the most comprehensive Hitchhikers Guide to Galaxy, ' Don't Panic. ' Writing a trigger is not a rocket science, in-fact we should thank the team at Salesforce and ForceDotCom for making everything so simple, that anyone can do it. Enough of talk, lets code. So you want to write a trigger. Let us have a glimpse of what we are going to build. The problem statement is as follows Problem:  When the User is entering the Opportunity, check for the Opportunity Amount. If the Opportunity Amount is greater than 50,000. Mark the Parent Account as
21 comments
Read more