Category: design Pattern

Git workflow.

Git workflow.

Git is a version control system for tracking changes in computer files and coordinating work on those files among multiple people. Git is a SCM (source code management) in software development.

Git was created by Linus Torvalds in 2005 for development of the Linux kernel, with other kernel developers contributing to its initial development.[12] Its current maintainer since 2005 is Junio Hamano.

Three main workflows of git

When we are using git there are three main workflows that can be adopted.

  1. Centralized workflow
  2. Feature Branch Workflow
  3. Gitflow workflow

1.Centralized workflow:-

The most popular workflow among developers and the entry stage of every project.

The idea is quite simple. There is only one central master repository. Each developer clones the repository works locally on the code makes a commit with changes, and push it to the central master repository for other developers to pull and use in their work.

2. Feature Branch workflow:-

In feature branch workflow user create feature wise branch. This useful when you want to do some experiment. After complete development of that code user can then merge the code to the final branch. Branches are independent “tracks” of developing a project. For each new feature, a new branch should be created, where the new feature is developed and tested. Once the feature is completed and ready to live, the branch can be merged into the master branch.

3. Gitflow workflow:-

In this type, a user takes advantage of git branching. This is somehow similar to a feature branch workflow but there are some differences. In this type, a user creates the branch based on the software development lifecycle. Like separate branches for features once all the features are ready then merge those feature branch inside the development branch once everything is verified and tested then merge that branch to release branch or some SIT branch. Or we can create them based on the product version as well.

The above is a simple example. This, not a mandatory to workflow as it is.

You can customize the workflow based on project requirement, team size and team expertise using the git and teams fine grain structure. For my personal project, I use a centralized workflow. For large enterprise project and in CI and CD implementation scenario people prefer the git-flow workflow.

So which approach do you choose? and Why? Let me know in comments.

For more stories.

Lets connect on Stackoverflow , LinkedIn , Facebook& Twitter.

Micro service architecture for legacy code base.

Micro service architecture for legacy code base.

For more stories.

Refactoring the legacy code is art.

There is no prerequisite to understanding this article. But if you go through the below article it could be advantageous Manage Big Ball of Mud.

As new features and new functionality are introduced the complexity of this application can increase dramatically and harder to maintain code base and add new features too. This application becomes the Big Ball of Mud. Teams have been struggling to maintain the complex application and some suggest replace the complete application with new technology, new hosting and or new architecture pattern. Replace the complete solution is really hard.

There have been big buzzwords in the industry about micro service, serverless architecture. Starting the greenfield development is a quite easy task. What about legacy one?

Strangulation

Michiel Rook’s blog Gradually convert Monolith into micro-service app

Martin Fowler describes the Strangler Application:

One of the natural wonders of this area are the huge strangler vines. They seed in the upper branches of a fig tree and gradually work their way down the tree until they root in the soil. Over many years they grow into fantastic and beautiful shapes, meanwhile strangling and killing the tree that was their host.

This has been a long journey to convert your monolith application into micro-service or nano service architecture or any other architectural pattern that is well suitable for our application context.

Solution

In a 2004 article on his website, Martin Fowler defined the Strangler Application pattern as a way of handling the release of refactored code in a large web application. The fundamental strategy is EventInterception, which can be used to gradually move functionality to the strangler and to enable AssetCapture.

The Strangler Application is based on an inference to a vine that strangles a tree that it’s wrapped around. The idea is that you use the structure of an application — the fact that large apps are built out of individual URIs that map functionally to different dimensions of a business domain — to divide an application into different functional domains, and replace those domains with a new micro-services-based implementation one domain at a time. This creates two separate applications that live side by side in the same URI space. Over time, the newly refactored application “strangles” or replaces the original application until finally, you can shut off the monolithic application. Thus, the Strangler Application steps are

  1. Choose a particular specific piece of functionality which is solo within an application.
  2. Modify it or refactor and rebuild as a service.
  3. Deploy while deploying use proxy pattern to bypass the traffic. This will help us to run code for both legacy and new user. or Create simple facade to intercept or filter the requests going to the backend legacy system.
  4. Repeat above steps until an application is fully migrated.

The great thing about applying this pattern is that it creates incremental value in a much faster timeframe than if you tried a “big bang” migration in which you update all the code of your application before you release any of the new functionality. It also gives you an gradually approach for adopting micro-services — one where, if you find that the approach doesn’t work in your environment, you have a simple way to change direction if needed.

Strangler Pattern address the following problems

  1. Legacy code or Big ball of mud.
  2. complicated and complex architecture.
  3. Monolithic design
  4. Fragmented business rules
  5. Painful deployment process

