Development Process
- Requirement gathering and analysis
- Design
- Implementation / Coding
- Early debugging.
- The code stays in the company.
- Developers can learn from each other.
- Teamwork taken to another level.
- Truth is sprout in discussion.
- Testing
- Deployment
- Maintenance
-
Most of code mistakes and discrepancies can be tracked out and fixed at the early stages of development.
One of the common practices in software development is code review conducted within the company. There is
a number of benefits to do it:
Wakatime
One of the core principles of our work is transparency in results and processes. We’ve used multiple tools to establish the company policy of time and progress tracking.
KISS
Nobody in programming loves to debug, maintain, or make changes in complex code. “Keep It Simple,
Stupid (KISS)“ states that most systems work best if they are kept simple rather than making it
complex, so when you are writing code your solution should not be complicated that takes a lot of time
and effort to understand.
If your code is simple then other developers won’t face any problem
understanding the code logic and they can easily proceed further with your code. So always try to
simplify your code using different approaches like breaking a complex problem into smaller chunks or
taking out some unnecessary code you have written.
“Make Simple Tasks Simple!” - Bjarne Stroustrup’s
DRY
The DRY principle is stated as "Every piece of knowledge must have a single, unambiguous, authoritative representation within a system". “Don’t Repeat Yourself (DRY)” principal goal is to reduce the repetition of code. The principle has been formulated by Andy Hunt and Dave Thomas in their book The Pragmatic Programmer.
The opposite of the DRY principle is WET (“write everything twice” or “waste everyone’s time”) which breaks the DRY principle if you are writing the same logic at several places.
To avoid violating the DRY principle, divide your system into pieces. Divide your code and logic into smaller reusable units and use that code by calling it where you want. Don't write lengthy methods, but divide logic and try to use the existing piece in your method.
SOLID
The SOLID principle stands for five principles which are Single responsibility, Open-closed, Liskov substitution, Interface Segregation, and Dependency inversion.
The SOLID principle helps in reducing tight coupling. Tight coupling means a group of classes are highly dependent on one another which you should avoid in your code. Opposite of tight coupling is loose coupling and your code is considered as a good code when it has loosely-coupled classes. Loosely coupled classes minimize changes in your code, helps in making code more reusable, maintainable, flexible and stable.
Law of Demeter
This principle was first introduced by Ian Holland in 1987 at Northeastern University. It is also known as the principle of least knowledge. This principle divides the responsibility between classes or different units and it can be summarized in three points.
- Each unit should have only limited knowledge about other units: only units “closely” related to the current unit.
- Each unit should only talk to its friends; don’t talk to strangers.
- Only talk to your immediate friends.
The Law of Demeter helps in maintaining independent classes and makes your code less coupled which is very important in software development to make your application flexible, stable, maintainable and understandable.