Browse Source

New Chapter: libraries

master
Julio Biason 5 years ago
parent
commit
e07a459da7
  1. 1
      content/books/things-i-learnt/_index.md
  2. 48
      content/books/things-i-learnt/libraries/index.md
  3. 2
      content/books/things-i-learnt/project-organization/index.md
  4. 2
      content/books/things-i-learnt/throw-away/index.md

1
content/books/things-i-learnt/_index.md

@ -35,6 +35,7 @@ template = "section-contentless.html"
* [One Commit Per Change](one-change-commit) * [One Commit Per Change](one-change-commit)
* Project Organization * Project Organization
* [Organize Your Code by Data/Type, Not Functionality](project-organization) * [Organize Your Code by Data/Type, Not Functionality](project-organization)
* [Create Libraries](libraries)
* Writing code * Writing code
* [Be Ready To Throw Your Code Away](throw-away) * [Be Ready To Throw Your Code Away](throw-away)
* [Future Thinking Is Future Trashing](future-trashing) * [Future Thinking Is Future Trashing](future-trashing)

48
content/books/things-i-learnt/libraries/index.md

@ -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") }}

2
content/books/things-i-learnt/project-organization/index.md

@ -81,4 +81,4 @@ transformations and such, but without the Data3 part). By breaking by their
types, I managed to create small modules for each one and the new project types, I managed to create small modules for each one and the new project
would simply reference Data1 and Data2, but not Data3. would simply reference Data1 and Data2, but not Data3.
{{ chapters(prev_chapter_link="/books/things-i-learnt/one-change-commit", prev_chapter_title="One Commit Per Change", next_chapter_link="/books/things-i-learnt/throw-away", next_chapter_title="Be Ready To Throw Your Code Away") }} {{ chapters(prev_chapter_link="/books/things-i-learnt/one-change-commit", prev_chapter_title="One Commit Per Change", next_chapter_link="/books/things-i-learnt/libraries", next_chapter_title="Create Libraries") }}

2
content/books/things-i-learnt/throw-away/index.md

@ -39,4 +39,4 @@ And not just code that solves the problem, but also the tests for that code.
... unless you focus mostly on [integration ... unless you focus mostly on [integration
tests](/books/things-i-learnt/integration-tests). tests](/books/things-i-learnt/integration-tests).
{{ 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/future-trashing", next_chapter_title="Future Thinking Is Future Trashing") }} {{ chapters(prev_chapter_link="/books/things-i-learnt/libraries", prev_chapter_title="Create Libraries", next_chapter_link="/books/things-i-learnt/future-trashing", next_chapter_title="Future Thinking Is Future Trashing") }}

Loading…
Cancel
Save