Five Reasons I Do Not Code Well Enough
Possibly, Salesforce triggers an increased number of problems due to its cloud architecture, which imposes a series of limitations to tasks. What is more, according to the StackOverflow statistics, in 2015 the respondents voted for Salesforce to be the most dreaded development technology. Chances are, you have come across a number of articles comparing Salesforce development to most unpleasant phenomena.
Even while trying to bypass such critical judgment -- which is a preferable strategy when trying to contribute to improvement rather than destruction -- it is essential to take a look at the fundamental problems Salesforce developers are faced with, and attempt to generate a solution.
Although in no way does this article attempt to convey its ideas as the ultimate truth, or provide a universal way out of every dead-end situation in development, still, it is aimed at simplifying the developer’s work in regards to some of the most acute problem areas.
Lack of Appropriate Code Assistance Options
Typically, Salesforce developers associate Code Assistance with its three main components:
* Code completion
* Code highlighting
* Methods description
These features simplify and expedite the work with the code for both experienced users, and those who stepped onto the path of development for the first time. Once you become familiar with the Developer Console, you will realize that it features each of these components; however, many have reported that the functionality has an “awkward feel” to it. The case is, whenever some symbol is entered, the console calls the server and then waits for the response with the relevant list of tooltips. This issue is likely to go unnoticed, unless you are faced with a slow Internet connection and an increased server workload. In such a case, you may have to wait a few seconds for the tooltips to appear, which can be both inconvenient and utterly frustrating.
Possible solution:
Being quite simple in its nature, this problem calls for a straightforward solution. Switching to a different Force.com tool will do the trick, and luckily, there are a few alternatives on the market. Unfortunately for many users, most of these tools are plugins (often fee-based) for such renowned IDEs, as Eclipse, Mavensmate or Intellij IDEA. While the reputation of these development giants is unquestionable, purchasing them for Salesforce development only may seem unreasonable for a number of businesses and individual developers. Among the IDEs that focus solely on Force.com coding, The Welkin Suite IDE deserves its portion of the attention, as it can be installed in three clicks, is ready for use out of the box, and it does not require installing a list of plugins, packages and such.
What makes this IDE noteworthy in the context of the aforesaid problem is that its creators implemented all of the discussed Code Assistance components, and extrapolated this functionality to cover HTML, CSS and Javascript. Since no server calls are involved in displaying the tooltips, they appear on your screen without the delays.
The Complexity of Maintaining the Project Documentation
Those, who worked on large/enterprise projects may have discovered that project documentation is essential for understanding the fundamentals of work and becoming integrated into the development process. Either way, newcomers will be consulting more experienced colleagues, and yet profound documentation will diminish the number of cases you will have to resort to external help.
Possible solutions:
* Hire a team of technical writers, who would maintain the documentation. As much as this may sound as a grand solution, there are a few drawbacks. First off, since technical writers need to consult the developers on any updates they make, the latter will be faced with constant distraction. Second, it is not unprecedented that the writers may lack expertise in the field, especially on the peculiarities of development, and thus, let some mistakes slip into the documentation. Furthermore, some businesses may lack resources to hire a team of technical writers.
* Use external solutions, such as Wiki-services, Git, etc. Among the minuses of this approach, the principal flaw relates to the fact that the documentation would still be kept outside of the project. Hence, to navigate this documentation, the developer would have to digress from coding. The same applies to adding and supporting the documentation. Once some changes are made to the method, the developers will have to open the resource with the documentation, find the necessary article and edit it.
* Use an IDE that supports such features as ApexDocs to maintain the documentation directly in the code.
For example, in TWS IDE, once you start typing the multiline comment (/**) above method definition, you will receive a template that is ready to be filled.
Following this strategy, you can avoid unnecessary distractions, while saving some time and effort. Since the description is immediately added to the Code Completion, using the existing code becomes significantly easier, as it follows the DRY (Don’t Repeat Yourself) approach.
Further on, you can proceed with using some external services which go through the project and create technical documentation based on these comments. Naturally, in no way can this be compared to the full-fledged project documentation, and yet such features provide a great option to keep your technical documentation organized.
The Impossibility To Write Code and View Classes Without a Consistent Connection to the Internet
As we said before, many of those who work with the Developer Console have noticed that Code completion tooltips appear with a certain delay. This is reasoned by the fact that after each symbol you type, the console calls the server to receive the list of tooltips. Apart from the fact that this phenomenon is quite irritating, when faced with some problems related to the Internet connection, these tooltips fail to be displayed in the first place. In addition, the console tends to randomly save (i.e. build) the file. In case some errors appeared when saving the file, they will be displayed on the Error panel for a certain amount of time even after you have fixed them. This makes it difficult to define whether the project was saved (built) or not.
The case of having multiple developers working on a single Sandbox deserves separate attention. It often happens so that several developers modify a single file in turns. Ideally, each developer should have a personal Sandbox, and yet most commonly this depends on the customer and their decision. When using the Developer Console, changes made by one developer could replace those of the developer who worked on the Sandbox before. Unfortunately, there is no apparent solution to this problem (unless you have the resources to create a local Salesforce server in your office). Nonetheless, there are ways to safeguard the changes you make, while facilitating the work considerably.
Possible solution:
We suggest searching for an IDE that features some local Code Assistance storage, and demonstrates the build process in the most “loud and clear” manner. With this functionality, some aspect of the collective work is substituted by the Pending Changes notification on the server. This implies that you have to pull the latest file changes from your org first, to be able to merge them with the changes you made via some merge tool (for instance, KDiff3). Certainly, this approach does not address the essence of the problem - it merely provides a pathway around the issue. Even so, you will not have to worry about someone else accidentally erasing your work. Furthermore, by having the entire project on your local workstation, you can keep coding regardless of any problems with the Internet connection, and build your project whenever you deem it necessary.
No Available History for the Changes Made to the Files
Chances are, the situation when you wrote and polished your code, and it fails to work in just a few days, is familiar to many of you. Unquestionably, none of your attempts to find out who has interfered with your code will bring any results, which leads to the endless hours of debugging your code that you have to endure. Only a relatively small number of developers can boast high spirits and enthusiasm upon completion of this process. As much as keeping the history of changes in the cloud to keep track of every action and restore the safe version would be a cure, in reality no such option is available yet.
Possible solution:
While cloud-based history managers are still drafted, you can make full use of Local History functionality, which is featured in some Force.com IDEs. This feature allows saving the history of all changes made, along with the history of pulls from the org. In case some unexpected issues appear, you can compare the previous version with the latest one to localize the reason behind the issue. Alternately, you can brainstorm and find a way to keep the reserve copies of the newest versions in your personal cloud. However, this approach appears unviable since it requires numerous actions to set the process up. Having an “out of the box” solution that does not require a setup is far more user-friendly.
Slow Test Run Processes
Here is a prelude -- a real-life example to back up the idea in this section:
Upon launching test runs, some group of developers had to wait for a week for these tests to be moved from the queue to execution. Surely, they found a way out of the situation and ran the tests another way. As a result, they had to contact the Salesforce Support team to delete these tests from the queue. But a week-long of waiting is an absurd phenomenon for development, which is all about gaining speed, not losing it, let alone stopping entirely.
Even though this case is unprecedented, sadly, it is a common practice for developers to wait 2-3 hours before their tests are ran on a loaded org.
Possible solution:
As it appears, you can send the tests to be executed with the ‘deployment’ attribute, which means they are prioritized. This way, they are rarely queued for more than 2-3 minutes.
Furthermore, your development process will benefit largely if your IDE allows you to run certain test methods and their test classes separately. This feature contributes to Code coverage by allowing you to run a single tests without having to wait for all the others to be executed, the ones you may not even need at the moment.
In conclusion, Salesforce development is full of limitations, bottlenecks and challenges that are inherent of cloud-based architecture. That being said, the human spirit of ‘adapt and overcome’ is spearheading the development of the new tools and solutions to bridge some of the biggest development gaps facing Salesforce developers.
About Our Company
The Welkin Suite is a team of young, enthusiastic and savvy Salesforce engineers, who reached the point of frustration upon discovering that most of the existing Salesforce IDEs seem to hamper the development process instead of boosting it. Thus, we decided to create our own IDE, which would not only continue to accumulate every feature a Salesforce developer may need, but would also ensure a truly pleasant and productive coding experience all in one program.