Best Engineering Principles

Best Engineering Principles

                                                In this article  we will try to understand the Best Engineering practices while developing or building the high class products. In this post, I’ll be introducing a details about what I have learnt in my past year of professional software development career.

•  Idea behind following the best practice during the Start or initiation of project/product cycle is         importance because any product can not be developed or enhanced in a days or weeks , it takes     good amount of effort and time cycle .
• To avoid any bottleneck obstacles at the end of product cycle we must follow certain principles         during the initial phase of our work.
• I will walk you through what all important and key factors to consider along with good design and     architecture of the system.
• Any developers and  team stack holders should or must follow these principles to adhere the best    engineering practices.

What are the symptoms of software development problems?

• Poor software quality
• Unacceptable software performance
• Software that is hard to maintain or extend
• Inaccurate understanding of end user needs
• Inability to deal with changing requirements
• Late discovery of serious project flaws

Why should I learn these principles ?

                            These principles are set of guidelines which help you write better, robust and                 clean code.Once, you start applying them, you’ll start seeing the results on the overall                     process of developing products. Here are some advantages which will be visible in your                code.

• Clean Code
• Robustness
• Efficiency
• Delivering high quality softwares
• Flexible, Easy to refactor
• Maintainability
• Scalability
• Modularity

As i keep believe that "everybody can write a code but better code is hard to write" and to write better code, required lots of practices and understanding about these principles.

Let's divide these principles in following areas understand and segregate based on their usages and scope.

1. General Principles

The KISS Principles

• This KISS abbreviation stands for “keep it simple, stupid” in the world of software development. It’s also known as “keep it simple and straightforward,” or “keep it simple, silly,” or whatever s’s you want to insert here.
• The idea behind 
• it is never-changing, 
• though. You should keep your code as simple as possible. But what does “simple” mean here? It’s always a good idea to pick up meanings in a dictionary. 
• For instance, according to The Free Dictionary, the word simple means having fewer parts or features, not complicated or elaborate. The definition perfectly suits engineering. Whenever you can avoid code, do avoid it.
• A simple code is good for maintainability because 

• you make it meaningful, 
• simple, and straightforward. 
• It means that you can always go back and see what’s going on. Thus, you can easily debug it and move on to your next task. 
• Besides, with the help of this principle, you could help outsiders read your code and refactor it (in case you are not working on that code anymore). 
• So, do learn the KISS principle and apply it in your work.

The YAGNI Principles

•  Another acronym that’s popular among software engineers, YAGNI means “You Aren’t Gonna        Need It”. This principle focuses on eliminating any unnecessary coding and works in tandem             with the KISS principle.
• Instinctively, meticulous engineers start by planning and listing everything that ‘might be used’ during the project. However, sometimes they end up with components that are never used.
• So it’s always a good idea to avoid coding something that you don’t need “right now.” You can always add it later if circumstances change.
• In short what you think might come in handy and be useful sooner or later, probably will never be used.

The DRY Principles

• DRY stands for“don’t repeat yourself,” and its underlying idea is that you have to avoid and reduce repetitions and redundancy by replacing those with abstractions or utilising data normalisation. 
• For example, pseudocode is an excellent way to make sure you aren’t making any repetitions. 
• You might be duplicating a bit of logic here or there, but you may want to merge them into a single function. 
• For that reason, there’s only one mantra here — avoid repeating yourself in your code.

The SOLID Principles

Despite being a collective of software design principles, SOLID can also be used for functional programming languages as well. It stands for five practices, which are

• Single responsibility principle (SRP)
• It states that everything should have its own place, and it should always be placed there. For instance, a class should be responsible for one thing only, and it has to own a specific name.
• To understand this practice, you can imagine your disorganised dorm room where you’re frantically looking for something and what is more surprising initially you find the thing you need! To avoid the dorm-like mess in your coding, you can use the single responsibility principle.
• Open-closed principle (OCP)
• If you need to extend functionality, you can add a new code instead of modifying the existing one. 
• For instance, you might want to use JavaScript decorations, which is a perfect example of the open-closed principle.
• Liskov substitution principle (LSP)
• Substitutability is a principle in OOPs stating that, in a computer program if S is a subtype of T, then objects of type T may be replaced with objects of type S (i.e., an object of type T may be substituted with any object of a subtype S) without altering any of the desirable properties of the program (correctness, task performed, etc.) 
• Named after Barabara Liskov, a computer scientist, this is an object-oriented programming principle that can make your code understandable and easy to read by helping you understand what best practice for inheritance is.
• Interface segregation principle (ISP)
• Don’t make your code depend on methods that aren’t used by your clients. Simply put, ISP splits software into several smaller independent parts in order to minimize the effects caused by needed changes. To do so, you get your interface to fit a definite client.
• Dependency inversion principle (DIP)
• The dependency inversion principle is the last one of SOLID. The main point of this practice is that you should never rely on something definite but on abstractions.
• The common illustration of DIP is when you want to plug in a home appliance so that you can use it, you plug it directly into a socket. 
• You do not probe your wall to dig a hole in there to find wires to connect the appliance. You use the socket (the interface, the high-level module) and what’s behind (low-level modules) is not relevant for you.