There are certain aspects which are specific to those particular applications. If it is really old code then we need to figure out and refactor accordingly into some functional level separation and then apply the strangler pattern.

There are two sides either complain about the things and be a part of the problem or take this up find solution and be a part of solution.

For more ref:-

Application Strangler Pattern Experiences & Thoughts
The biggest problem to overcome is lack of will to actually finish the strangling (usually political will from non…stackoverflow.com

https://docs.microsoft.com/en-us/azure/architecture/patterns/strangler

This is just simple idea. Apply and let me know.

For more stories.

Lets connect on Stackoverflow , LinkedIn , Facebook& Twitter.

Pragmatic REST API design guide.

Best way to design REST API.

I have both experiences as API developer and API consumer too. I am curious to know is there any best practices, There should be some consensus, here is the answer Google released an API design guide recently.

Characters of design good API:-

  1. Easy to learn
  2. Easy to a consumer without documentation.
  3. Secure & scalable.
  4. API should be easy to extend.
  5. Deliver higher quality in lower cost.
  6. Appropriate to an audience.
  7. High adaptability & Productivity.

The Google API design guide is pretty straightforward in its purpose, with a goal of helping “developers design simple, consistent, and easy-to-use networked APIs” — but I thought it was noteworthy that they were also looking to help “converging designs of socket-based RPC APIs with HTTP-based REST APIs.”

“This Design Guide explains how to apply REST principles to API designs independent of programming language, operating system, or network protocol. It is NOT a guide solely to creating REST APIs.”

Most of the companies think that API design is only in the context of REST API design this guide will help you to think beyond the REST API design style.

The best thing about this guide is this is not only for REST. I think many of the developers already aware of the API style book. API style book is really best guide to designing REST API. If you don’t know about the API style book then go through it and apply the same in your tool suite.

I love the way google guideline explain to us How to design good API.

API should do one thing and do it well.

Don’t leak implementation logic. Names really matter in API design, names should be largely self-explanatory. API should like prose.

This is the simple my understanding about the Google API design guideline and let me know more from you, How you guys design API in an organization?

If you enjoyed this article, please don’t forget to Clap.

For more stories.

Let’s connect on Stackoverflow, LinkedIn, Facebook& Twitter.

Manage Big Ball of Mud.

Manage Big Ball of Mud.

Everyone wants to develop a project from scratch no one wants to manage the big ball of mud. This article is for those people who wanted to

” Leave campground cleaner than you found it”.

What is Big Ball of mud? Ref- Wikipedia.

A big ball of mud is a software system that lacks a perceivable architecture.A BIG BALL OF MUD is haphazardly structured, sprawling, sloppy, duct-tape and bailing wire, spaghetti code jungle.

Ball vs Blocks

Let us observe the picture to understand the difference between to manage the big ball & manage the block. Carrying the big ball is tedious instead of the blocks. When a ball is small we can easily carry and maintain. When its size increases it’s very difficult to manage. As we generally try to arrange the big balls to make some structure it is quite difficult? While If we try to arrange the blocks and structure them it is quite easy and maintainable.

How these forms?

Big ball of mud is an architectural disaster. This kind of systems has usually been developed over a long period of time, with different individuals are working on various pieces. The people who develop this kind of architecture with no formal training of what is software architecture or programming design pattern training.

There are many reasons

  1. No formal training of software architecture.
  2. No formal knowledge of design pattern.
  3. Financial or Time pressure.
  4. Throwaway code.
  5. Inherent Complexity.
  6. Change of requirements.
  7. Change of developers.
  8. Piecemeal Growth.

How to manage BBOM?

Sometimes the best solution is simply to rewrite the application catering to new requirements. But this is the worst case scenario.

The clumsy solution is that stop the new development and refactor whole system step by step. To do this

  1. Write down the test cases.
  2. Refactor code.
  3. Redesign & Re-architect the whole system.

To overcome this BBOM anti-pattern. You must have to follow below steps

  1. Code Review
  2. Code refactoring overtime period.
  3. Fallow best practices.
  4. Use design Pattern & architectural pattern.
  5. If you have time constraint while developing at least design code in a modular way (Single responsibility principle), so you can easily rearrange later.
  6. Use TDD(Test Driven Development).

Big ball of mud isn’t just absence of architecture rather its own architectural pattern, that has merits and trade-offs.

I am not saying here that this case is never gone happen, This happens many times with many peoples including me as well.

This article will give you a brief idea, How to manage & overcome this issue?

There is a will there is a way.

I have followed this path, love to hear from you folks.

How you are gone managing this big ball of mud?

For more stories.

Let’s connect on Stackoverflow, LinkedIn, Facebook& Twitter.