I have joined a team in company and this team owns few services, which are used widely by many other user facing internal/external UI apps and other internal apis.

My manager gave me rough idea that these services are responsible for, let's assume, around $1B worth of traffic, or something like, so idea was, it's super critical.

There are tons of business logic, lots of if/else in c# code. Also sql Stored procedures and sql function are used. I have worked in these kind of code in past also, so I know these services are complicated too.

System mainly in maintenance mode, so no frequent code changes.

There are no unit tests and very minimum documentation.

There is an effort going on to rewrite these services side by side, without modifying this existing, and some migration plan. My manager want me to understand business.

Need for frequent releases, data issues in this monolithic in various environment, old infrastructure and high maintenance causing money, are few reasons. There is an initiative for cloud Native microservices in my organization.

In past, for these kind of scenario, I wrote integration test first. But this time I am trying to write this in BDD style, not sure if this going to be a right approach. I never worked with BDD, but read about it. Seems output of BDD is good documentation, with other benefits. Nevertheless my ultimate aim to document business logics so that we can use it while rewriting this application. Refactoring seems not an option here.

Suggest me if I am going in right direction, any other points I should take care of, on effective documentation of business logics.

  • Is a 1B USD project that you the right setting for experimenting with something new? – VoiceOfUnreason Apr 24 at 2:17
  • These are set of services. There is no plan to modify this codebase, but writing new set of services. Frequent releases, data issues, old infrastructure are few reasons. Updating in question also. – PKV Apr 24 at 2:39

First, read Working Effectively with Legacy Code. Then read it some more.

Other than that, my own take on your specific situation:

  • A big bang rewrite is going to be pretty much impossible to pull off. You've got a complicated system which is talking to a lot of other systems, making the whole thing a giant system. And you want to replace the central part, undocumented and untested as it is, with new code. And it sounds like any amount of downtime is going to cost $$$$. So writing tests and then refactoring (again, book above) carefully is the way to go.
  • BDD tests are great in theory.
    1. Non-programmers can write tests! Except not really, any more than non-programmers can write SQL. Both look vaguely like English, but there are strict rules and you very quickly run into problems trying to translate the umpteen different ways of phrasing something into code, or conversely, trying to teach non-programmers to (effectively) code.
    2. It's fast enough! Sure, until you actually have a reasonable amount of tests, at which point a single run will take days. This is one thing that is glossed over in pretty much anything I've read about BDD, acceptance tests and end-to-end tests (as these terms overlap considerably): your first test will probably run in milliseconds, but in realistic applications a unit test covering the same code will run orders of magnitude faster.
    3. It's readable! No, the test cases themselves may be kind of readable but clunky English, but as a programmer you need to understand all the code which goes into running a test. BDD tests inevitably end up glossing over details which are handled in lower layers, which just as inevitably comes back to bite you when those details turn out to be important to your tests. In plain acceptance tests you're much more likely to see where things have been glossed over (things like having to pass DisableCertificateVerification flags or creating the objects you are manipulating). With BDD you're also dealing with one extra language, and that is not a complexity you should take on lightly.
    4. My IDE supports Gherkin! Well, kinda. Until you mix givens and whens (because sometimes something is a prerequisite and other times it's the thing under test), loop over test cases and more complex features, and your IDE gets very confused trying to go to the right definition.
  • Thanks. Refactoring seems not an option. Updating in question also. Regarding documenting cases/ scenarios, my idea was not worrying slowness. As system is mostly in maintenance, so no frequent code changes as such, mostly data issue. I have no need to document it from business point of view as long as my new service can learn from names of all test cases from old system. Not sure this can fly. I am not confident – PKV Apr 24 at 2:55
  • Considering the large body of evidence that big-bang rewrites are commonly disasters my main question would be why a rewrite is not an option. If you're changing everything about the system it makes sense, but you haven't mentioned transitioning to a different language, framework, database or anything else which would necessitate a plug-in replacement, and it sounds like the system will need to continue exposing equivalent APIs as the main entrypoints. – l0b0 Apr 24 at 3:02
  • You meant refactoring? As I updated in question, we are planning rewrite. Reasons, mainly dividing in microservices. – PKV Apr 24 at 3:11

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.