The BDUF Principles

• Big Design Up Front is used to indicate that the whole design solution is done before execution. This is typical of traditional models of software development, where there is an explicit phase of Analysis prior to the implementation phase
• This is a relic from the waterfall era before everyone became cool and Agile.
• This acronym is here to remind us not get over carried with super complex architecture. We shouldn’t spend 3 months designing our application before even writing the first line of code. Start small and iterate.
• BDUF is basically what happens when you don’t KISS and end up with a lot of stuff which YAGNI.

2. Software Development Principles

• Code Simplicity 

• Strive to keep your code simple.

• Testing

• Continuously test from end to end.

• Code Coherence

• Keep it consistent across your team.

• Code Reviews 

• Don't be shy, allow someone to check your code!

• Estimation 

• Set your time and budget estimates realistically.

3. Programming Language Principles

• Under this we will talk  Each programming language has its own software engineering best practices and, what is more, they differ from front-end to back-end. Still, we can single out several such practices. Here are a number of language-related principles that you might find useful.

•  Code Smell Detection Tools
• Code smells are not bugs or errors. But they signify certain patterns in code that might be defected and therefore lead to problems in terms of further development of software or/and its maintenance. 
• For this reason, it’s vital to use code smell detection tools. Here are some examples of such tools — inFusion, JDeodorant, Stench Blossom (the names speak for themselves), and a few more.
• Code Quality Tools
• No one is safe from errors, especially when you’re developing software. You are likely to encounter a few on your way. In such a case, it’s always important to be on the safe side of things. That’s why you’d better use tools like linters (or lint tool) and cops. 
• These tools will help you increase the quality of your code by automatically analyzing it and flashing out bugs, inconsistencies, and other errors.
• Code Consistency
• To maintain code, it needs to be consistent. Let’s look up the meaning at The Free Dictionary once again. According to it, consistent means in agreement, compatible, coherent, and uniform, and which is also not self-contradictory. 
• Thus, code consistency means that your code at least suits the definition. Also, it helps you to wrap your head around your code and foresee how your software will behave hereinafter. So try to maintain your code as coherent as possible.
• Code Quality Tips

                    Some tips and techniques can be applied to any coding language and are useful in improving                         the overall quality of your code:

• Allocate appropriate names to all functions, variables, and methods. This will make your code easier to read, understand, and debug.
• Always use the common or native language of the developer for names and descriptive texts. Avoid abbreviations as much as possible to reduce ambiguity.
• Use consistent indentation and alignment while formatting your code for better readability.

How we can use these principles under development Cycles ?

Let's use the simple things how we approach to deliver the products , what all basic steps we should follow and based on that i have categorised these practices for better and effective delivery.

    We can put  these into three phases     

    1.  Initial Phase where development and kick off for the project starts and 

    2.  Mid Phase where Testing and Deployment needed for better stability

    3. Final phase where How better collaboration and monitoring can happen 

Code Ownership 

• Collective Ownership encourages everyone to contribute new ideas to all segments of the project. Any developer can change any line of code to add functionality, fix bugs, improve designs or refactor. 
• No one person becomes a bottle neck for changes. This is easy to do when you have all your code covered with unit tests and automated acceptance tests.


Refactoring

• Code should be written to solve the known problem at the time. Often, teams become wiser about the problem they are solving, and continuously refactoring and changing code ensures the code base is forever meeting the most current needs of the business in the most efficient way. 
• In order to guarantee that changes do not break existing functionality, your regression tests should be automated. I.e. unit tests are essential.


Micro Services

• The micro services architecture runs a set of small services in a single application. 
• These services are independent of each other and communication between these services is by means of a well-defined interface that uses a lightweight mechanism, for example, a REST API. 
• Each service has a single function which matches micro services with business needs. 
• There are different frameworks or programming languages that can be used to write micro services and they can also be set to either function as a single or group of services.


Unit Testing

