Skip to main content

Eating an elephant, Breaking Code into tiny bites.

Most people have heard the joke “How do you eat an elephant? One bite at a time.” When programming we often end up biting off huge pieces and trying to shovel them down. We start by building. We are almost always figuring out how to make it work. There is no book that says “If you need to create a sales report here is the code…” The reason is simple, every situation is different. One company might only care about the number of sales in a month. Others might want to track where the sales came from, what interactions led to the sale, the dollar amount, etc. (This later scenario is more likely)
We end up with code that is cluttered, is not very optimized, and just plain ugly.
What are we going to do to fix it?
This is where breaking it into small pieces comes in. In my programming, it is rare for me to have a method that has more than 10 lines of code. Yes, you read that right no more than 10 lines of code PER method. I have had programmers tell me that is impossible. It’s not only possible, it is a fast, efficient way to program.

Here is how I do it.
As I am programming I look for where I can break up code.
  • If I code group I most likely have multiple methods. Many people ask what code grouping is? The simple answer is dividing pieces of code using blank lines.
  • I look for something that does a particular thing. I will have for example a for loop creating a map. Maybe I need to have a map that Maps Line Items to an opportunity. This is its own method. This entire piece would consist of about 4 lines of code. Here is an example of on such piece of code. This creates a set of CreatedById’s that can be used later to query the users.
    set<id> userIds = new set<id> ();
    for (task t :   trigger.new) {   contactIds.add(t.CreatedById );
    }
  • I look for long methods. Any method that looks overly long, probably is.


This process takes a little time to learn, as most things do. In the end, it creates code that is easy to read, and easy to maintain. Overall, I find programming this way speeds up development. I can test small chunks of code. If something doesn’t work I am often looking at 4-8 lines of code, instead of 50-60 lines. I can quickly re-factor a ugly, quickly written, piece of code without effecting the rest of the code.


What tips do you have to speed up programming? Leave your comments and questions below.
Labels:

Comments

Post a Comment

Popular posts from this blog

I don’t test my code and you shouldn’t either.

Wait, what? I am sure about now you are saying something like “Not testing your code is asking for trouble.” Let me clarify, I do not test my code through the UI. It started about a year and a half ago. I was given a task to write a trigger for a client. The only problem was they had hit the data limit in their Salesforce sandbox. While my project manager worked on getting permission to delete records, I had work to get done. How was I going to do it if I couldn’t create records? Then it hit me, I could use test classes to test my code. This one simple thing changed my programming style. I wrote the code, and wrote very robust test classes at the same time. They had to cover everything I could think of. I couldn’t create a record in the Salesforce UI. When it was done, I had very well written code, and my tests were also complete. Fast-forward a week. We had deleted records and freed up space. The client was testing the trigger we had made for them. They came back with “It’s not...
Post a Comment
Read more

How do I learn to program?

The Question This question is asked often. You will see many answers, some even contradict each other. Here are a few I have seen. "It really depends on what your overall goals are." "Start with an easy language like..." "Start with a harder language like..." "Just start" All of these answers have valid reasons, but they do not help someone get started. I see this question come up over and over. I started to wonder how did I learn? How did other people learn? Finding Answers I set out on a journey to find an answers. I started asking programmers questions. The answers I found were fascinating. One question I asked was "How did you learn to program? Where you self taught or did you learn in school?" 90% of the responses said self taught. My first interesting enlightenment. This shouldn't of been such a big surprise. After all I was self taught. My second enlightenment came when I was trying to find a way to...
1 comment
Read more