0

Our team is working on software that does a lot of calculations, inputs are quite immense structures and outputs are calculated data for the GUI (around 10 tables, warnings, and other messages produced deep in the code). I think neither the input data structures can be smaller, nor the outputs. The generated output to the GUI and for example warning messages are being sent from the place where they have occurred. I think it's not a good idea to put them into the output structures, they would create outputs very hard to test and data would have to go unnecessarily through many layers of code. On the other hand, I hate having these side effects. Is there any architectural approach how to deal with these side effects?

Improve this question
10
  • Are warning messages literally calls to something like MessageBox.Show("The warning message"); or are they strings that get passed from one DTO to another?
    – Greg Burghardt
    Feb 28 at 19:37
  • 1
    Consider using Test Driven Development to write the code. Making code testable up front helps on this.
    – Thorbjørn Ravn Andersen
    Feb 28 at 19:45
  • @GregBurghardt we are sending a message to GUI from backend
    – Michal Krasny
    Feb 28 at 20:27
  • @ThorbjørnRavnAndersen TDD never worked for me. I usually learn by coding and for TDD I must know, how the system works and what I want, but I learn that either after the work is done or often after several bugfixes.
    – Michal Krasny
    Feb 28 at 20:29
  • 1
    If this implementation detail cuts across concerns or module boundaries, then it is very relevant, and could be the source of your architectural problems right now.
    – Greg Burghardt
    Mar 2 at 13:07

1 Answer 1

Reset to default
8

There is no silver bullet to solve your issue.

That does not mean it cannot be solved, though "solved" is probably be the wrong term. A better description is IMHO "it can be managed", since there is not just one solution, but only a set of techniques and practices your team can apply.

Without claiming of being exhaustive:

  • Try to split your system into separate, individual components where each one has a strictly defined input and output. Implement a clear data flow between the different components of your system. Visualize the flow using diagrams, and model precisely what input goes into a certain calculation, and what output comes out (including the warning messages).

  • Warning messages which are only for the purpose of logging should be fed into a separate stream or output channel, which does not have any real influence on the flow of control. What kind of channel or channels you need is nothing I can tell you from this 100,000 feet view, for this you have to provide some more details.

  • Warnings or error messages in a batch process which refer to certain input records should either be directly included in the output for the specific record, or keep a machine-readable reference to their input. That will allow you to either sort the records out, handle them in a special manner or process them later.

  • Your team should gather some expertise in functional programming, immutable data structures and techniques like map-reduce.

This is all which comes into my mind right now, I guess I have missed a few things, but I think you get the general idea - your team needs a tool box, not just "one ring to rule them all".

Improve this answer

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge that you have read and understand our privacy policy and code of conduct.

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