Showing posts with label Apex Naming Conventions. Show all posts
Showing posts with label Apex Naming Conventions. Show all posts

Tuesday, 19 July 2016

Salesforce Platform Developer 2 Programming Assignment Tips

Prerequisites:  

ü  Good understanding on Salesforce Security Model, Object Model, Triggers, Pagination, SOQL, Aggregation, Unit Testing.
ü  Can build solution using Apex & Visualforce

If your answers to above questions are No, Take some time and get some experience on these.

Assignment Tips: 
If you have good exposure to Apex programming, you should be able to complete your basic coding in approximately 20 hours.  Once you are done with coding, you should reserve another 10-15 hours to test your application, review and refine your code and writing unit test coverage.

Design
ü  Check if your solution can incorporate features from recent releases.
ü  Triggers (if any) are modularized, i.e. write the actual logic in some utility class and call that from the trigger. Follow best practice to have just one trigger per object. 
ü  Your triggers (if any) must be able to process bulk data. 
ü  Ensure no recursions in trigger. If there are chances of recursion, you must handle it using static variables.
ü  Exceptions should well have caught and proper message should be displayed to the end user.
ü  If needed, make use of SOQL Aggregate functions, Group By clause etc.
ü  Do not re-invent the wheel, check if Salesforce already provides some api/methods for your logic/computation.
ü  Your code should respect the required security model and no data should be exposed to unauthorized profiles/users.

Coding
ü  You should not be the only person who can understand your code. 
ü  Write proper code comments for each class, trigger and method. Write one liner comment against instance variables stating its purpose. 
ü  Wherever complex logic involved, explain it with code comments so that evaluator can understand it the way you want.
ü  Wherever you have more than one significant design/logic options, mention those. Explain & justify your design approach i.e. which one you are going with and why. Note that you may have 1-2 such instances.
ü  Follow naming conventions. Give proper names to classes, methods and variables.
ü  Consider Indentation to look your code neat and clean.
ü  Remove any dead code, commented out logic etc.

 Testing
ü  Ensure all the functionalists are working as expected, none of the requirement is missed from implementation. 
ü  Consider bulk data testing (if required).
ü  Consider negative testing, create negative test scenarios and ensure no weird results are shown. Test that exceptions scenarios are proper handled and user friendly error message are displayed on the UI.
ü  Ensure you have covered all test scenarios, take some time and think of more test cases, trust me I found one more test scenario in my case which was no where documented in the requirements. But I caught that during testing and immediately added extra piece of code to handle that. Hint: For example if you have some logic on a record deletion, you must consider all the ways in which that record can be deleted and ensure your code handles each of those.
ü  Do not rely on testing done in development Sandbox. Retest everything in the production environment.

Test Class
ü  Many people fail in the programming assignment due to poor Unit Testing. The primary intention of Unit Testing should not be achieving the % of code coverage, rather you should write unit test method to cover all the test scenarios.
ü  Do not write the test cases just for 75% of code coverage, try to achieve 100%.
ü  Create the test data in the test class only. Your test cases should not be depending on org specific data.
ü  Write Test Methods to test bulk data processing.
ü  Write Test Methods to test your automation logic.
ü  Write Test Methods to test Negative scenarios.
ü  Write Test Methods to test all positive scenarios. 
ü  Write test methods to all DML operations your code is handling, for example Insert, Delete, Update etc.
ü  Do not write any test methods for operations not in the scope of assignment. for example, Merge.
ü  Write Test Methods to test data security.
ü  Write assertions for every expected output.
ü  In my assignment, I had 7 Unit test methods and around 70 assertions.

Essay Writing Exam
ü  It's your choice to do it before or after submitting your assignment.
ü  You will have 3-4 questions; each question would be discussing different aspects of your solution.
ü  Each question may further have 2-3 discussion topics and you should manage your time to answer all of these.
ü  If you have done your programming assignment your own, you should be able to answer all of these questions. 
Result
ü  Result would have sent over email 6-8 weeks after the assignment end date.
ü  Result highlights your strong areas and areas of improvements.


Happy Coding !!

Thursday, 12 November 2015

Salesforce Dev Utility Post #2 : Best Practice -- Force.com Development Naming Conventions

If most people don't mind along with the senior developer then you will have very difficult time persuading them all. In this case I would recommend just keep going with the original convention set forth by the original developer and at least keep things consistent.

If other people are not okay with that as well then you can focus on the ROI of converting already existing project naming convention to language naming convention and present that to the management along with the senior developer. This will most certainly cause some friction.
In conclusion, I would say that language naming conventions are very important because new people coming into your project are more comfortable with the code-base requiring less explanation and causing less friction.

The reason being that language naming conventions are global and project naming conventions are local so people would need more time getting used to it.

As new developers are getting used to the project naming conventions they are bound to mix it up with language naming conventions if that's what they were used to. Code reviews could solve this issue but it is an unpleasant element of going with the project naming conventions nevertheless.

Hence, from that perspective language naming conventions are more important than project naming conventions.

Follow the CamelCase Java conventions, except for VF pages and components start with a lower case letter.

Triggers:
  • § <ObjectName>Trigger - The trigger itself. One per object.
  • §  <ObjectName>TriggerHandler - Class that handles all functionality of the trigger
  • §  <ObjectName>TriggerTest

Controllers:
  • §  <ClassName>Controller
  • §  <ClassName>ControllerExt
  • §  <ClassName>ControllerTest
  • §  <ClassName>ControllerExtTest

Classes:
  • §  <ClassName>
  • §  <ClassName>Test (These might be Util classes or Service classes or something else).

Visualforce pages and components:
  • §  <ControllerClassName>[optionalDescription] (without the suffix Controller). There might be multiple views so could also have an extra description suffix.


Object Names and custom Fields:
  • §  Upper_Case_With_Underscores

Variables/properties/methods in Apex:
  • §  camelCaseLikeJava - more easily differentiated from fields

Test methods in test classes
  • §  test<methodOrFunctionalityUnderTest><ShortTestCaseDesc> - For example, testSaveOpportunityRequiredFieldsMissing, testSaveOpportunityRequiredFieldsPresent, etc.

Working on something that would be used as an app or in some cases just a project? If yes, then do the following:

Prefix all custom objects, apex classes, Visualforce pages and components with an abbreviation so that they are easier to identify (e.g., easier for changesets). For example the WidgetFactory app would have the prefix wf on those. Additionally, when adding custom fields to a standard object they would also be prefixed to identify them as part of the app/package.


The main reason for the Object and Fields Names using Upper_Case_With_Underscores is that when you type in the name field or object with spaces it automatically adds the underscores. Although Apex is case insensitive, always refer to the Objects and Custom Fields in the code as Upper_Case_With_Underscores as well for consistency all around and consistency with what is generated by the SOQL schema browser and other tools. Object and Field Labels (which are generally ignored by code but visible to users) should keep spaces, not underscores.

"Happy Coding"