Force.com commandments - Part II

Wow, every day we learn something new so It seems like I'll never run out of material for my list of commandments!

Here's the continuation of my previous list, it's important to point out that some of these might not be valid for future releases but people should be careful for now when dealing with some of the current limits. So here we go...

Thou shall not:

  • Assume that standard objects in destination orgs don't have any validation rules/trigger logic that will cause your package's test units to fail, place your catch blocks and take actions accordingly

  • Assume your custom settings will be initialized when running test units in a destination org , make sure you validate null values or set the values for custom settings

  • Give end-users credentials to test your app and go on vacation leaving the user wondering what the heck is a verification code. Make sure you change the f$!@#%^ email address!

  • Leave out apex:pageMessages component from your VF page to display any errors (unless your page is used for other purposes)

  • Forget to add a status indicator in your VF pages when doing async stuff

  • Forget to test and probably fix the behavior of the "enter" key in custom VF pages

  • Expect cascading delete operations to execute trigger evaluations on those records that did not initiated the delete operation

  • Forget to use Test.startTest() and Test.stopTest() methods inside test units

  • Assume that you can run a report on humongous amount of data, make sure you plan your report filters and create external ids (indexes) accordingly

  • Assume you can use a Long Text area field in a formula field or SOQL where clause

  • Assume that Force.com can handle all type of attachments , there's a limit of 5 MB!

  • Leave the endpoint for a WSDL to Apex generated class (or any endpoint value) as a hardcoded value, make sure it can be changed through custom settings

  • Create a VF page just to show an image, use IMAGE in formula fields!

  • Ignore revoked tokens scenarios when using OAUTH

  • Use Contacts without Accounts, these are always private regardless of your organization's sharing model

  • Forget that text names for custom objects have a max length of 80 characters

  • Forget there's a data loader built into salesforce

  • Ignore the use LogLevel for debug statements

  • Create tabs for objects that don't really need a tab

  • Assume auto-numbers will always be sequential, numbers will keep increasing but data creation in test units will break the sequence

  • Forget that once a master relationship has been established it CANNOT be changed

  • Create public utility classes for test data creation without the @isTest annotation (Winter 12)

  • Pretend that no one is using the production org while you're doing your deployments

  • Forget that a profile is tied to a type of license

  • Forget you can actually know the total number of records for specific objects just by going to Setup>Data Management>Storage Usage

  • Create a ton of single static resource for your VF pages, use a damn zip file

  • Assume SF to SF will copy all of your lookup relationships

  • Miss new platform releases webinars or not visit http://blog.sforce.com

  • Fall for jeff douglas blog phantom results in Google... but you'll probably will anyway...


Amen.

Comments

Popular posts from this blog

Force.com commandments

Force.com object and record level security

almond