• The purpose of unit testing is not for finding bugs. It is a specification for the expected behaviours of the code under test. 
• The code under test is the implementation for those expected behaviours. So unit test and the code under test are used to check the correctness of each other and protect each other. 
• Later when someone changed the code under test, and it changed the behavior that is expected by the original author, the test will fail. 
• If your code is covered by a reasonable amount of unit tests, you can maintain the code without breaking the existing feature. 
• Without unit tests your refactoring efforts will be a major risk every time you do it.


Policy as a Code 

• The configuration of infrastructure and infrastructure itself are codified with the cloud. This makes it possible for organisations to dynamically monitor and enforce compliance. 
• It enables the automatic tracking, validation, and reconfiguration of infrastructure. In that way, organisations can easily control changes over resources and security measures are properly and distributively enforced. 
• The fact that resources that do not comply can be flagged automatically for further investigation or automatically restarted to comply, increases the speed level of teams within an Organization.


Configuration Management

• The operating system, host configuration, operational tasks etc. are automated with codes by developers and system administrators. 
• As codes are used, configuration changes become standard and repeatable. This relieves developers and system administrators of the burden of configuring the operating system, system applications or server software manually.


TDD - Test Driven Development

• Test-driven development is a development style that drives the design by tests developed in short cycles of: 



            1. Write one test,
 

            2. Implement just enough code to make it pass,


            3. Refactor the code so it is clean.


Automatest Testing

• Also known as Specification by Example. Specification by Example or Acceptance test-driven development (A-TDD) is a collaborative requirements discovery approach where examples and automatable tests are used for specifying requirements—creating executable specifications. 

Chaos Engineering

• Chaos Engineering is the discipline of experimenting on a system in order to build confidence in the system’s capability to withstand turbulent conditions in production.
• A good example of this would be the Chaos Monkey of Netflix. 

Continuous Integration

• "Continuous Integration is a software development practice where members of a team integrate their work frequently, usually each person integrates at least daily - leading to multiple integrations per day. 
• Each integration is verified by an automated build (including test) to detect integration errors as quickly as possible. Many teams find that this approach leads to significantly reduced integration problems and allows a team to develop cohesive software more rapidly." 
• You see, without unit tests and test automation, it is impossible to do CI right. And only when you do CI right you might be able to succeed at Continuous Deployment.


Continuous Deployment

• Continuous delivery is a series of practices designed to ensure that code can be rapidly and safely deployed to production by delivering every change to a production-like environment and ensuring business applications and services function as expected through rigorous automated testing. 
• Since every change is delivered to a staging environment using complete automation, you can have confidence the application can be deployed to production with a push of a button when the business is ready. 
• Continuous deployment is the next step of continuous delivery: Every change that passes the automated tests is deployed to production automatically. 
• Continuous deployment should be the goal of most companies that are not constrained by regulatory or other requirements.



Infrastructure as a Code

• Code and software development techniques like version control and continuous integration are used to merge and provision infrastructure under this practice. 
• The interaction with infrastructure is programmer based and at scale rather than a manual setup and configuration resource. 
• The API-driven model of its cloud makes it possible for system administrators and developers to interact with the infrastructure as such. Code-based tools are used by engineers to interface with infrastructure; hence it is treated like an application code. 
• There being code based makes it possible for infrastructure and servers to be quickly deployed, using fixed standards, also the latest patches and versions can either be updated or repetitively duplicated.


Logging and Monitoring

• To gauge the impact that the performance of application and infrastructure have on consumers, organisations monitor metrics and logs. 
• The data and logs generated by applications and infrastructure are captured, categorised and then analysed by organisations to understand how users are impacted by changes or updates. 
• This makes it easy to detect sources of unexpected problems or changes. It is necessary that there be a constant monitoring, to ensure a steady availability of services and an increment in the speed at which infrastructure is updated. 
• When these data are analysed in real-time, organisations proficiently monitor their services


Collaboration and Communication

• This is the key feature of any Agile and/or DevOps model; as development, test, security, and operations come together and share their responsibilities, team spirit is enhanced and communication skills are facilitated. 
• Chat applications, project tracking systems, and wikis are some of the tools that can be used by not just developers and operations but also other teams like marketing or sales. 
• This brings all parts of the organisation closely together as they cooperate to see to the realisation of goals and projects.

Final Conclusion

                                                    We are at the end of this section and learned a lot about best engineering practices ,above is  our non-exhaustive list of best practices for software engineering. These principles will not only help you code more efficiently, but also raise awareness in the software engineering community about responsible coding and making a better products.