Everyone eventually rewrites either a small piece of code, an entire application or framework or refactor their work, and this process is in a constant cycle. You notice this everywhere, from small applications, libraries, frameworks and even Enterprise Software. Should we be concerned? Why is this such a common theme?
For Applications, one of the primary reasons for refactoring or rewriting is technical debt, so let’s have a look at some common reasons for technical debt, and I attempt to propose some solutions to each point.
The concept of concurrency is not an easy concept to grasp, when dealing with concurrency - the main enemy when doing any task in parallel are shared resources. This is why functional programming as a concept has gotten a lot of attention due to it’s potential in this modern age where there is an abundant amount of CPU core’s, making it much more scalable for parallel computing.
What about the
Object Oriented Approach? well, we’ve been dealing with concurrency problems for quite some time, and in
.NET, we have the we have the
Task Parallel Library(TPL). TPL makes concurrency patterns easier to implement. Let’s have a look at one of the most common problems in concurrency - race conditions.
So, you have some type of application that does simple image manipulation - in most web applications case, resizing. You use some library, you construct an object with the image binary as a stream, and it does some wizardry magic and poof, you’ve just resized the image and stored it in a file in an image format of your choosing.
But wait - some image formats aren’t that trivial. Maybe we don’t care too much about the detail of how it does this, but we do care about what happens to our streams, how it’s used, and how much memory is consumed - after all, we wouldn’t want our application to crash or become unresponsive, right?
I’ve recently been heavily involved in moving towards a Service Oriented Architecture - and the most common form of Transport / Network Protocol used is of course,
HTTPdue to tooling and statelessness.
HttpClientis well known for being thread safe. Infact, it is very much encouraged to instantiate a
HttpClientobject and keep it in memory for as long as you need, this avoids the extra cost needed for reconstructing the object.
But, is it really that thread safe? Well, after some experiments with high volume of requests, it turns out - not completely / it depends.