DEV Community: Menilek Techane

The Refactoring Dilemma: Tidy Now, After… or Never?

Menilek Techane — Fri, 28 Nov 2025 17:13:30 +0000

At work in my team we didn’t have an agreed upon approach to refactoring. Therefore, the question of how, when and why we refactor was left up to us which can lead to inconsistency and large Merge Requests (MRs) at a minimum and ~~utter despair and destruction~~ bigger issues that I’ll leave you to imagine😉

I recently read an informative book on the subject of refactoring called Tidy First by Kent Beck. Kent refers to a range of refactoring techniques which he calls ‘tidyings’ and argues that we adopt them as a form of ‘geek self care’ over the 122 pages of the book. The most pertinent part of the book concerning us, questions when should we refactor?

Before we discuss when and why, it is important to understand what kinds of changes we can make regarding refactoring aka tidying. Changes to a codebase can largely be split into either behavioural changes or structural changes. Behavioural changes are your feature requests and fixes which extend a system. Structural changes however, seek to maintain the existing behaviour within a system but augment the structure oftentimes for our own benefit.

For example, we may reorganise the order (aka flow) of code within a class/component/file to better aid our understanding. It is these structural changes that we are concerned with when we talk about refactoring. With this distinction in mind, let’s now address the when and why.

Consider the scenario where we are faced with introducing a feature request to an existing Platform system (remember this is a behavioural change). Let’s say we see some issues with the codebase whilst attempting to introduce this new behaviour. Maybe we notice that the functions we plan to extend lack types. Should we tidy first? In this scenario, the payoff is immediate and you know exactly what to do and how. Changes of this nature are like keeping the kitchen clean as we cook. This example is a no-brainer, of course we should tidy first - notice the change is small and can be completed immediately, unlike introducing typing across all functions in the repo (I’m guilty of this😅). Essentially, it is advisable to tidy first if it will make the behavioural change easier.

Tidying after making a behaviour change is a good option when tidying first doesn’t make sense. This may be because the code is quite tangled or complex so by making our change first, we’d gain a better grasp of how we could improve the structure. This is all dependent on the scale of the change(s). Kent Beck advises that we can tidy after, if the refactoring's are proportionate to the behavioural changes. For example, a 30 minute behavioural change would solicit a 30 minute structural change at a maximum. This seems very generous to me (especially when we consider bigger behavioural changes spanning days) but as a rule of thumb I’d advise that refactoring’s are smaller than the time taken to implement behaviour.

Kent goes on to argue that we should seek to tidy after a behavioural change when coming back later would be too expensive or if you wouldn’t feel a sense of completion submitting the work without this tidying. This would produce an MR combining a behavioural change with a moderately sized (at best) structural change.

The third option is to tidy later. This case is fitting when there is a big batch of changes required that offer no immediate payoff and would be better suited to a separate Merge Request. To phrase this another way, you can tidy/refactor in small batches and there is eventual payoff. Once I pushed a change to introduce types to functions across the board which added additional complexity to an MR I had raised. This was a big batch of changes with no immediate payoff. I was encouraged to instead document similar issues in a ticket to come back and make such a change later which prompted me to write this!

The final option is to tidy.. never! This is only appropriate when you’re never going to change the code again - for instance, we have some retired repositories that are unlikely to change. This option is reserved for the smallest number of cases as the majority of code we work with is living and changing which leads us to consider how we will agree to approach and apply the three former methods of tidying.

After reflecting on the above, I created the following proposal for my team:

An MR can include small ‘tidyings’ that offer immediate benefit. These may be introduced before or after the behavioural change of a feature/fix ticket.
If the structure change does not offer immediate benefit or is not related to the current behavioural change it can be documented in a ticket to be addressed later.

I’d love to hear your thoughts on this! How do you (and your team) handle refactoring code? Thanks for taking the time to read this🤓

TIL (Today I Learned): Tactical Vs Strategic Programming

Menilek Techane — Mon, 21 Oct 2024 16:42:42 +0000

I've recently splurged on some software development books and came across an interesting concept in A Philosophy of Software Design by John Ousterhout. Have a read and consider which approach you and your team members practice.

What is Tactical Programming?

