A private repository provides a mechanism to distribute and manage packages.

This article demonstrates that there are significant advantages to breaking your application into packages and once you do, you should be using OnePub.

The changes required to get the demonstrated ROI (return on investment) are small and simple to integrate into your existing workflow. Payback is almost immediate and cumulative.

Executive Summary

OnePub allows and perhaps more importantly, encourages your team to break code into smaller more manageable modules.

A package-based modular design has the following benefits:

• increase your ability to move staff between projects

• reduce the cost of onboarding new staff.

• reduce development and maintenance costs

• reduce wastage caused by code duplication

• create an asset, by building a library of reusable IP

• Improve customer satisfaction

OnePub makes each package visible via your OnePub organisational portal along with API documentation, discussion threads and update notifications.

A modular design and greater visibility; reduce the cognitive load required to understand any piece of code, increases the chance of code reuse, allow greater mobility of developers between projects, reduce bugs, and decouple code - prompting more fluid release schedules, that together, reduce costs, increases customer satisfaction and improves the bottom line.

Using OnePub to help implement a modular code base is low-cost, quick to implement and non-disruptive to the development environment allowing it to be introduced at any point in a project’s life cycle.

Productivity gains are immediate and cumulative.

Using OnePub to promote a modular design allows increased staff flexibility, improves the bottom line and improves customer satisfaction with only a minimal investment and almost no staff training.

OnePub provides end-to-end encryption, multi-region backups and operates across multiple tier-one cloud providers.

For organisations that need greater control over their code, OnePub has a dedicated offering that can run on your own cloud or internal servers (conditions apply).

Contact: sales@onepub.dev for pricing and conditions.

The detail

OnePub encourages your team to take a more modular approach to development by breaking code out into small, single-concern packages.

Modular design is not a new concept and the advantages are well documented:

http://gwentechembedded.com/the-advantages-of-modular-software-and-programming/

The use of packages in Dart helps to enforce a modular approach by creating a ‘clear boundary’ around each package. Using packages makes it much harder to create entangled code as you need to explicitly decide to call into another package by adding a dependency. This ‘boundary’, stops the accidental entanglements common in monolithic code bases.

So what are the advantages of breaking your app into packages?

The summary items are:

• separation of concerns makes code easier to understand

• easier to test

• faster build/release pipelines

• flexible resourcing

• improved code reuse/reduced duplication

• simplified release cycles via decoupling

• fewer bugs

• vendoring - remove roadblocks caused by problems in third-party packages

• Improved documentation

• creates an asset, not just a code base

• Improved project velocity

• direct efficiency gains/cost savings on development

Is it easy to do?

Before we get into the details, let's just shoo away the elephant in the room. With Dart, breaking code out into a separate Dart package is easy to do. You can create a new package and publish it in under five minutes and it requires little expertise.

OnePub is a Dart native, so there is no need to install additional tools/languages into your development environment.

Separation of concerns

Human static analysis (reading code) is a key part of developing and maintaining an application.

The larger the code base, the harder static analysis becomes as it is hard to know what code needs to be considered within the scope of the problem.

Breaking code into smaller, digestible packages, creates a clear boundary, making developing and maintaining the code easier as it becomes viable to understand the entire code base.

Packages support ‘separation of concern’ by eliminating ‘accidental’ entanglement that is common in a monolithic application.

Easier to test

Smaller packages are easier and faster to test. They can also be tested out of the cycle of the main application.

Small discrete packages tend to have fewer test dependencies making for a simple test environment.

Faster build/release pipeline

If you test each of your packages as you release the package, then you don’t need to retest the package as part of your main applications release pipeline.

This results in a faster test/release process and faster build times for developers improving developer productivity.

Commits are easier to merge as the set of tests that need to pass are smaller and there is less code in flux that you are testing against.

Releases become easier as each of the parts are decoupled so less coordination across the entire team is required.

Flexible resourcing

Complex code bases tend to create reliance on single developers who are perceived as possessing critical knowledge, making organisations dependent on them.

This often leaves an organisation hostage to key resources.

Breaking code into smaller, modular, packages, reduces the complexity of any single piece of code. Small modular packages make it easier to move developers between packages and save an organisation from falling foul of Developer Stockholm Syndrome.

