No matter whether you are a decision-maker, a junior dev, a recruiter or a project manager, our industry has created a plethora of buzzwords and deemed them industry standards on different levels.
This article will tackle some of the more prominent Marketing/CV Buzzwords in an attempt to explain them just deep enough to grasp the core idea for more educated decisions in the future.
At the end of the article, I will also include a link list for the different topics of this article.
Sounds weird, right?
Tools like the pre-compiler Babel allows developers to use newer features by transpiling new code features into older and cross-browser compatible alternatives.
Here's a quick rundown of the most important versions:
- ECMAScript 6 (ES6)/ ECMAScript 2015 (ES2015)
- ECMAScript 7 (ES7)/ ECMAScript 2016 (ES2016)
- ECMAScript 8 (ES8)/ ECMAScript 2017 (ES2017)
- ECMAScript 9 (ES9)/ ECMAScript 2018 (ES2018)
As you can see, starting with 2015 a more regular and streamlined pace was established. By far the biggest and most popular step was going to ES5 and while more recent versions also come with increasingly modern and amazing features, they pale in terms of popularity impact compared to ES5.
The whole process is rounded up by a proposal stage for new features not yet standardised and officially released. This is nice for playing around and all that but it is not.
Basically everywhere: frontend, backend, web, mobile, maybe even your next office coffee maker… To say it with the famous words of Jeff Atwood:
So what are the advantages of Typescript?
- We can define types and interfaces for our variables, objects and functions.
- We gain inheritance and composition for types and interfaces.
- We receive instant feedback (in supporting IDEs) about type conflicts when calling a function, using a variable or receiving an output.
- Typescript helps your IDE to give you more information and assistance with your code.
- We get some basic assistance during refactoring, as types and interfaces give us more confidence in our code.
- Typed code (with readable variable names) already offers a basic form of in-code documentation without a single line of comments.
- A certain amount of bugs can be caught earlier.
What will Typescript not solve/offer?
- Typescript will not catch all bugs in your code, especially when working with 3rd party APIs.
- Typescript is an extra abstraction for your code. While some programmers swear by it, a new hire might not be able to work on your codebase if they lack Typescript Know-How.
- Depending on your code-base, some edge cases might be hard to map with correct types/interfaces, leading to longer development time.
Before we move on, I'd like to quickly point out that from my experience, the last point on that "CON" list is often (not always) a sign of code smell, something that hints at "magic code" or stuff that is written either too complex or too clever to be good, stable and maintainable code.
This also brings us to one of my personal favourites about Typescript: it nudges us towards thinking more about the code we write, before we write it, not unlike TDD. When working with separate teams for Backend/API and Frontend code, predefining API contracts with Typescript allows us to mock data and work independently based on the formed API contract between both teams.
Keeping it very basic, Functional Programming is a programming paradigm that does not allow any mutations of data or uses any shared state. The main premise is that a function, run with identical input, will always return the same output and will not change any of the input values. It is declarative rather than procedural or imperative.
This paradigm makes functional code easily testable and predictable and often results in cleaner code, shorter functions and overall code that's easier to read and argue about on a human level.
Test-driven development is the software development practice of writing tests that match your expectations or requirements before you write the code to fulfil these.
TDD can fit in well with your existing agile workflow and has its roots in the Agile Manifesto.
A new feature should have a full description of the expected outcome. The team or developer can now transform these specifications into one or multiple simple (unit) tests based on their initial understanding and either check them manually or preferably integrate them with your automated testing. This will bring us to our first state: "RED" because these tests will now fail.
The second step is to write the most simple version of code to pass these tests. The idea is to make the most minimal change needed to pass these tests and reach the second state: "GREEN"
The third step is basically checking the existing code and tests for edge cases, performance issues and possible code optimisations and whether or not the initial feature requirements are fulfilled.
If you learned about unexpected issues during development, requirements changed or your new understanding of the task tells you that your tests need to be adjusted, you go back to the first step and adjust or add to your tests so that you will again get red test failures, iterating over these 3 steps until the task is feature-complete.
Existing tests from previous tasks will help you confirm that other code should not be affected by your changes.
Again, basically, anywhere you write code. There is a small reality check in this case though. The practice of TDD will create a larger up-front workload before you can finish a task and many programmers muse that TDD is something they would like to do but their day-to-day business does not allow them to follow these principles.
Depending on how much code coverage with unit tests your team is trying to reach and how much time you have available, TDD might be a lot of overhead at first and there is a strong bias against it. From my experience though, teams that adapted this practice, apply a good measure of common sense and strike a good balance between code coverage and team performance (GTD or getting things done), during the later development phases of such projects, the existing tests help greatly track new bugs early and before deploying to a client's server.
At the end of the day, this article will not try to pick the best of the 3 solutions but I will try to give my personal experience without going too much into detail.
All three are primarily solutions to build web frontends and interfaces but can be combined with many different CMS backends when needed.
While often used in concert with Angular or React, Redux can be used in other constellations too and resembles Facebook's Flux Architecture in many ways.
With only 2kb for the basic install, Redux is tiny but it can easily be extended with custom middleware and there are existing solutions for integrations of data fetching, and other asynchronous tasks. With the Redux Toolkit (RTK), developers are also freed from the burden of writing boilerplate code.
Again, this is a frontend library so no server-side to this either.
I hope this article helped you get some basic knowledge about some of the bigger buzzwords thrown around by recruiters, managers and some techies. I will follow up with two in-depth articles about typescript and functional programming, their PROs and CONs as well as some integration examples with other things from today's list such as React and Redux.
Das Büro am Draht is a Berlin-based consultancy helping our clients to build resilient and adaptable digital platforms to support today's business requirements and even launch tomorrow's business models we might not yet foresee. Hence, we work closely together at every stage of the digital transformation process - from digital strategy to solution design & development to operational support. Our agile approach to developing versatile and scalable solutions ensures that our clients consistently deliver engaging and personalized customer experiences. To learn more about how we help companies across industries, follow us on LinkedIn.