View source for BOSS/Design

We don’t want to specify any harsh requirements that would prevent students creating a variety of projects.

However, we do need to give some recommendations for designing projects, so that future students can still understand and maintain the projects.

It is also worth noting that due to the requirement of hosting things for free, you will want to read the [[BOSS/Hosting|hosting page]] as this limits what you can do signficantly.

Please make sure to follow the [[BOSS/Languages|coding guidelines]] as well for any programming.

== KISS ==

Keep it simple stupid!

If it doesn’t require a feature, don’t add it.

If it doesn’t require being written in a fancy programming language, don’t use that.

If it doesn’t require data collection, don’t collect people’s data!

== Existing Systems ==

If a system exists, please try to use it unless its completely impractical.

This is because students don’t have much time and don’t want to be managing a completely new system. However please use open source projects (closed source nearly always comes with a cost, either data collection or money both of which we cannot afford)

Note: I’m mostly referring to libraries. I think its quite fun to write simple projects like a link shortener for yourself.

=== Licensing ===

Please see [https://boss.bathcs.com/policies/licenses/|our license policy] for information on how our projects are licensed.

In general, new projects should be licensed under [https://spdx.org/licenses/LLVM-exception.html <code>Apache-2.0 WITH LLVM-Exception</code>], contributors must agree to the [https://developercertificate.org/ Developers Certificate of Origin (DCO)], and any contributions must not violate the [https://www.bath.ac.uk/publications/university-of-bath-ip-policy/ University of Bath’s Intellectual Property policy].

== Keep it general ==

Always try to keep the structure of the project general, so that it can be repurposed easily. Don’t take it too far though—there’s a balance.

Generalisation normally leads to cleaner code and better maintainability.

== Modules ==

Modules are your friend, different languages implement them differently and have different ideas about how they should be organised (e.g. Go vs Rust).

We don’t really have opinions, as you should use the style which fits the programming language you are using. If you don’t like that style, don’t write a project in that language (for maintainers, I’m sorry but deal with it).

If you try to go against the style of the programming language, you will find more barriers and have to implement hacky workarounds which will lead to unreadable, confusing and buggy code.

== Data storage ==

Due to limitations with the fact we will never get any funding, we must create projects which only relies on database storage (which we can host for free, see the [[BOSS/Projects/Database|database page]]).

== Docker ==

For easy hosting for free, we require projects which need hosting to be dockerised (meaning they have a <code>Dockerfile</code>).

These Docker containers cannot interact with the host system at all.

== Websites ==

If all pages can be written in markdown, then use a static site generator.

If a website is dynamic it should always be designed with a backend and frontend to help with code security, which also helps with a website feeling “modern”.

Any data input should be validated on the backend.