The Good, The Bad and the Ugly of Summer ’14 for Developers.

It’s that time of year again. All the good developers and all the good admins eagerly awaiting the end of planned maintenance and the new gifts, er, features, that Salesforce is providing. At 340 pages, the Release notes are a great balance of detail-without-being-boring and I highly encourage everyone to read through them. If, however, you don’t happen to have an adorable screaming infant providing you with extra reading time between 2-4am have no fear; I written up a few highlights. I don’t want to let all the cats out of the bag, but suffice it to say, there’s The Good, The Bad and The Ugly. Without further ado:

The good.

  1. Our leader here, is innoculously described as “Speed Up Queries with the Query Plan Tool” (see Page 241-ff.) In essence, this is the Salesforce equivelent of MySql’s EXPLAIN, PostgreSQL’s EXPLAIN ANALYZE or Oracle’s EXPLAIN PLAN functionality. If you’ve never had the pleasure of arguing with a relational database query written by the intern… well, you may not know about explain. In general these tools all work the same way – prepend any given query with the keyword(s) EXPLAIN and the database will return information about how it will gather the information your looking for instead of the actual query results. Here’s why you need this: You and I both put our pants on one leg at a time, but I’ve writen queries against objects with more than 30 Million records, and I say all our SOQL queries should be reviewed with this explain tool. With this tool we can see which, if any indexes the query optimizer is able to utilize. Here’s how SOQL’s explain works:

[code lang=text]
"plans" : [ {
"cardinality" : 2843473,
"fields" : [ ],
"leadingOperationType" : "TableScan",
"relativeCost" : 1.7425881237364873,
"sobjectCardinality" : 25849751,
"sobjectType" : "Awesome_Sauce__c"
} ]

As they say in the hood, “that there query sucks”. See that “LeadingOperationType” key in the JSON results? TableScan means it has to scan every record. ow. I should really refactor that query so that explain identifies fields it can index off of. With Sumemr’14 there’s a spiffy dev console button to access this information. Wicked.

Other good highlights include:

  1. The ability to override remote object methods
  2. Pricebook Entries in tests. Without “SeeAllData=true”, aka “DISASTERHERE=true”
  3. Un-restricted describes. If you build dyamic UI’s this is indespensible!

The Bad.

  1. There’s an aside on page 191 that bodes ill for many of us. If you’ve ever put Javascript in a home page component, start heeding their warning now. After Summer ’15 no more JS in homepage components. Convert to the new Visualforce component, or suffer the wrath of progress.

The Ugly.

Ok, I can’t really blame Salesforce for this, but the simple fact of the matter is that not all Salesforce devs are created equal. As a Salesforce consultant and developer I have inherited a number of orgs plagued with test classes that execute code, but make no assertions.

As a developer, I understand the importants of testing code, and believe that we should always write useful tests. Additionally, I know Salesforce runs the unit tests in our orgs before every release. Without assertions, however, these test runs tell us only that the code runs, not that it’s functioning properly. While there are rarely, if ever, technological solutions to social problems — like the lack of rigor and professionalism with regard to testing amongst Salesforce developer– I believe it is in the best interest of not only Salesforce Developers but also Salesforce itself, to build a feature allowing administrators to engage an org-wide flag requiring all test methods to call assert methods, with sane protections against such clear abuses as System.Asert(true);

This can only result in better testing, and therefore better code in production, as well as better feedback to Salesforce about the viablity of new API versions.

You should vote for this idea here: