Apex Code Development You need to sign in to do that
Don't have an account?
Justin Norris Documenting Your Apex Code - Best Practices?
Hi all,
Our org is leaning on Apex more and more to solve particular problems. Personally I go to code as a last resort since I am a button-click admin and declarative automations are a lot easier for me to maintain, but sometimes it's the only way.
Anyhow, now that we are building up a decent amount of Apex code I want to document this thoroughly.
Both so other people can easily see what has happened, and so that I can easily answer the question,
"do we have any apex code that touches ______"
And just basically so I can keep my house in order.
Anyways, I am wondering if anyone has any best practices, samples, or templates about how you document your code?
In fact, documentation of workflows and anything else would be of interest to, because we don't do any of that right now.
I figured some smart people out there have figured this out before, so why should I reinvent the wheel! :)
Appreciate anything you can share.
Our org is leaning on Apex more and more to solve particular problems. Personally I go to code as a last resort since I am a button-click admin and declarative automations are a lot easier for me to maintain, but sometimes it's the only way.
Anyhow, now that we are building up a decent amount of Apex code I want to document this thoroughly.
Both so other people can easily see what has happened, and so that I can easily answer the question,
"do we have any apex code that touches ______"
And just basically so I can keep my house in order.
Anyways, I am wondering if anyone has any best practices, samples, or templates about how you document your code?
In fact, documentation of workflows and anything else would be of interest to, because we don't do any of that right now.
I figured some smart people out there have figured this out before, so why should I reinvent the wheel! :)
Appreciate anything you can share.
As for documentation of workflows and other things, we make a effort to have every one of our fields documented in our objects (even if it's putting a description of [UNUSED] in them). We've written some internal tooling that displays object data on a angular page so that our external developers know the API names and structure of the objects.
The biggest thing that has helped us as for as organization goes is storing everything in git [4] and having each commit tied to a unit of work either a User Story (from rally) or a Bug (from bugzilla). This way we can look back at the history to see what has been done and who did it. It was a little tough to get our non-developers over to git but it was worth it in the long run.
[1] http://en.wikipedia.org/wiki/Javadoc
[2] https://gitlab.com/StevenWCox/sfapexdoc
[3] http://andyinthecloud.com/2013/02/02/spring-cleaning-apex-code-with-the-tooling-api/
[4] http://blog.deadlypenguin.com/blog/2014/07/21/using-git-with-salesforce-and-distributed-teams/
All Answers
As for documentation of workflows and other things, we make a effort to have every one of our fields documented in our objects (even if it's putting a description of [UNUSED] in them). We've written some internal tooling that displays object data on a angular page so that our external developers know the API names and structure of the objects.
The biggest thing that has helped us as for as organization goes is storing everything in git [4] and having each commit tied to a unit of work either a User Story (from rally) or a Bug (from bugzilla). This way we can look back at the history to see what has been done and who did it. It was a little tough to get our non-developers over to git but it was worth it in the long run.
[1] http://en.wikipedia.org/wiki/Javadoc
[2] https://gitlab.com/StevenWCox/sfapexdoc
[3] http://andyinthecloud.com/2013/02/02/spring-cleaning-apex-code-with-the-tooling-api/
[4] http://blog.deadlypenguin.com/blog/2014/07/21/using-git-with-salesforce-and-distributed-teams/