How TypeScript can unite the Software Engineering tribes
How explicit modelling benefits the development process
Explicit modelling makes it simpler for developers to maintain and extend the codebase because the intent of the code is made clearer by the extended vocabulary provided by TypeScript.
Using TypeScript simplifies the process of writing code that adheres to SOLID principles because the semantics commonly associated with those principles, such as abstract interfaces and classes, are codified in the language. There is no need to infer these constructs because they are first class features in TypeScript.
How we use TypeScript at Amplience
Our team started experimenting with TypeScript during some self-contained integration projects. These projects consisted of an API-controller layer, backed up by services to do the heavy lifting and to communicate with external and internal APIs.
We had a particularly eclectic team composition for the project consisting of:
Back-end developers who were familiar with strongly typed languages
QA developers used to writing tests in Ruby
The team was diverse in terms of experience and job role, but TypeScript offered something familiar for everyone, including:
Strong typing, classes, interfaces familiar to back-ends
A strong set of tools available to QA for integration testing
All members of the team had to overcome their own personal learning curves to become familiar with TypeScript and its language features, but working with a common language and tools made a huge difference to the way the team worked together.
How our workflow was enhanced
By leveraging the same models, interfaces and fixtures between QA and development, the team were able to reason better about how the projects were built. All of this was made possible because TypeScript gives you the language features that make it simpler to write high-quality and maintainable code.
The TypeScript compiler robustly enforces the rules we put in place, so there was less ambiguity when multiple developers and disciplines worked on the codebase.
Challenges we would have faced if we hadn’t used TypeScript
We definitely could have taken the pencil and paper approach, but surely there’s a better way?
The answer is a resounding ‘Yes’, and the solution is to use TypeScript.
TypeScript’s strong typing makes it simpler to explicity implement design patterns and OO concepts, such as the factory function pattern demonstrated below.
Had we chosen not to use TypeScript, the team would have been deprived of the ability to check types at compile-time and in our text editors using a linter. We would have been throwing away an array of tools that do the heavy lifting and ensure we’re making the system work as intended.
Data inconsistency, re-definition and duplication would have always been a risk, and the Object-oriented constructs we benefited from in TypeScript would not have been formalised had we relied on implicitly implemented patterns.
All in all we found TypeScript to be a great language and tool to use in delivering our project, and each of us learned a little something along the way.
The problem with a disjointed stack
There can be a disconnect between front-end and back-end developers working on different parts of the same application, perhaps working in different programming languages and with different technologies. This lack of awareness can be problematic when new features are being developed that require input from both sides of the stack in order to properly design a solution.
The disconnect is illustrated in the image below, which shows that the natural meeting point between the two disciplines is the API layer.
The possible solution
This chasm can be filled by adopting a common dialogue within a project. The dialogue could take the form of understanding a common set of design and architectural patterns at the high level, or if we were to go a little lower level, we could even use the same programming language within the stack so that components can be more easily described and communicated amongst all team disciplines.
How using TypeScript changes things for the better
We believe that TypeScript is the language to unite and align the entire stack and has the potential to make teams more cross-functional or ‘T-shaped’.
You can even dive deep into the future of TypeScript
Here’s some new functionality from the 3.7 beta of TypeScript that demonstrates the new optional chaining operator (look out for the ‘?’ operator in the code example below):
TypeScript has been a good fit for our projects at Amplience, and it doesn’t look like it’s going away any time soon. TypeScript is growing in popularity, has robust documentation and an enthusiastic community behind it.
We think that using TypeScript will make your development teams happier, more T-shaped and better communicators- and it will also help them write more resilient and maintainable code.
As the old saying goes, the proof of the pudding is in the eating. So dig in and see how TypeScript can change the way your teams work for the better.