Good Software Development Practices For Mobile Engineers

I realized over time that one good reason to have a clean code base is that it helps in creating a roadmap that supports scaling an existing application in the future. It clearly shows that a lot of planning must have been done to give allowance for new incoming modules without unnecessary changes to existing features.

However, bad code does not just happen, it is a sum-up of several factors such as;

• The need to launch a product fast into the market.
• Shortage of engineering members/developers to work on a large scale product.
• Bad engineering practiced established at the base of the team.

Research shows that 59% of developers strongly agreed their companies spend an excessive amount of time dealing with bad codes.

Robert c. Martin, the author of clean code says Of course, bad code can be cleaned up but it is very expensive

Thus, a poorly written application has the following effect on the engineering, business, and administrative team,

On the Engineering team

• This might be a very stressful and crude environment for a junior engineer to learn the right way to build a product.
• Since one of the major challenges that constantly arise with such codebase is the need to fix issues that constantly affect the business negatively, if not well managed; this might put the development team under the constant pressure of output beyond normal in order to make up for unexpected scenarios.
• Scaling up the current system to accommodate new features becomes burdensome as extra effort and time will be needed to restructure a chunk of the codebase to implement even a small feature in order to prevent a break.

On the Business and Administrative Team

• End users’ complaints might keep revolving around the same issues which will eventually have a high impact on the company’s face.
• Due to this drawback which affects scaling the product evenly, a challenge comes with keeping a tab on the competition.

Below are some practices I have learned over time which has, in turn, improved my knowledge as skill in writing a clean and well-structured code:

1. Planning is very important before writing code.
   The planning phase before implementing a feature or building a system that might look very simple is yet a very important stage before writing code. One key importance of this stage is to put in perspective the need to have more features implemented as our application grows bigger. Learning to do research from other developers and interacting with other engineers can help you save a lot of time on writing unnecessary code which will either increase compile time or increase debugging time which is a result of a massive codebase. There are several projects and open source applications that have become unmaintainable because the initiator of such a project did not plan first before beginning to write code.

For example, as an ios engineer, before I implement a new feature I draw out a plan on my notepad, I break my code into modular pieces and create an individual file that controls the core part of my code; This helps me maintain my code since i don’t have to go through several code line to locate a class, variable or method I need to change. Learning to break down the complexity of a feature of an application into smaller pieces helps me manage my codebase more effectively in the future.

2. Learning to handle edge cases (Error handling) optimally.

It is important to optimize applications so well that crashes are reduced to the barest minimum. This is achieved by correctly handling crashes using options carefully. An edge case occurs when an application is pushed to its minimum or maximum limits.

Sometimes we find ourselves in a team caught up with meeting deadlines and we all focus on getting the product out as soon as we can. But, when we do not put edge cases into consideration, the probability of user experience issues coming up may be high. Keeping simple edge cases in consideration helps you return more optimized results and this also handles errors correctly.

Writing unit testing can be a major way to handle edge cases, paying attention to tests makes you think about possible cases that can happen and then write tests about them. They will help you check for anything that may go wrong and then write tests for them. Having a corrective measure as this can prepare you for uncertainties which save time and data.

3. Creating Different methods for different tasks (Single Responsibility).

Writing code that is clean and clear makes it easy to maintain in the long run and this comes with principles that have been tested over time. For example, We know that the model is the heart of an application meaning that one way you can make maintenance simpler is by separating the model from the rest of the application. The single responsibility principle helps in addressing the limitations of components.
A class is the foundation of an application, meaning a class should do only one thing and there should be just one reason to change a certain method. You violate the rule when there is more than one reason to change a method. Having just a reason to change these classes makes them very simple. Just by reading their names, you know what they do. And this eventually makes it easier to fix something when working in a large application. It makes sense When you learn to break down large problems into smaller tasks and then write simple classes to handle each problem.

4. Use the right name conventions for variables and methods.

The focus of every developer should be clarity and simplicity. Making efforts to be both clear and simple should be the goal while making effort not to be simple at the expense of being clear. Some rules that should be followed are:

Using camelCase for Variable names e.g cartItemResult, accountNumber

• Name variables, parameters, and associated types according to their roles, rather than their type constraints.
• It is also important that your methods that are meant to handle an action have a name that is more intuitive.
• Since functions and methods are to execute an action, it is generally advisable they named with action words
• For names that are more than one word, it is generally advised not to use punctuation marks as parts of names or as separators.

In summary, as an engineer, We must constantly strive to write a clean code that is easy to understand while handing it over and not leaving it for other developers that will take it up to clean. We must take up the challenge to make our code as readable and simple as possible to read and go through.

“Our watchword should be making our code easy to read and understood not just by me alone but by other engineers”