As a developer one of your primary goals is to implement and release working code. The Tactical developer works fast and can oftentimes produce more features/bug fixes than their Strategic counterparts. However, the Tactical developer encounters issues within the codebase and takes the short-sighted view to patch over the issues instead of addressing them. In this approach, issues aren't resolved or refactored and instead additional complexity is introduced by extending poorly designed code to introduce their code. We call this complexity: technical debt. They then kick the can down the road when it comes to refactoring 'the big ball of mud' that the codebase has become.

What is Strategic Programming?

The tenet that 'working code is not enough' sufficiently distinguishes Strategic developers' approach from the Tactical developer. Here, the goal is a great design. Taking a long term view of the codebase considers how to introduce the change whilst also resolving issues along the way. You can think of a Strategic developer as a Steward of your codebase, ensuring the long term health of the code and thereby reducing complexity and technical debt where possible. This might be through proactive investment such as planning the design and weighing up the options before beginning implementation. Alternatively, this could be the result of reactive investment by refactoring an issue encountered during a change.

Contrasting Strategic and Tactical approaches

Tactical programming is faster in the short term and has a time and place for instance, producing a proof of concept to validate a concept. However, the shortcuts taken to produce software using this approach will eventually work against yourself and your team resulting in incremental degradations in productivity.
Strategic programming will prove to be slower initially. This can be down to proactive planning prior to implementation of a feature or due to the improvement of poor design encountered whilst attempting to introduce a feature. Yet, it is these investments of time that will add up over the course of time to benefit developer productivity and gradually reduce technical debt.

Tactical programming in the Wild

John Ousterhout coined the term 'Tactical Tornado' for the individual that takes tactical programming to the extreme. This takes the old Facebook motto, 'Move fast and break things' to its limit. Even Facebook realised, with time that this motto was not serving their best interests as the quality of their codebases degraded. The motto then changed to 'Move fast with stable infrastructure', then simply 'Move fast' and now 'Move fast together'. Tactical Tornadoes might be praised by management for their high output, but those that work alongside them will oftentimes have to pick up the slack by addressing their poorly designed code. This, then makes the team members look slow in contrast and exacerbates the relationships within the team and management.

My experience

I have experienced both approaches whilst working as a developer. Occasionally, the needs of the business pressure folks to prioritise speed, this is especially true within Startups, unfortunately leading to new technical debt. A good code/peer review process will push back against some changes with a preference for a more strategic approach e.g: Why is it designed like this? Can we try such and such approach instead please.

Conclusion

After reading this, I hope you gained some value. I have been guilty of programming tactically in the past and appreciated the examples within the book. I would love to hear how you mitigate tactical programming within your place of work. My personal favourite is a great peer review process however, sharing this concept with my team could reduce complexity and tactical programming prior to it reaching the peer review stage.

Transform your Flashcard Carousel into a Progressive Web App (PWA) in an evening

Menilek Techane — Mon, 30 Oct 2023 19:34:25 +0000

Good evening internet! This is my second blog post in what has surprisingly become a series. In the first post (read it here), we created this flashcard application (try it here) with the intention of helping language learners learn words of interest using Vue, Vite and Vercel. In this post we will extend the application by turning it into a Progressive Web App (PWA) all in a single evening!

What exactly is a PWA?

PWAs bring the best of both worlds from platform specific apps (IOS & Android) and web apps into one solution. PWAs can be downloaded and installed directly from the browser or via the App/Play Store and appear on the device like any other app. My favourite benefit of PWAs is that they can be used without network connectivity. This is mighty helpful for this app and many others when I'm travelling and want to cram in some last minute revision but don't have access to the internet. For example, you might be on a plane or bored on a train and can't access your mobile data/a WiFi network.

Getting started

You can find the respository here.

