Force.com commandments

I spent a few minutes today thinking about my experiences developing on the Force.com platform. Overall it has been great, nevertheless, there have been some bumps in the road (and there will be more to come).

Here's a list of some commandments that I've come to think of as imperatives for development on Force.com.

NOTE: This is just a list with no particular order of some of what I consider are the most important items.

Thou shall not:

  • Say a class or trigger is ready without having any test units

  • Place a SOQL query inside a for loop

  • Place a DML operation (for a single record) inside a for loop

  • Hardcode an id, object prefix or service instance names... anywhere

  • Create a full sandbox without being damn sure you're ready to create it

  • Say a field is hidden by just removing it from a page layout

  • Assume your test units will magically find data in a new org

  • Assume a 75% coverage is good

  • Ignore asserts in your test units

  • Rely on good percentage coverage of other classes to upload your "I must get this to production right now" code

  • Prefer a trigger over a validation rule (if it can be done through a validation rule)

  • Create a new trigger for an object each time you want to add something new unless you're pretty sure of what you're doing

  • Ignore the undelete event in a trigger

  • Assume a trigger will process a single record

  • Create all of your classes with "without sharing" keyword unless you know what you are doing

  • Leave open queries (without a where clause or limit) unless you know very well your data

  • Ignore the escapeSingleQuoutes function to "clean" user-supplied input in dynamic SOQL

  • Keep list of objects as part of your viewstate ... again ... unless you know what your are doing

  • Create a custom object for saving custom settings

  • Look for a RecordType based on the Name instead of the DeveloperName

  • Ignore the certification maintenance emails

  • Reset a security token without taking in account existing integrations or other people that may be using the token

  • Have a mac and not use SoqlXplorer

  • Use chrome and not use the "Force.com utility belt" and "Force.com Logins" extensions

  • Ask questions like crazy unless you already searched in the discussions boards and found no answer

  • Use accents in profiles or page layouts names (for those that use Spanish)

  • Change the type of a lookup relationship without taking in account any impact on the standard report types and reports that are currently using those report types

  • Suspend a user without thinking about re-assigning ownership of his/her records

  • Ignore declarative changes in production, always keep track of these changes

  • Avoid the use of Security Code Scanner to resolve thy issues -- Cory Cowgill


Amen.

Comments

  1. Lol. Nice list.

    How about: Thou shalt run the Security Code scan and resolve thy issues.

    ReplyDelete
  2. Good one! I'll add it to the list!

    ReplyDelete
  3. Definitely, an oath for any new developer!

    ReplyDelete
  4. Think I will post this on my wall and recite it after I say the pledge of allegiance every morning! I've probably been guilty of more than I will admit to, but now have now excuses. After all, my hand will be on my heart and I will have just pledged my allegiance to God, Country, and Code.

    JoAnn

    ReplyDelete
  5. LOL. Not a bad idea.

    Thanks JoAnn.

    ReplyDelete
  6. Two to go next to "Thou shalt not prefer a trigger over a validation rule":

    1) Thou shalt not prefer a validation rule over a workflow field update (if it can be done through a workflow field update)

    2) Thou shalt not prefer a trigger over a workflow field update (if it can be done through a workflow field update)

    ReplyDelete
  7. Ezra,

    I'm not sure if I understand point 1, how could you replace a field update with a validation rule?

    As for point 2, I agree with you. If your business logic is fair simple then you should avoid triggers at all means. However, we should always be careful with not ending up with a mix of triggers and workflows. They end up messing around with each other and we usually end up adding helper classes to avoid recursion.

    Thanks for your comments!

    ReplyDelete
  8. I'll depend on what you'are doing... but I would also say: "Thou shalt try Dynamic APEX and Partner WSDL first". You'll need to evaluate the cost/benefit of it, but I think is a good idea to keep it in mind on design phase...
    Good post John,

    Angel Abrego

    ReplyDelete
  9. Exactly Angel,

    It depends on what you're doing. I must admit that even though I understand the power of dynamic Apex, having Force.com validate any changes in the metadata that might impact my classes makes me feel "safe". Dynamic Apex can save you a lot of headaches, but I'd think twice before going with this option.

    As for the Partner WSDL, WSC and Tolerado provide a pretty neat way for using the Partner WSDL. I won't think of it as a "commandment" but it's a good recommendation.

    ReplyDelete

Post a Comment

Popular posts from this blog

Force.com object and record level security

almond