DEV Community: Swarup Kumar Mahapatra

When to refactor

Swarup Kumar Mahapatra — Mon, 15 Jun 2020 09:51:48 +0000

We always believe we have put our best efforts while writing code. However following questions come to mind

When should one start refactoring, when should one stop refactoring?
Doesn’t bias kick in while trying to start refactoring your own code?

Understanding Encapsulation

Swarup Kumar Mahapatra — Tue, 14 Jan 2020 08:03:35 +0000

I have been reading Domain Driven Design for a while.

I realized, creating Value Objects and building Entities by composing Value Objects is the best way to explain Encapsulation.

Getters and Setters do not explain encapsulation at all.
Agree?

Will I still be called a developer?

Swarup Kumar Mahapatra — Mon, 16 Dec 2019 14:30:03 +0000

There are many people who write code. Some (many) of them are from non computer science background. Some are self-taught.

Some of them may understand Data Structures and Algorithms, but cannot write the implementation. They would have successfully delivered projects by using modern libraries/frame-works.

By doing so , they would have got good grasp over "System Design". Yet they would fail to implement a "merge-sort".

Will they still be called a developer? Are they not as good as developers from FANG companies ? Are they left behind?

F - Facebook , A - Amazon , N - Netflix, G - Google

Looking forward for opinions.

Also I am part of the "They" .

Back to Basics

Swarup Kumar Mahapatra — Mon, 25 Nov 2019 18:49:08 +0000

I have been in software industry for some time. However there are times, where I feel like going through basic concepts again.

Example:
Basic sorting, search algos
Stacks/Queues/Trees
4 pillars of OOPS
Refactoring
REST

Does anyone feel the same? How often do you go through such topics again? ✋
Most importantly, why you do it?

How were you introduced to DDD ? And how much time did it take to grasp the concepts?

Swarup Kumar Mahapatra — Sat, 21 Sep 2019 18:19:47 +0000

There is Algorithms, which takes lot of time to grasp.
Then there is Domain Driven Design, where one might think they got the point, but with very next example you feel lost. Too subjective. No Thumb Rules.

So how has been your journey with DDD so far?
When did you first encounter it and how did you learn it?

Test Driven ... Everything

Swarup Kumar Mahapatra — Sat, 01 Dec 2018 13:56:40 +0000

TDD , or test driven development , is one of the better ways to develop software. It leads to better design.

TDR , or test driven reading , is one of the better ways to understand programming concepts. (specially Design Pattern topics)

The more blogs and tutorials I read, the more I realise that every article starts with the design code and then the execution ( main() ) code .

I then thought, if I read the main/execution code first and then try to go back and see the design code , then everything starts making sense.

Tests / main() code also leads to a better understanding of programming concepts

Thoughts ???

Need help in understanding 'Why use REST'

Swarup Kumar Mahapatra — Fri, 16 Nov 2018 18:44:56 +0000

I have been using RESTful services for quite a while (#what and #how of REST). I am looking for examples where the example might look like REST but it doesn't follow the core REST principles. Help me out please!.

[UPDATE] - The following video https://youtu.be/pspy1H6A3FM?t=1018 has been an eye opener, however its worth while to have a discussion.

Test Automation - whose job is it anyway?

Swarup Kumar Mahapatra — Thu, 08 Nov 2018 14:30:28 +0000

I have spend 2 years in manual testing , 2 years in web automation testing and 1 year in software development across various tech stacks in various companies.

Nobody denies the fact that testing is the key ingredient for quality software development. I would go one level up and say these words

“Well Planned Testing is the only ingredient required for building best software products”

What is testing?

Given a certain input, When an action is performed, Then the outcome should match as expected. Plain and simple to explain.

Testing takes place at various levels of software development project. The more detailed the tests and each level , the better the software. At some levels the tests can be like “Verify that a string becomes camelCased upon calling a method named uppercase . And the tests can be like Verify a mail is received by recipient after sending a mail to a valid emailId” .

Test Pyramid is a well known concept of how to plan testing of a complex software project. A key part of the pyramid is AUTOMATION. And people to do automate the tests at every level , however the tests priority and tests ownership is the least at the peak of pyramid. And when regression sets in, questions are raised on this layer of tests by management.

Here is my RANT on why automation of the peak layer fails.

Automation scenarios are listed out by QAs (good thing) , but implementations are done as PET PROJECTS.
Pet Projects are written by using an arbitrary technology and since not all QAs are technical , not all of them get involved.
The automation tests does the intended job and it provides a great sense of regression security , but the code lacks production code standards since it is pet project.
The writer wouldn’t have spend time on learning clean code and neither the fellow colleagues get involved in learning it (specially manual testers) . Even if some other QAs get involved, the quality never increases because they don’t spend full time on it.
One fine day the writer leaves the company, and the tests would fail in the CI and no one takes ownership of it. More features are added the tests break, but nobody maintains.
Meanwhile a new QA who knows a bit or programming joins in. A regression happens in the software and the blame goes to the QAs for not maintaining automation tests.
This new QA rises up and scans the existing automation test. He may or may not know the tech stack, but maintaining seems hard to him. Then he starts his own PET PROJECT and re-writes the test-cases.

Things that “PEOPLE THINK” could have prevented the re-write.

Creating a dedicated automation testing group. This won’t work out because in the agile world , teams tend to be small and QAs tend to be less as well. Even if a manager creates a dedicated automation team , the members rarely pay attention to the functionally of the product. This happens because their success is determined by the number of cases translated rather than having a deep understanding of the product and no brainstorming in creating the correct suite of automation cases. This leads to mindless automation and huge suite of test cases . Violates the Test Pyramid
Developers only writing automation suite. The same problems of the above point exists. Along with that the developers feel like “this code” is a second class citizen job (just because it doesn’t go to production) , and nobody wants to pay attention to it since devs fear that their career would change.

Test automation gets treated as a second class career, sadly.

Back to the title of the article, whose job is it anyway?

First, test automation SHOULD NOT be treated as a pet project . Even if someone starts as a pet project, they should not go beyond 2 scenarios. The pet project should be presented infront of management and senior developers and need to be presented as a case that the project needs to be treated in the same way as a production code , and any engineer should be able to support it as and when required. An OATH taking ceremony needs to be done.

Next, assuming the team comes to a consensus regarding the tech stack to be followed, taking a leaf from pair programming, a QA too should pair with a developer. The developer role can be rotated on periodic (sprint basis).

Following are the advantages of pair programming.

Pair Programming makes sure that knowledge exchange happens. QA will be the driver, Dev would the navigator.
The developer makes sure that code quality remains high
The rotation of developer makes sure that even if a QA resigns, the tests at least can be maintained until the next QA steps in.
The automation tests slowly becomes the savoir of the masses for devs . They will make sure that these tests are run against their commits.
The QA on the other hand improves his own coding skills.
Finally the QA , who does the manual testing, also brainstorms in making the right choice of test cases and follow the test pyramid.

Well that was my idea , I would like to know what others think about it.

May be question still remains.

Test Automation — whose job is it anyway?