Surprisingly I had a long list of mistakes, and I wasn't doing anything about it. So I decided to write this post to attempt on reducing these mistakes.
I believe in learning from mistakes, thus I challenge all my readers to list down their mistakes and leave them in comments below. Remember no one is perfect, so don't be shy and leave comment.
1. Using InvokeServiceMethod in calculated fields.
This is biggest performance degrader.I regret this one the most, I used this trick to calculate an status of opportunity and it turned out to be biggest technical debt of all time. No one want to fix it now and it is stuck there churning away time, memory and CPU every time it is referred.
2. Not checking CountRecords() Or FirstRecord() before get field value.
This is one of my most frequent mistake in Siebel. It goes unnoticed because the logic works for mostly all scenarios but one, what if there are no records retrieved from query? Siebel is going to throw it back to you, logic won't proceed and service will halt making you accountable.
So please don't be a Jim and always check for record count or First Record before proceeding.
3. No comments
Leaving no comments on blog post is ok, but leaving no comments in script is a big no no. Have your ever noticed how much easy it becomes if there is one of two line of comments in script? just one or two line makes it so convenient for developer to understand the code without going into details.
My self plead guilty of committing this some time.
If I have to create a standard I will try to use following template for comments:
/*
[jim] [25 Dec 2015] [ added code for xxxxx reason, code is invoked from xxxxx places]
*/
simple isn't it? Please share in comments below what type of comments you use.
3. Not nullifying objects after use.
Developers believe that ST script engine will clear up memory for them. But no memory leaks are real still in Siebel 8. So please Jim don't make that mistake again.
4. Try catch finally block
This is the only way for keeping some dignity, and we still avoid it to save time. Do you also make that mistake?
5. Using profile attributes.
They work like magic in some scenarios, but it is so difficult to trace them back, and using it in Open UI is like calling Mayhem. Please share your thoughts on this. How do you trace back the creation of profile attributes?
Please don't forget to leave your list of mistakes in comment below.
A nice read Jim. Thanks for sharing the list.
ReplyDeleteLeaving no comments is very frequent - we use following format for comments
Priyana - 25012016 - Project ID/Name - reason for code implementation
Other mistakes which I keep making are using profile attributes, and its true that they are very difficult to track back.
One additional is - not populating process name property in Workflow so when it ends up in error or exception we can not identify from the logs like which WF has the problem, this one is a very common mistake in my team!!
Glad you like it Priyanka,
DeleteIt is important to know your mistakes, before we can try to correct them. I have actually started adding comments after writing this post. :)