Finding a good development partner
Download as PPTX, PDF•0 likes•288 views
The document discusses finding a good development partner. It recommends looking for a partner that has clear coding and testing standards. Specifically, it suggests standards should require single trigger frameworks, 85% or higher test coverage, use of assertions in tests, and comments in the code. It also advises verifying code quality by ensuring tests generate their own data and contain assertions rather than relying on @seeAllData annotations or methods that simply increment variables to fake coverage.
Finding a good development partner
- 1. Finding a good development partner Kevin Poorman Principle Architect @CodeFriar
- 3. Agenda •Why you need a good development partner •Terms and Conditions •What to look for in your partner and in the code •Questions, Comments and Snide Remarks
- 4. Why do you need a good development partner? •Strategy v. Tactics •Code is strategic by nature. •Cost of maintaining code is always the largest expense of a software project. (cf. Code Complete, by Steve McConnell) •In other words, you want a developer who writes code as if the person who ends up maintaining it is a violent psychopath who knows where they live.
- 5. Terms and Conditions •Single Framework Structure •Test Coverage •Assertion •Comments
- 6. Terms and Conditions Single Framework Structure SingleTrigger Calls class method(s) A Calls class method(s) B, C and F Calls class methods X, Y, and A
- 7. Terms and Conditions Single Framework Structure – Why you want this! • This allows you to set the order of operations for your trigger code! • Makes it far easier to test! • Much easier to follow the code down to where a problem may be
- 8. Terms and Conditions Test Coverage 75% 85% 95% Minimum Requirement to deploy Rest easy at night Psychopath never looks up your address
- 9. Terms and Conditions Assertions • Until we have Siri in Salesforce, we can’t just ask if our code is working right. • We use assertions to tell Salesforce what the expected response is • We could, for instance, assert that Dreamforce14 = Awesome when we run code that asks is Dreamforce14 Awesome? • Three Assert methods: • Assert() • AssertEquals() • AssertNotEquals()
- 10. Terms and Conditions Assertions Tests without Assertions are wasted money. You’ve paid someone to write them so you can deploy, but their purpose is to prove the code works as expected. Having tests without asserts is the new buying a picture frame and never replacing the example family photo that came with it.
- 11. Terms and Conditions Comments – what the what? • Comments are how developers leave notes to future psychopaths, admins and anyone else brave enough to venture into the code. • Two flavors of Apex code comments // & /* */
- 12. What to look for in a good development partner Coding Standard: Written document describing how the code will be written: – Good: • Defines what is to be tested, what “dialect” will be used, and what / how code will be commented – Better: • Also describes naming conventions for files, classes and methods • Provides example comment blocks & establishes rules for a single trigger per object, with all trigger logic in classes!! – Best: • Additionally describes code coverage requirements and specifically mentions that tests will include positive, negative and permissions based tests.
- 13. What to look for in a good development partner Testing Standard: Written document describing how the code will be tested: – Good: • Defines a minimum requirement of 80% code coverage. (Why 80%? Because you probably inherited some badly tested code!) – Better: • Also requires that all tests generate their own test data and that no tests use @seeAllData • Enforces no i++ tests • Increases the minimum code coverage requirement to 85% – Best: • Additionally demands that all test methods call at least one Assertion • Requires a minimum code coverage of 90%
- 14. What to look for in a good development partner Trust but verify – Your Coding standard should specify naming conventions for files and classes, and as such you should be able to easily identify your test classes and what they’re testing.
- 15. What to look for in a good development partner Trust but verify – When reviewing test classes, you should read through them, not necessarily for comprehension, but to ensure that they are firing assertions.
- 16. What to look for in a good development partner Trust but verify: SeeAllData will hurt you when you least expect it. – As you can probably imagine, the @seeAllData annotation allows your test to access all the data in the org you’re running the test in. – This is a bad thing. (repeat after me) This is a bad thing! – More often than not, this results in tests *expecting* data to be present in an org. • If the data is only present in one org… the test will fail in other orgs. – Instead, each test should create and insert it’s own records. – Almost never truly needed
- 17. What to look for in a good development partner Trust but verify: Faking Code Coverage – You can fake code coverage. You shouldn’t. You shouldn’t allow the very concept to be floated in your presence. This is generally done by creating a class with a method that consists of nothing but lines incrementing a given variable. Ie: i++; for a long time, follwed by a quick test method asserting that I = 3000; – Tar and feather developers you’ve found who do this. It only serves to foster a false sense of security.
- 18. Comments Test Coverage Single Triggers Test Data Top of Every File 85% or higher aggregate 1 trigger per object All tests generate their own Data! Above every method 85% or higher on all new classes Uses an established Trigger framework Use a TestFactory Class Around any complex logic blocks or apex-shorthand CodeCoverage report card with each code submission Clear and concise comments on how triggers Custom Assertion methods – Assertions.recordDidFailV alidation() You should be capable of reading the comments in the file and following the flow of data Verify coverage in the Developer console. Trigger logic classes are bulk tested Positive, Negative and Permissions based testing. Coding & Testing Standards My opinionated requirements.
- 19. Questions & Answers If you don’t ask questions … I will. Questions & Answers
Editor's Notes
- #4: I’m not here to sell you on a particular development partner I’m here because all too often, as a consultant I’m parachuted into an org and asked to help out in an emergency only to find a righteous mess because good meaning people were asked to hire or find development partners who provided code that “worked” (until now) and was relatively inexpensive. I believe as developers, that we have to be better at our craft, and I want to make sure you hire the right people so that you’re not faced with the kind of 11th hour emergencies that require calling in someone like me. If you know what to look for, I believe you can make a solid business case for a slightly more expensive developer partner that writes more maintainable code.
- #5: Strategy solves long term problems. You win wars and build businesses with strategy. Tactics, on the other hand, are how you solve short-term problems. Tactical solutions to strategic problems are rarely truly solutions and often disastrous in the long run. Code is strategic by nature. Every line of code in your org is likely to out survive your tenure at the company, and will almost certainty outlive your partners engagement with you. Code has to survive automated testing, release upgrades and the inevitable, if un-often deprecation of features. Because it wouldn’t be code if you could do it another way. Because it’s code, because you’re hiring someone to write the code for you, it *must* be maintainable code.
- #7: One of the “best practices” that any org can adopt is the practice of establishing a single trigger per object. For instance a single trigger on Account. The trigger itself contains no logic, it simply exists to fire off a custom class whenever the trigger is fired. The custom class is structured to handle the various contexts like “after insert” and “before delete” and the class method called by the trigger starts off by determining which context to run. Essentially the trigger fires in all actionable contexts and the class handles running the proper code for that context.
- #9: Code coverage the term we use to talk about how well our code is tested. When tests are run, Salesforce knows which bits of code have been executed, and can tell you that 50 out of 100 lines have been executed, giving you an embarrassingly low code coverage of 50% Salesforce demands (rightly) that you have 75% code coverage on all classes, and at least SOME code coverage on your triggers to deploy. But with code coverage, as with steaks, the bigger the better.
- #12: One of the “best practices” that any org can adopt is the practice of establishing a single trigger per object. For instance a single trigger on Account. The trigger itself contains no logic, it simply exists to fire off a custom class whenever the trigger is fired. The custom class is structured to handle the various contexts like “after insert” and “before delete” and the class method called by the trigger starts off by determining which context to run. Essentially the trigger fires in all actionable contexts and the class handles running the proper code for that context.
- #13: First and foremost, you should only hire development partners who have an established coding standard document that you can read, and *understand* before the project begins. You want to be able to provide this documentation to a developer maintaining the code 4, 5 and maybe even 10 years down the road. Don’t loose these, put them in the corporate wiki. Code is understood by contract to not be “complete” until the coding standards are met. This helps ensure your code is consistent!
- #14: The Testing standard, while overlapping a little bit with the coding standard, specifically speaks to how your code will be tested. Remember, Badly written tests are more harmful than badly written code. If you believe your code works because the tests pass, but the tests are bad, then you have been setup to fail. Tests that do not call an assertion method are running the code but not testing it to ensure expected behavior. This meets the requirements for deployment within Salesforce, but doesn’t actually prove the code works as intended. Sometimes, you’ll find code specifically written to fake code coverage. This code should be reported immediately and the offenders Named and Shamed on social media. Or tired and feathered, if that’s still legal in your state.
- #15: The Testing standard, while overlapping a little bit with the coding standard, specifically speaks to how your code will be tested. Remember, Badly written tests are more harmful than badly written code. If you believe your code works because the tests pass, but the tests are bad, then you have been setup to fail. Tests that do not call an assertion method are running the code but not testing it to ensure expected behavior. This meets the requirements for deployment within Salesforce, but doesn’t actually prove the code works as intended. Sometimes, you’ll find code specifically written to fake code coverage. This code should be reported immediately and the offenders Named and Shamed on social media. Or tired and feathered, if that’s still legal in your state.
- #16: The Testing standard, while overlapping a little bit with the coding standard, specifically speaks to how your code will be tested. Remember, Badly written tests are more harmful than badly written code. If you believe your code works because the tests pass, but the tests are bad, then you have been setup to fail. Tests that do not call an assertion method are running the code but not testing it to ensure expected behavior. This meets the requirements for deployment within Salesforce, but doesn’t actually prove the code works as intended. Sometimes, you’ll find code specifically written to fake code coverage. This code should be reported immediately and the offenders Named and Shamed on social media. Or tired and feathered, if that’s still legal in your state.
- #17: SteveMoForce hates multi-select picklists. Al Gore isn’t fond of hanging chads. I hate seeAllData=true. More often than not, when I start working on a project or am asked to help figure out why a changeset or deployment is failing … this is what I find! A test using see all data is looking for a specific account, contact or order to manipulate by it’s ID. This fails because even if the objects are otherwise identical, the ID’s for those objects will not be the same in two different orgs. Yay.
- #18: You don’t want to see classes that do this!