From c230327e1e87da162853cfc1680a9e1292853a45 Mon Sep 17 00:00:00 2001 From: Julio Biason Date: Mon, 15 Jul 2019 12:15:09 -0300 Subject: [PATCH] New Chapter: Project organization --- content/books/things-i-learnt/_index.md | 2 + .../one-change-commit/index.md | 2 +- .../project-organization/index.md | 84 +++++++++++++++++++ .../books/things-i-learnt/throw-away/index.md | 2 +- 4 files changed, 88 insertions(+), 2 deletions(-) create mode 100644 content/books/things-i-learnt/project-organization/index.md diff --git a/content/books/things-i-learnt/_index.md b/content/books/things-i-learnt/_index.md index 33d9a5c..3c908d0 100644 --- a/content/books/things-i-learnt/_index.md +++ b/content/books/things-i-learnt/_index.md @@ -33,6 +33,8 @@ template = "section-contentless.html" * Source Control * [Always Use A Version Control System](always-vcs) * [One Commit Per Change](one-change-commit) + * Project Organization + * [Organize Your Code by Data/Type, Not Functionality](project-organization) * Writing code * [Be Ready To Throw Your Code Away](throw-away) * [Future Thinking Is Future Trashing](future-trashing) diff --git a/content/books/things-i-learnt/one-change-commit/index.md b/content/books/things-i-learnt/one-change-commit/index.md index 77da0ba..9dc5129 100644 --- a/content/books/things-i-learnt/one-change-commit/index.md +++ b/content/books/things-i-learnt/one-change-commit/index.md @@ -36,4 +36,4 @@ the changes in the file before committing. [^1]: Ok, it _may_ have some issues if the field can't be null, but you get what I meant, right? -{{ chapters(prev_chapter_link="/books/things-i-learnt/always-vcs", prev_chapter_title="Always Use A Version Control System", 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/always-vcs", prev_chapter_title="Always Use A Version Control System", next_chapter_link="/books/things-i-learnt/project-organization", next_chapter_title="Organize Your Code by Data/Type, Not Functionality") }} diff --git a/content/books/things-i-learnt/project-organization/index.md b/content/books/things-i-learnt/project-organization/index.md new file mode 100644 index 0000000..f86599b --- /dev/null +++ b/content/books/things-i-learnt/project-organization/index.md @@ -0,0 +1,84 @@ ++++ +title = "Things I Learnt The Hard Way - Organize Your Code by Data/Type, Not Functionality" +date = 2019-07-15 + +[taxonomies] +tags = ["en-au", "books", "things i learnt", "project", "project organization"] ++++ + +A lot of projects assume that you'll put things with the same functionality in +the same place, no matter what data they deal with. This makes things harder +to break apart later. + + + +Most projects keep organized by the functionality each component do. For +example, all the models are in the same place, all the functions that convert +one model into an internal structure/DTO are kept together, and so on. +Something like this: + +``` +. ++-- IncomingModels +| +-- DataTypeInterface +| +-- DataType1 +| +-- DataType2 +| +-- DataType3 ++-- Filters +| +-- FilterInterface +| +-- FilterValidDataType2 ++-- Processors +| +-- ProcessorInterface +| +-- ConvertDataType1ToDto1 +| +-- ConvertDataType2ToDto2 ++-- OutgoingModels + +-- DtoInterface + +-- Dto1 + +-- Dto2 +``` + +This is fine and works. But when you organize by data, it'll make a lot easier +to split your project in smaller projects -- 'cause, at some point, you may +want to do almost the same thing as you're doing right now, but with small +differences. + +``` +. ++-- Base +| +-- IncomingModels +| | +-- DataTypeInterface +| +-- Filters +| | +-- FilterInterface +| +-- Processors +| | +-- ProcessorInterface +| +-- OutgoingModels +| +-- DtoInterface ++-- Data1 +| +-- IncomingModels +| | +-- DataType1 +| +-- Processors +| | +-- ConvertDataType1ToDto1 +| +-- OutgoingModels +| +-- Dto1 +... +``` + +Now you can make a module that deals _only_ with Data1, another that works +only with Data2 and so on. And then you can break them into isolated modules. + +And then when you have another project that also have Data1 but also deals +with Data3, you can reuse most of the stuff in the Data1 module. + +And I do understand that this creates an explosion of directories/packages, +which may seem a bit unnecessary. + +Believe me, I also thought the idea of keeping things by functionality made +more sense. But in one project, I got a requirement to do almost the same +thing as I was doing before, but with a small change, which would require one +less step/transformation (in our example, you can think as the new requirement +as doing exactly what the Data1, Data2 and Data3 did, with their +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 +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") }} diff --git a/content/books/things-i-learnt/throw-away/index.md b/content/books/things-i-learnt/throw-away/index.md index 2abe9b4..f051141 100644 --- a/content/books/things-i-learnt/throw-away/index.md +++ b/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 tests](/books/things-i-learnt/integration-tests). -{{ chapters(prev_chapter_link="/books/things-i-learnt/always-vcs", prev_chapter_title="Always Use A Version Control System", next_chapter_link="/books/things-i-learnt/one-change-commit", next_chapter_title="One Commit Per Change") }} +{{ 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") }}