DEV Community: Chris Mathurin

Front-end development (React in this case) and the SOLID principles

Chris Mathurin — Tue, 13 Mar 2018 02:38:12 +0000

Having been a full-stack developer for a number of years now, I have mainly seen SOLID mentioned (let alone enforced) when working on back-end code. Maybe a few years ago it was harder to implement, but we have libraries and framework such as Knockout, Angular, Vue and React, which should make this at least a bit easier.

"Is React SOLID?" is a short article about how React allows you to use the SOLID principles. As React is a library, it does not force you to apply any principles...

What does SOLID stand for?*

SOLID is an acronym build by the first letter of 5 object-oriented programming design principles. The basic idea is, if you follow these principles, your software gets better.

Single responsibility principle

Open/closed principle

Liskov substitution principle

Interface segregation principle

Dependency inversion principle

In case you need a reminder, here's a link to a good intro.

The conclusion of the article is:

*"While React doesn't force the principles onto you, at least it often allows you to follow them. Sometimes it gets easier because of JavaScript, sometimes JavaScript makes it harder, but overall it is possible to write SOLID applications with React."

As a C# developer, I definitely find it is much easier to apply SOLID to back-end code, probably because I've spent most of my time working on back-end code.

I am currently learning React, well at least trying... I know that I'll try to follow at least Single Responsibility and Open/Close principle. I am not so sure about Dependency Inversion, as front-end testing makes it much easier to test and mock your code, wherein C# you would be required abstract things using interfaces with the help of some DI mechanism. Liskov substitution perhaps, but Interface segregation probably not.

I did a spike to find out ways to implement dependency injection. Some of the things I looked into were:

InversifyJS
Redux Observable
Using the module system
PropTypes
Redux

As we are using Redux to manage states, it made sense for us to use it for DI where (and if) required. We are not currently enforcing the use of TypeScript in our current project, but it is something that we want to adopt as we previously trialled it while working on an Angular SPA. Using TypeScript would make applying SOLID much easier and more aligned with C#, which I think is great. C# developers should find it familiar and front-end devs would be exposed to concepts already used in C#. Maybe a good path into full-stack for those interested?

Any SOLID and/or TypeScript fans in the building? If you have used it, what is your experience, good or bad? And are you a full-stack or front-end dev?

Source:
*Is React SOLID? (From a fellow Dev.to member :)

NET Core 2: Why xUnit and not NUnit or MSTest

Chris Mathurin — Tue, 13 Mar 2018 02:08:55 +0000

With a recent new project using NET Core 2, my team and I looked at whether we should move to MS Test(Didn't consider MS Test 2 at that time), stick with NUnit or try xUnit. We had a spike, where I looked into whether we could still use NUnit in case we were not able to use xUnit, as we were not keen on MSTest as an alternative framework. In the end, we decided to give xUnit a go!

xUnit is pretty lean compared to NUnit and MsTest and has been written more recently. The .NET framework has evolved since NUnit was first created. XUnit leverage some of the new features to help developers write cleaner test, as tests should be kept clean and treated as first-class citizens. The authors wanted to codify some rules rather than repeating guidance about “do X” or “don’t do Y". You can read more about why xUnit was created here: https://xunit.github.io/docs/why-did-we-build-xunit-1.0.html.

Some of the reasons why we went with xUnit:

NUnit was not fully compatible with .NET Core 2 at the time
We wanted to move away from MS Test, as the team preferred the xUnit and NUnit way of writing tests
xUnit is aimed at improving test isolation and trying to codify a set of rules to establish a testing standard.
xUnit [Fact] and [Theory] attributes are extensible, so you can implement your own testing functionality.xUnit doesn’t use Test Lists and .vsmdi files to keep track of your tests.
Microsoft is using xUnit internally, one of its creators is from Microsoft. xUnit was also created by one of the original authors of NUnit.
There are no [Setup] and [Teardown] attributes, this is done using the test class’ constructor and an IDisposable. This encourages developers to write cleaner tests.
xUnit allows us to write less code since its flexibility allows things like subspec which allow you to write only what you need to do. Using tools such as xBehave: http://xbehave.github.io/ and Xunit.Gherkin.Quick.
xUnit is easier to read and uses intuitive terminology.

An interesting recent article from Uncle Bob on (unit) testing:
http://blog.cleancoder.com/uncle-bob/2017/05/05/TestDefinitions.html

A performance (with a new update to Visual Studio 2017) comparison was released a few months after picking our testing framework, comparing NUnit, xUnit and MS Test 2. You can find the blog post from Microsoft here.

References:

http://georgemauer.net/2015/05/01/why-not-mstest
https://seankilleen.com/2015/06/xUnit-vs-MSTest/
https://stackify.com/unit-test-frameworks-csharp/
https://xunit.github.io/docs/why-did-we-build-xunit-1.0.html http://blog.cleancoder.com/uncle-bob/2017/05/05/TestDefinitions.html

Brief intro to Evolutionary Architecture

Chris Mathurin — Tue, 13 Mar 2018 01:39:21 +0000

A few weeks ago I attended a talk organised by Thoughtworks about "Building Evolutionary Architectures". This was a very interesting and important subject, which addressed the issues that most software development teams will encounter at one point or another. The main one being Tech Debt, and how to monitor, reduce and prevent the same type of Tech from re-occurring.

This topic addresses the new kid on the block, Microservices, and how this new architecture has made us rethink how we design software.

"For many years, software architecture was described as "the parts that are hard to change later". But then microservices showed that if architects build evolvability into the architecture, change becomes easier."

"Incremental change is critical for the mechanics of evolution, while uncontrolled evolution leads to undesirable side effects. Predictability is impossible when the foundation architects plan against changes constantly in unexpected ways. Instead, prefer evolvability over predictability."

One of the focus of the talk was "Fitness Function", which is described as follows:

"Mathematically speaking, a function takes input from some allowed set of input values and produces an output in some allowed set of output values. In software, we also generally use the term function to refer to something that is actually implementable. However, as with acceptance criteria in agile software development, the fitness functions for evolutionary architecture may not be implementable in software (e.g., a required manual process for regulatory reasons), but architects must still define manual fitness functions to help guide the evolution of the system. While automated checks are preferable, some projects cannot automate all fitness functions. Thus, it is still useful for architects to elucidate architectural verifications explicitly as fitness functions for many reasons that will become evident."

Conveniently some of the people at ThoughtWorks have just published a book called "Building Evolutionary Architectures", you can download a free chapter here.

Source:
Building Evolutionary Architectures