I’m trying to land on same hard, quantitative metrics that predict how well built an app is / how maintainable it is. I’ve thought of some, but wanted to hear if anyone else has any other ideas they think could contribute to an app’s quality score?
average elements per view (view being page or reusable element). Lower is better, as it indicates widespread use of reusable elements
average expression length (number of nodes in an expression e.g Current User’s | Role | is | Admin). Lower is better, as it indicates expressions have been reduced to their simplest form
reusable element to page ratio (higher is better). This indicates widespread use of reusable elements. However, is not perfect as SPAs will naturally score higher and apps with loads of small pages may score lower. I am personally of the belief that well built apps almost always have very high reusable - page ratios.
actions per workflow (lower is better). Indicates modularisation and simplicity with each workflow having a single responsibility.
plugin count (lower is better). Whilst all apps need some plugins, extreme counts indicate shortcuts being taken / a lack of desire to build things the right way which results in dependency on third party plugins.
Any ideas/feedback? A single number to classify an app will never be perfect, and I essentially want it to be a number that represents ‘how much would my agency like to work on this app’ based on our own experience.
I also consider this when assessing a client’s project:
Single casing for naming a specfic architectural element (datatype, datatype fields, option sets, option sets’ attributes, custom states…), e.g. all datatype are PascalCase, all datatype fields are snakeCase… I prefer some casings above others for a specific architectural element, but the crucial thing is having only one per each of them.
Also, the existence of a naming convention for naming elements in the elements tree, preferably not renaming default Bubble naming for elements, i.e. keeping Group, RepeatingGroup, Input…
Eh I don’t wanna be overzealous - I think any convention is fine (some better than others) as long as its consistent. It’s consistency that’s important. If they rename everything then, wel, sounds like a waste of time to me, but I can probably work out what your convention is. If you’re inconsistent though, you’re removing my muscle memory and not giving any value in return!
I consider the use of App Texts something to take into account too. Going through every single text in the app as soon as multilanguage is to be applied is a task I prefer not be involved with if possible.
This is hard to quantify, or figure out just looking at a new app, but the amount of glaringly old/unused data types, or what appear to be duplicate types that do the same thing (maybe buildprints can detect what percent of data types or even fields aren’t used?). Sometimes if a client has gone through multiple developers it can be pretty obvious due to naming conventions which were built by one dev or another. I also wince a bit when I see a v large number of advanced filters.
How many data types and complex workflows have notes describing what they do is one too, I try to do this on every new one I create now and it’s great when you get an app that has done this.
More reusables I’m not so sure, I’ve worked on some apps that use a lot of reusables that have been much more of a hack job than others that don’t, but that’s just me. Number of plugins definitely though, especially if there’s multiple plugins that do the same thing.
Hmmmm, I wonder if this might be extremely app dependent. Maybe an ‘acceptable range’ that is very broad would capture most of this and penalise only the ones which obviously have something wrong?
Re: Not only is this a great idea for the reasons you mentioned, but it’s also important if you’re app is is sending data as Things via API. The reason is that the field as seen in the editor is not it’s actual format. If you perform a GET on a Thing with fields, if you use spaces or other non standard characters your field might look one way in the editor but actually be completely different on the code side, leading to confusion and waste of time.
Yeah, I don’t think you can base the maintainability of an app based on the number of reusable elements it uses. I’ve seen people overuse reusable elements to the point that they have a button as a reusable element that is only used in one part of the app.
I also can not stand having to get into an app, find the page through preview to determine where things are, to then go to the page, find the reusable, click into the reusable, see there is another reusable, click into that to see there is another reusable…it is a nightmare having to try and find things when the developer nested reusables together for no logical reason whatsoever.
If considering reusables as a ‘maintainability’ factor, consider whether or not there are reusables that are deeply nested, like more than just one nesting as bad for maintainability and overuse of reusables, so if you see apps that have a reusable that is a button and used in one place.
I’d also say too, that for maintainability, if there are two reusables, one is popup and other is group and they are the same, that is poor maintainability scores right there.
I agree but also there is an idea, that how many expressions are there in regards to things like conditionals. So a dozen short expressions that are each their own conditional would be poor for maintainability, if those expressions could have been combined so as to reduce the number of conditionals necessary. But there are other times, it is just easier (so maybe more maintainable) to just split them out into shorter expressions resulting in larger numbers of conditions on the same element.
Other things to consider would be overuse of backend workflows, so if there are backend workflows getting scheduled from just one location and are not used as a performance improvement (ie: don’t make user wait for completion before continuing) and could otherwise have just been run as an action on page, I’d say that is poor for maintainability as it requires us to jump around from one place to another within the editor unnecessarily.
You’d also want to see how well things are chained…meaning, are there events triggered after processes finish or are there a bunch of workaround and hacks to try and get things to have proper chain reactions.
And most important of all, does the app use Bubbles ‘responsive properties’ which is not about responsive design, but does the app use conditionals to make things visible or are they using workflow actions. For the most part, if workflow actions are used to just hide/show elements that could otherwise use a single conditional to make it visible (and so is not visible on page load by default) it is a sign of a poor build, so not as maintainable.
Additionally, whether or not API calls are doubled up, so one for action and one for data…causes a ton of confusion and is unnecessary. If you ever need both, you just opt for action only and run the action when it is needed.
It means, if the backend workflow is only used from one place in the app AND it is not utilized for allowing processing of data to take place in backend so the user is not waiting for the blue line of death to finish, then it doesn’t need to be a backend workflow.
Basically, the less we need to jump around in the editor the better.
We’re trying to save that app.