3

I am working on a Qt application which has different features bluetooth stack, storage (data model), views, controllers, .. The project architecture is based on an MVC pattern. Nothing fancy or complicated.

The current project has a lot of libraries "subdivision". For instance, there is a library called views which contains QML files. In terms of dependency, there is no reason to have those files in a separate library. We could have them inside the application (.exe) project.

Same for the bluetooth stack, there are different libraries for protocol, stack, commands, clientsprotocol and clientscommands. The 3 first libraries have been used for other projects and almost never change (but they are copy/pasted in each project, there is no common shared library with versionning and so on). Wouldn't it be better to have a single library with subfolders?

EDITED QUESTION: What are the good practices, rules of thumbs or strategies when it comes to splitting a project into libraries?

(Before change: What would you say is a good practice when it comes to split the code into libraries? Should we avoid "splitting" if not necessary ? Or should we divide the project with a "maximum" of libraries?)

Eric Brinette
  • 31
  • 3
  • 3
    No need to split unnecessarily. You'd separate your code if you need to reuse it from multiple places. For instance, you might separate your business logic into a library, and link to it from a GUI application and a command-line interface. People also split because of conway's law - team X wants their own project, etc. But it sounds like you're managing a small project so that doesn't matter. You might split if your project is so big you want to manage binary size, e.g. ICU or QT. But that's probably smell the project is too big. – parktomatomi Nov 18 '19 at 16:27
  • Thank you for your input. You guessed right, the projects are quite small (mobile apps mostly - using Qt). I had never heard of conway's law term. But the three reasons you provided make sense. If you find articles I should read on the subject I will gladly read them. – Eric Brinette Nov 20 '19 at 08:40
  • Here they are... . – Trantor Nov 20 '19 at 11:32

1 Answers1

2

Some references for KISS, Occams Razor and Yagni as software design principles can be found here: https://effectivesoftwaredesign.com/2013/08/05/simplicity-in-software-design-kiss-yagni-and-occams-razor/

Keep simple things simple, put all functionality to one lib, if these multiple libs depend on each other... . Reduce complexity and make your life easier!

(I fully support and understand your intents, but I fear we are going to get a lot downvotes from all these software 'architects' around here who make their whole living around producing masses of libs, interfaces, components and 'pimpling' with minimal functionality depending on each other and making other people's life hell on earth :-) )

Trantor
  • 768
  • 1
  • 8
  • 27
  • Thank you for your input. I am wondering if there is a good practice I should follow. If I preach to my colleagues to "reduce complexity" I want to make sure this is the right call. If you find articles on the subject I will gladly read them. – Eric Brinette Nov 20 '19 at 08:34
  • If your question is answered, please set the hook. – Trantor Nov 20 '19 at 11:31
  • Well I would but I can't anymore because the question is considered to have an answer entirely opinion-based rather than fact. I edited the question maybe it will be "unlocked" again after review. Anyway, thank you for the reference, while I applied most of those rules, I like to put a name on it. Very instructive link! – Eric Brinette Nov 21 '19 at 09:14