The early days of a new software project can be challenging.

There are a gazillion things to think of, and deciding where to start is a nerve-wracking moment.

No wonder you want to get past this phase as quickly as humanly possible.

Turns out it doesn’t get that much better towards the end either — applying application code changes requires a fair amount of time too.

Here are four simple steps to get around these bottlenecks and improve your software delivery performance.

1. Standardize the Process

Want to start your software project without unnecessary fuss and stress? Standardize your starting process for all the projects, and you’ll get your wish.

Going through all the possibilities each and every time is a Sisyphean task — not only do you waste your precious time, but you also slow down the developers.

If you’ve already tested several options, choose those most suitable for your business and make use of them. Think about aspects like:

  • development framework,

  • architecture,

  • software environment,

  • code organization, and

  • folder structure.

The standardization of procedures will save you hours of tedious work, lower the threshold of entry for developers, and streamline workflow.

2. Create a Project Bootstrap

Yet another idea to get your project started off on the right foot is a bootstrap. One developer should start the initial bootstrap, which must contain the bare minimum specified by the whole team. After the repository creation, more developers can join the project and start enriching it.

It’s a good idea to practice, test solutions, and foster a cooperative culture.

The bootstrap can transform into a more robust and generic solution  — a template with configurable options or a starting point for the next projects.

3. Use Universal Solutions

Hand in hand with standardizing your process is using universal programming languages, frameworks, and technologies.

Find the ones that are not tied to a specific programming platform or focus — they should be applicable for the majority of your projects — and that are well-known to your engineers or can be introduced and used universally later on. It will shorten the learning curve for new hires or new team members and make project onboarding easier.

Here are some solutions I find useful for my projects:

  1. Top front-end frameworks, such as Angular, React, and Vue.js.

  2. Library for managing application state: Redux.

  3. Reactive programming libraries: RxJS and redux-observable.

  4. Library for deriving data: reselect.

  5. Keeping the code in good shape: TypeScript.

To create the list for your business, consult your in-house developers.

4. Apply Layered Architecture

It doesn’t matter how quickly you get your project off the ground if your end product is not adaptable. 

The business world is changing at a fast pace — new UI/UX trends and market regulations are emerging on a regular basis. Your software architecture needs to be ready to embrace change.

The easiest way to get there is the layered architecture. 

This pattern brings three major benefits:

  1. You can make design changes faster.

  2. Changes in one layer don’t affect other layers.

  3. You can maintain code stability over time.

Split your application into the visual and data layer, and you’ll be able to manage your software infrastructure with no difficulty. 

How it Works for Us

As true believers of this approach, we follow these four steps whenever possible. To help you grasp the idea, I’ll share a few examples of their practical implementation.

One of such is the folder structure we use.

 
Copy of Last (4).png
 

We’ve structured folders in a pattern of “{appName}-app” and “{appName}-lib.” The ”app” part represents all the components from the visual layer. The “lib” folder is for the data-layer handling. Every folder under the “lib” has a similar structure and represents its own business part of the app. 

We’re using Redux in our projects with a couple of supporting libraries listed under universal solutions. 

One of them is “reselect” for getting data from a Redux store. See more at https://github.com/reduxjs/reselect. 

 
Copy of Last (3).png
 

Let’s dive deeper into the project structure:

src/
  PROJECT_NAME-app/
    * This folder should contain the main App Module
    * Structure of folders here should more or less represent the structure of components in the application
  PROJECT_NAME-components/ 
    * Module with reusable components, directives, and pipes
    * - it can be divided into few modules
    * - do not import this module(s) in App Module
  PROJECT_NAME-lib/ - Main application logic
    * Example folders, it's not necessary to create them for the initial bootstrap:
    api/       - abstract DAO
    auth/      - authentication module and guards; actions, effects, and reducers for managing the “auth” store branch, etc.
    store/     - folder for the Redux store model, initial state, combined reducers, and effects
    translate/ - i18n module
    users/     - actions, effects, and reducers for managing the “users” branch in-store; dao, dto for calling BE API
      * Folders like “auth” and “users” should be one per BE resource
    utils/
      * Utils, helpers, etc.
    styles/
      * Main style variables and mixins. It should be created with the tool or bash script.

Let’s use a front-end application written in React.js with Redux in Typescript as an example. The application shows a list of the employees of the company. 

The folder structure could look like that:

folder_structure_under_lib_example.png

As you can see, there is a folder called “Person,” which is related to the employee list mentioned above.

The rest of the folders represent other important parts of modern front-end applications:

  • “i18n” for language support,

  • “router” for routing,

  • “toast” for notification banners for users, and

  • “epic.ts” files that represent “epics” from redux-observable (visit the library source page to learn more).  

The whole “-lib” folder remains untouched, and we can remove the “-app” folder and build from the ground up. We can refactor it or change the entire implementation. The data layer sits untouched, and we can easily connect it to the newly created visual layer from the “app” folder. 

Every visual component can get all the data it needs using selectors. That is the only thing that “interests” them in the data layer. This is a perfect use of the SoC (Separation of Concerns) — one of the most important programming design patterns.

 
Robert-Duraj.png
 

Our React Native and frontend developer, Robert Duraj, has been working on a tool that generates projects based on the architecture described above. The tool — currently in the beta phase — uses the command “generate,” which can be run with yarn or NPM.

The tool asks us to specify which layer it should use to generate an additional part of the application. For example, the tool asks whether our request applies to the “data-layer,” to which we can answer yes. Then, we need to give the name of the added element and, eventually, decide which components are to be placed in the newly created folder. By default, all the available components I mentioned before are added.

After approval, the tool adds the new folders, new files, and base content with the given name. We can refine these files in the next steps.  

This solution allows us to avoid time-consuming copy-pasting and renaming files and variables while adding a new “branch” — a new subfolder linked to a newly added functionality in the application. 

In a nutshell, it automates the task of adding new elements of the application — based on the structure described in this article — instead of requiring us to create them manually.