Developer Stockholm Syndrome is where management feels compelled to let a developer run riot, for fear of losing them because they are perceived as irreplaceable.

You can now move resources between packages as and when required rather than waiting for a key resource to become available.

Packages also reduce the cost of onboarding new staff. Less complexity and improved documentation allow new developers to be put to work and operate at higher levels of productivity in shorter periods of time.

Improved code reuse

Code duplication is a serious problem, particularly as your applications grow. It increases costs at every phase of development with more code to develop, test, maintain and debug.

Breaking your code into smaller packages makes the code more visible, particularly if you use a system like OnePub where all of the packages are stored in a single searchable location along with API documentation and package discussions.

The common developer aversion to using someone else's code is greatly reduced if the code is contained in a well-documented package with a small and easy-to-understand public API.

Code duplication is common and a serious drain on development resources.

Simplified release cycles

Even if a package is being used in a single project; packaging allows the maintainers to release their package on their schedule.

Decoupling release cycles, through the use of packages, removes bottlenecks and improves the velocity of development.

Packaging becomes even more valuable if you are using packages to share code between projects.

Each time you publish a package to OnePub, a new ‘versioned’ copy of the package is created.

Each project can depend on a separate version of a package and upgrade to the latest version when it suits their production schedule.

Feature branches in git can provide some of this flexibility but feature branches bring complexity and risk with them. The feature team needs to wait for a suitable merge window to release their code. Merging a feature branch is often a fraught process, the main branch will have moved forward, necessitating a git rebase and mistakes during a merge can result in bugs being introduced.

Separate packages eliminate all of these problems.

If a package’s public API changes, then the application team can choose a time, that suits their release schedule, to upgrade to the new version.

With a monolithic repo, releases require every team to be synchronised.

Decoupling your release cycles allows you to deploy more often, delivering new features faster.

Fewer bugs

This one speaks for itself. If we can reduce code duplication, then the code we have will be used more, bugs will surface faster and can be eliminated earlier in the development life cycle. It can also remove the need to fix the same bug multiple times.

Vendoring

The Dart ecosystem is still maturing and it's not unusual to find a package that you depend on, which needs a bug fix or a dependency update.

Not all open-source maintainers can assist you in the time frame that your project requires.

OnePub allows you to fork the package, fix the problem and then publish it to OnePub as a private package (referred to as vendoring a package).

Your team gets to move forward and once the original package is fixed, you can revert to the public version.

Improved documentation

OnePub automatically generates API documentation for each published package.

The documentation for all of your packages can now be found in one place and is easier to search.

Visible documentation yields better quality documentation.

When a developer knows their documentation is going to be visible, they tend to write better documentation.

Smaller ‘single concern’ packages are also easier to document.

Improved documentation has flow-on effects, such as reducing the cost of onboarding and allowing the movement of resources between projects.

Create an asset, not a code base

For many companies, their code base is one of their most important (and expensive) assets.

Burying code in a monolithic repo decreases its value because it's hard to find, entangled and hard to understand.

Using OnePub and publishing (internally) creates a searchable asset register, it becomes the ‘goto’ location for when developers need a solution.

OnePub transforms your code base into a visible, reusable, corporate asset.

Improved project velocity

This is essentially a feature that emerges from the combined benefits we have already discussed.

Better documentation, easier maintenance, better staff utilisation, faster onboarding and a decoupled release cycle all combine to increase project velocity.

Direct efficiency gains/cost savings on development

And with improved velocity comes cost savings, an improved ROI (return on investment) and greater customer satisfaction.

Conclusion

Breaking your code base into small ‘single concern’ packages is simple, quick and will drop into your existing development methodology with little effort and virtually zero training.

OnePub is Dart native and the OnePub website is modelled on pub.dev so your team is already familiar with the tools.

Breaking code out into separate packages only takes minutes and the payback is virtually immediate and the gains are cumulative.

If you are looking for ways to increase velocity it might be time to take up OnePub’s free trial offer and see the improvements for yourself.

Consulting Services

Still a little hesitant?

OnePub offers consulting services to help your team improve velocity by identifying code to be moved into separate packages and achieving the most out of your OnePub system.

Contact sales@onepub.dev