Code simple, Code right. – simple code, correct code. (Part 2)

To recap from my last post:

Best Practices.

– know how to name the class, its variables, constants, methods…

– know how to comment and not create an explanatory book or not comment on anything

– knowing that the method should only perform one thing in each method

– know that the variables have to be based on the intent of your need

– know that the use of constants should be minimalist and private

– knowing that not only do we have to create the code but that we really care about the coverage of this code.

Another super important point is the separation of points of attention. (SOC – separation of concerns).

Why use declarative mode of code mode.

Oops, but we are developers and we want to code. Developers don’t always code in the Salesforce world!!!

But that’s a conversation for another time.

This point of attention is what separates the impact of your work in an org, what makes it relevant and well structured.

Here we talk about what to do and not how to do it.

For example.

Visual presentation mode.

Declarative – layouts, flow, record type, formulas, reports, dashboards.

Coding – Apex, Visualforce page, lightning component.

What this example tells us, tells us how the developer should know how to choose the best way to build the requested functionality.

In the best way to use what the system provides, in the fastest and most acceptable way of structural architecture.

That’s why I always say that a developer shouldn’t just think like a developer and execute.

We have to have a critical and questioning point, like an architect has.

Thus, the combination of best practices and HOW-TO will transform us into Solution Developers and not requirements deliverers.

Code simple, Code right. – simple code, correct code. (Part 1)

Why talk about this topic?
Simple, because every day we see huge development errors due to the need to deliver quickly and directly.

There is no longer a concern with the quality of the work, but with the speed of it.

And with that we see technical debts grow at an alarming rate, we see customers leave the Salesforce platform saying that it doesn’t work, that it has a lot of problems, that there’s no way to work the way they want and excuses go around.

But is this 100% true? In my opinion and experience, NO!!!

I say yes, about 35% to 40% at most… The rest are development problems and poor consulting performance.

Good, but my focus is on the quality of the code and not on other extra code factors.

When I say good code matters a lot, I mean basic programming principles.
– understandable
– practical maintenance
– does not create fear of breakage in your modification
– scalable and reusable

If we developers focus on delivering code with these characteristics, the amount of technical debt related to code would decrease dramatically.

And how to do it?
Simply using Best Practices.

– know how to name the class, its variables, constants, methods…
– know how to comment and not create an explanatory book or not comment on anything
– knowing that the method should only perform one thing in each method
– know that the variables have to be based on the intent of your need
– know that the use of constants should be minimalist and private
– knowing that not only do we have to create the code but that we really care about the coverage of this code.

We could go a long way here, but these are some of the most basic things we see errors when we access an org and do a technical scan.

Next week I will go into more depth on these best practice points.