Julio Biason
5 years ago
4 changed files with 51 additions and 2 deletions
@ -0,0 +1,48 @@
|
||||
+++ |
||||
title = "Things I Learnt The Hard Way - Create Libraries" |
||||
date = 2019-07-15 |
||||
|
||||
[taxonomies] |
||||
tags = ["en-au", "books", "things i learnt", "libraries", "project organization"] |
||||
+++ |
||||
|
||||
One thing you must learn is how to break your project into smaller libraries, |
||||
to avoid doing rounds to deal with "the same, but a bit different". |
||||
|
||||
<!-- more --> |
||||
|
||||
I've seen a lot of projects that use things like branches for different |
||||
things. Say, you have an e-commerce page. But you also have different clients, |
||||
and they all have different colours and logo. Some people would take this |
||||
scenario and, using the VCS properties, use the main branch for the main code |
||||
and a branch for each client, merge from main branch from time to time -- and, |
||||
thus, the branches are never merged back. |
||||
|
||||
This is suboptimal, 'cause that's not how VCS are supposed to be used. |
||||
|
||||
But you can, for example, break the main code into a library/framework and |
||||
have one project for each client, with their assets and you just reference the |
||||
library/framework in each. |
||||
|
||||
Simple and clean. |
||||
|
||||
But stop there for a second. Although this makes the code cleaner, avoids |
||||
duplication and uses a VCS in the way it was supposed to be used, you can't |
||||
start this way. |
||||
|
||||
Remember that [future thinking is future |
||||
trashing](/books/things-i-learnt/future-trashing). What you can do is actually |
||||
break your project by functionality, [making modules related to their |
||||
data](/books/things-i-learnt/project-organization) and then, when you get a |
||||
reasonable number of clients, you'll notice what can be reused in each, what |
||||
modules make sense for one client and not for another. And then you'll have a |
||||
good way to deal with those. |
||||
|
||||
One project that may appear when creating libraries is "How do I create my own |
||||
library repository?" 'Cause all modern languages today have support for |
||||
importing external libraries and, even if your libraries will never be out of |
||||
your control, they are external to the project. So you may need to learn how |
||||
to deal with this before creating the libraries. And, unfortunately, each |
||||
language and build tool has its own way to manage this. |
||||
|
||||
{{ chapters(prev_chapter_link="/books/things-i-learnt/project-organization", prev_chapter_title="Organize Your Code by Data/Type, Not Functionality", next_chapter_link="/books/things-i-learnt/throw-away", next_chapter_title="Be Ready To Throw Your Code Away") }} |
Loading…
Reference in new issue