Before we dive in, please note that the main branch runs the flashcard app and the PWA branch offers the complete flashcard PWA. Our goal in this tutorial is to learn what a PWA is and the steps we must take to transform our web app into a progressive web app.
If you are following along from the first tutorial great, though, we will spend less time focussing on deploying the app in this tutorial. For the sake of simplicity, complete your work on the main branch as this will make deployments smooth (unless you're a wizz with Vercel and know how to configure builds from other branches).

Clone the repository then let's get started! 🤓

Installing vite-plugin-pwa

Vite has a plugin that converts a Single Page App (SPA) into a PWA. This is awesome and very versatile as it isn't restricted to working with Vue (the JavaScript (JS) framework used in this tutorial), React or any other JS library/framework supported by Vite.

Issue the following command within your terminal/command windows within the repository:

npm i vite-plugin-pwa --save-dev

Now that vite-plugin-pwa is installed we can add it into our vite.config.js file like so:

import { VitePWA } from "vite-plugin-pwa";

export default defineConfig({
  plugins: [
    vue(),
    VitePWA()
  ]
})

Transforming our application

Now we can begin the serious work of turning our app into something that we can install on our devices. PWAs have a number of requirements that we must meet to enable us to install our app locally.

We will now take the steps to figure out the necessary requirements for our PWA. Let's build our app using the npm run build command in the terminal. Once this is complete inspect the output in your terminal; you will see the following:

building for production...
✓ 15 modules transformed.
dist/registerSW.js               0.13 kB
dist/manifest.webmanifest        0.17 kB
dist/index.html                  0.57 kB │ gzip:  0.34 kB
dist/assets/index-200d626d.css   3.29 kB │ gzip:  1.05 kB
dist/assets/index-27c61d9b.js   64.32 kB │ gzip: 25.25 kB

PWA v0.16.5
mode      generateSW
precache  5 entries (66.72 KiB)
files generated
  dist\sw.js
  dist\workbox-27b29e6f.js
✓ built in 3.07s

Now that the built application has been generated, issue the npm run serve command to view the app in your browser. It is typical for web apps that can be installed as PWAs to indicate this with an install icon within your browser's search bar like so:

As this is not yet available to us we must investigate why. We can use the Developer Tools to view the Application tab for insights and errors like so:

We have a number of errors that we must first resolve before we can attempt to rebuild our app and check if it can be installed again. The errors we have received concern our web app manifest (this was one of our build outputs: manifest.webmanifest). VitePWA enables us to provide a manifest object to the VitePWA plugin in the vite.config.js file, feel free to explore the VitePWA docs to learn more here.

The Web App Manifest

This is a set of criteria that informs the browser that the app can be installed and information about said app. This includes but is not limited to:

name, short_name and description
theme_color, background_color and display
icons and optionally screenshots

To learn more about potential members of the manifest file check this out.

We must now populate the aforementioned fields. Within the public directory some icons and screenshots have been provided. We can reference these within our manifest. You may want to include your own icons and screenshots. You can generate your own icons for your PWA here.

Within the VitePWA plugin in the vite.config.js file add the following:

export default defineConfig({
  plugins: [
    vue(),
    VitePWA({
    manifest: {
        name: "French Flashcards",
        short_name: "Français Flashcards",
        description: "Install this flashcard app for quick reference on the go! \nAvoid loading this again and again; train your mind whenever you feel like it, even when you don't have an internet connection!",
        theme_color: "#ffffff",
        background_color: "#ffffff",
        display: "standalone",
        icons: [
        {
            src: "/192x192.png",
            sizes: "192x192",
            type: "image/png",
            purpose: ""
          },
          {
            src: "/512x512.png",
            sizes: "512x512",
            type: "image/png",
            purpose: ""
          }
        ],
        screenshots:[
          {
            src: "/narrow-screenshot.jpg",
            sizes: "438x841",
            type: "image/jpg",
            form_factor: "narrow"
          },
          {
            src: "/wide-screenshot.png",
            sizes: "1280x668",
            type: "image/png",
            form_factor: "wide"
          },
        ]
      }
    })
  ]
});

Again, you may wish to update the manifest with screenshots of your own. Please ensure that the sizes and file formats accurately reflect those of your screenshots. The Applications tab in the Dev Tools might inform if they do not meet the necessary criteria.

With the manifest object populated, let's build the app again using npm run build followed by npm run serve to preview the newly generated build. There should be no errors, if there are you will need to follow the suggestions in your Dev Tools then repeat this build and serve process until they are all resolved.

Installing our application

Now that the code is complete the next step is to install the app. Click the install icon within the browser's search bar (if you are on a desktop/laptop) and you will be presented with the following:

Alternatively, on a mobile this will be your view!

Once you are happy with your code, commit it and push your changes. If you are following along from the first tutorial, Vercel will pick up these changes and deploy your new PWA!🎉

This concludes the tutorial! Thanks for reading and following along. As always, I'd love to hear how you got on and any ideas you have to take this app to the next level!🚀

Create a French Flashcard Carousel in an evening

Menilek Techane — Sun, 22 Oct 2023 22:01:05 +0000

Hello internet! This is my first blog post and we will be building a mobile friendly French Flashcard application (try it here). If you are learning a language or gearing up for travel this simple tool is for you.

Introduction to Vue, Vite & Vercel

Vue 3, in it's own words: is a progressive framework for building user interfaces. Vue enables developers to create dynamic Single-page Applications (SPA) that rewrite the current web page with new data from the application's web server. This approach to web development sees us advance from creating many HTML pages and loading them with our web server ultimately producing an increasingly seamless process more akin to a native app.

What is Vite I hear you ask, Vite is french for 'quick' and is a build tool we will use to bundle and serve our application. If you are familiar with Webpack, the Vue-CLI or even Create-React-App this will feel like a Concorde amongst Pigeons!

Last but not least, Vercel is a platform that boasts the ability to provide a frictionless developer experience when deploying and serving our application's content. This is what we will use to host our application.

Prerequesites

Before we get started it is important to note that this article assumes a good grasp of JavaScript. You will need both Node version >=12.0.0. and NPM installed. A familiarity with Vue is helpful but not essential though worry not, we'll have code samples galore and an accompanying repo available here. Now let's get started!

Scaffolding our App

First we need to scaffold our Vue app with Vite. Use the following command and select Vue.

npm init vite@latest

We will go ahead and use Vue without TypeScript for now.

Once we've completed the above we can navigate into our application's directory, run npm install and top it off with npm run dev. Your browser should popup displaying boilerplate output like so:

Installing Vue3-Carousel

We will use the awesome Vue3-Carousel to create our flashcard Carousel. First, we need to install it using:

npm install vue3-carousel

Next up we want to create a carousel.css file in the assets folder within the src directory. This will style all of our carousels, go ahead and paste the following inside it:

.carousel__slide>.carousel__item {
  transform: scale(1);
  opacity: 0.5;
  transition: 0.5s;
}
.carousel__slide--visible>.carousel__item {
  opacity: 1;
  transform: rotateY(0);
}
.carousel__slide--next>.carousel__item {
  transform: scale(0.9) translate(-10px);
}
.carousel__slide--prev>.carousel__item {
  transform: scale(0.9) translate(10px);
}
.carousel__slide--active>.carousel__item {
  transform: scale(1.1);
}
.carousel__item {
  min-height: 200px;
  width: 100%;
  background-color: var(--vc-clr-primary);
  color: var(--vc-clr-white);
  font-size: 20px;
  border-radius: 8px;
  display: flex;
  justify-content: center;
  align-items: center;
}

Creating our Carousel

Vue 3 components allow us to define JavaScript functions, templates for rendering our page and styles all in one place! Go ahead and create a Days.vue component within the components directory like so:

This component will be responsible for rendering the French words for Monday through to Sunday. We need to import the newly created carousel.css file as well as some Components from Vue3-carousel using the below snippets then we can begin defining our functions and rendering the Carousel. We will need to add the following to our Days.vue component within the script tags:

import { Carousel, Slide, Pagination, Navigation } from 'vue3-carousel';
import 'vue3-carousel/dist/carousel.css';
import '../assets/carousel.css';

Within Vue components we can use the content defined within the Script tags to help us render output within our Template tags.

Now, our application requires some French content (feel free to deviate and put a Spanish/Mandarin/Amharic spin on this)! We shall begin by creating an object that will hold the day in English as a key and the day in French as the corresponding value. Let's call it FrenchDays and define it using the sample below:

const FrenchDays = {
    Monday: "Lundi",
    Tuesday: "Mardi",
    Wednesday: "Mercredi",
    Thursday: "Jeudi",
    Friday: "Vendredi",
    Saturday: "Samedi",
    Sunday: "Dimanche"
}

Congrats! You've made it to the fun part where we get into the cool parts of Vue.js and render our Carousel. We've got our FrenchDays object (or whichever language you've chosen you cheeky polyglot!) and we want to loop through these and create a slide for each word aka value in our object.

Vue has a special directive just for this called v-for, see more here. This directive allows us to iterate through the properties of an object. There is a lot going on in the code below so we shall dissect it step by step:

    <h2>Days</h2>
    <Carousel :itemsToShow="2" :wrapAround="true">
        <Slide v-for="day in FrenchDays" :key="day">
            <div class="carousel__item">{{ day }}</div>
        </Slide>
        <template #addons>
            <Navigation />
            <Pagination />
        </template>
    </Carousel>

Let's examine the Slide component. This is using the v-for directive to iteratively create Slides for each property in our FrenchDays object. You might also notice this: :key="day" what this does is give each Slide a unique key. This key helps Vue determine what has changed within the virtual Document Object Model (DOM) and what hasn't.

If you are interested in learning what the Navigation and Pagination components are or what the itemsToShow and wrapAround props are feel free to play with their values or refer to the Vue3-Carousel docs here.

Ok, we've done a lot of work, what do we have to show for it so far? We'll need to render our Days component to see what all the fuss is about first! In the App.vue file within the root of our /src directory we want to make some changes as this currently renders the boilerplate HelloWorld.vue component generated by Vite. Instead we want to import and render the Days component and we will do this with the following:

<script setup>
  import Days from './components/Days.vue'
</script>

<template>
  <Days />
</template>

<style>
#app {
  font-family: Avenir, Helvetica, Arial, sans-serif;
  -webkit-font-smoothing: antialiased;
  -moz-osx-font-smoothing: grayscale;
  text-align: center;
  color: #2c3e50;
  margin-top: 60px;
}
</style>

After we save, Vite will quickly pull in our changes and our browser should show us:

Toggling the Language

We are nearing the final hurdle. How do we toggle between French and English? There are many ways in which this can be implemented (and I am curious how you might have done it; please do share in the comments 🤓) but we will always require a user clicking/tapping on a Slide within our Carousel to kick off the change. As always, Vue has a directive for that named v-on:click or better yet @click.

Essentially, we require a click event that will trigger a function that toggles our French word into English and vice-versa. We also need a way of knowing which word is being shown so that we know which word to show when clicked. Let's update our Slide component within Days.vue by adding the click directive and a function we want to trigger.

<Slide v-for="day in FrenchDays" :key="day">
    <div class="carousel__item" @click="toggle(day)">{{ day }}</div>
</Slide>

We also need a way to determine whether a flash card shows English or French. This will allow a single flashcard to toggle without toggling all of the flashcards - this will ensure we don't spoil our language learning fun!

We will track the state of a flashcard using a Ref. Refs let us create variables enriched with the power of reactive and mutable reference objects, what that means is that if there is a change to the value of such a variable it will be detected and trickle down to anywhere else that uses that variable, notifying it of the new value. One thing we need to note is that with the introduction of reactive variables in Vue3 using ref, we must use .value to access their values inside our script block, though this is not the case inside our template (we'll see this in action later).

First we need to import ref from Vue like so: import { ref } from 'vue'; within the script tags in our Days.vue file.

To make use of ref we can define the following:

const MondayRevealed = ref(false);
const TuesdayRevealed = ref(false);
const WednesdayRevealed = ref(false);
const ThursdayRevealed = ref(false);
const FridayRevealed = ref(false);
const SaturdayRevealed = ref(false);
const SundayRevealed = ref(false);

So far so good, time to begin defining the toggle function. The purpose of the toggle function is to invert or toggle the boolean value of a flashcard. Currently, these have all been set to false by default.

This could be implemented in a number of ways. Using if/else statements or a switch statement are viable options but I recently stumbled upon a way to achieve this succinctly using object literals! I will link to a very handy article here.

Depending on which day/card a user clicks determines which day/card we want to toggle; thereby toggling the boolean value for that day e.g MondayRevealed now equals true.

const toggle = (day) => {
    const dayMap = {
        Lundi: () => MondayRevealed.value = MondayRevealed.value ? false : true,
        Mardi: () => TuesdayRevealed.value = TuesdayRevealed.value ? false : true,
        Mercredi: () => WednesdayRevealed.value = WednesdayRevealed.value ? false : true,
        Jeudi: () => ThursdayRevealed.value = ThursdayRevealed.value ? false : true,
        Vendredi: () => FridayRevealed.value = FridayRevealed.value ? false : true,
        Samedi: () => SaturdayRevealed.value = SaturdayRevealed.value ? false : true,
        Dimanche: () => SundayRevealed.value = SundayRevealed.value ? false : true
    }
    dayMap[day]()
}

Let's break down some of these lines:

Lundi: () => MondayRevealed.value = MondayRevealed.value ? false : true

This lines run if the day clicked on is Lundi (French for Monday) then the value for MondayRevealed is updated with the use of a ternary operator.

dayMap[day]()

On the line above we are invoking the function that corresponds to the value of the key equal to the day passed as an argument. E.g if we were to pass in Jeudi this would match the following
() => ThursdayRevealed.value = ThursdayRevealed.value ? false : true

We now have our Carousel and a toggle function; the only thing that remains is a way to show the translated word. This will involve retrieving the English day for a given French day and rendering this within our template.
Luckily enough we have an object named FrenchDays consisting of the days in French and English and must now create a function that will return the English word for a given French day.

To retrieve the corresponding English key for a French value within the FrenchDays object we have to...

const findKey = (obj, value) => {
    return Object.keys(obj).find(key => obj[key] === value);
}

Now that we can find the English word for a French word in our FrenchDays object we can move onto figuring out how we can render this in our template. This is where the use of our boolean variables comes in handy. To illustrate, imagine we click on Mardi (Tuesday in French), this will toggle the value of TuesdayRevealed to true and if this value is true we want to show the English for that word.
To implement this we can use an object literal again. This time we can accept the day value and map it to the corresponding boolean value.

const isWordRevealed = (day) => {
    const revealMap = {
        Lundi: MondayRevealed.value,
        Mardi: TuesdayRevealed.value,
        Mercredi: WednesdayRevealed.value,
        Jeudi: ThursdayRevealed.value,
        Vendredi: FridayRevealed.value,
        Samedi: SaturdayRevealed.value,
        Dimanche: SundayRevealed.value
    }
    return revealMap[day];
}

We can now use isWordRevealed to render the correct word within our Carousel like so:

<Slide v-for="day in FrenchDays" :key="day">
    <div class="carousel__item" @click="toggle(day)">{{ !isWordRevealed(day) ? day : findKey(FrenchDays, day); }}</div>
</Slide>

We can go one step further to tidy up our template expression as there is a lot going on within the curly braces. Instead we can store the value within a variable and render that variable within our template like so:

const dayToShow = (day) => !isWordRevealed(day) ? day : findKey(FrenchDays, day);

<Slide v-for="day in FrenchDays" :key="day">
    <div class="carousel__item red" @click="toggle(day)">{{ dayToShow(day) }}</div>
</Slide>

You should now be able to toggle each flash card independent of the others! 🎉

A little challenge would be to add flashcards for months, numbers and the seasons! In the gif above you can see I've gone ahead and added months in already.

Deploying our Flashcard application

The final piece of the puzzle is to deploy the application. We will do this using Vercel. Before we do this, ensure that you've committed and pushed all your changes to a repository in your Source Control Management provider of choice (Github, Gitlab, Bitbucket etc).

If you don't already have a Vercel account sign up using the link here and then select your Git provider. By connecting to your git provider instead of using your email you can smoothly deploy your project in a couple of clicks.

After selecting your git provider, you will be prompted to select your project to deploy. Select your flashcard application then you'll be prompted by a screen to configure the application. There is no special configuration required for this simple app so we will be good to go with the default options. Click the Deploy button and behold the magic!

Congratulations! You have now deployed your flashcard application. Continue to the Dashboard and click the Visit button to see your work in all it's glory.

This concludes the tutorial! Thanks for reading and following along. I would love to hear your thoughts, how you used this project and any potential changes you added in the comments. Merci beaucoup 😁

Stay tuned for the next post in the flashcard series where we will turn this app into a Progressive Web App (PWA)! Suggestions on further extensions to the app are more than welcome. Au revoir😊