Progressive coding and bug repression

We all live in a world where there is a wrong to every right, a left of right and a right of left. Taking pace in what we do is a very important thing. Taking pace in coding is a great value when a developer possesses such. One step at a time helps to observe more, than act, as actions cannot be (easily) undone.

Virtually all developers now a days engage in progressive coding as long as a source control manager (SCM) is employed. Yet most developers deviate from this style of coding, caused by the wrong use of the SCM.
Here I won't be doing any/much talk on SCM as progressive coding can be achieved without SCM. SCM only makes it easier by doing a little more work.

What is progressive coding

Progressive coding is a coding style in which codes are written bit by bit as they cross level of functions, roles and use.

Let's take a house for instance. A house has to be built progressively not in an instant. In a house there are different compartments, each of which has a function, role and use.
What I'm simply saying can be expressed in a few lines of code.

function buildHouse() {
    const room = buildRooms(4)
    const kitchen = buildKitchen()
    const lib = buildLibrary()
}

function buildRooms(num) {
    const i = 0
    return new Array(num).join("room\n")
}

function buildKitchen() {
    return "chef Chen's kitchen"
}

function buildLibrary() {
    return "Einstein's library"
}

Each compartment is split into its function. With this kind of coding style, as more compartments are needed in the house they can be carefully erected in the house using the buildHouse master function. This style of coding can be said to be progressive coding.
When there is need to change the way in which rooms are built, there is no need to affect the buildHouse function. This style helps a developer keep sanity within theirself and sanitation within their code.

Progressive coding is more like coding in units rather than having a function performing more than one function.
With the illustration above, it may still seem cool to have the body of every other function in the buildHouse function. Trust me, it's not cool when each compartment function begins to do some tedious tasks. A little bug somewhere can deprive you of your sanity; it makes the code difficult to read and debug. In a progressive style of coding, bugs can easily be narrowed down to where they caused a break. A progressive code is very well flexible and can easily adapt to change.

Progressively adding units of functions that perform one bit of major task as and when needed by the programmer is progressive coding

Ways to engage in progressive coding

• Modular development.
• Unit development.

Modular and Unit development are the two lucid ways to code progressively.

Modular Development

Modular development is a system where dissimilar functions work together towards achieving a common goal.
These functions are dissimilar in that they don't behave the same way, but are altogether a part of something larger, and work together to give one result.
In a modular level of development codes are built in environment called modules. Modules can be seen as an intermediate state of an application.
Python, Java, C/C++, Ruby—name it—almost, if not all languages—provide(s) an environment for modular development.
Java class files can be considered to act as modules.
There is a number of environment/runtime/standard that supports modular development in JavaScript. Some of which are:

• Common JS (CJS) e.g node.js
• AMD
• ECMAScript 2015 (ES6 modules)

Modular development is a very important part of programming as it helps organise bulk of codes based on a macro-task the codes altogether perform.
It is easier to build an app as a collection of modules rather than as a single outstretched app.

Unit development

Unit development is building a module from collective bit of functions. Where a module is made up of unit of functions that defines the behavior of that module in the whole application. Building modules in units aid a good testing experience as each test is being done at the unit level.

Unit

A unit is the smallest bit of functional code working a microtask.

Module

A module is a collection of functional units of code.

Package

A package is a collection of functional modules

Bug repression

It is impossible to write a bug free computer code. Since the Adam of Computer Science, the machine had had a bug stuck in it. Now the bug goes down the bloodline through a network of electric wires, and has extended its territory, where it now sits at the heart of computer software development, leveraging the imperfections of man 😉.

We must fight the war against those tiny little bugs as they infest the heart of our designs. They are almost invincible yet we programmers are totally indomitable.

Bugs will surely exist in a code, but efforts must be made to keep activity of bugs controlled. It is a necessary evil in CS.

One thing developers must be careful of is the ineffective way of fixing bugs. During the process of bug fixing, a developer must make sure an imbalance was striken between creating bugs and fixing bugs. An imbalance that tilts right, respectively.
In the process of fixing a bug you may be giving chance to another bug somewhere else. Make sure more bugs are being fixed and less bugs are being created. Progressive coding helps to understand bugs even better, and a simple refactoring will fix more bugs if this coding style is adhered to.

#MakeItClean

(Remember to follow here and on twitter to get the most out of my post. If you like this, please do show it. Got any contributions? Use the comment box. Bye for now)