At the base of Odoo's CMS lies an XML templating engine called QWeb, which is discussed in detail in the following recipe. For now, it's enough to know that we can use it to inject nodes into existing documents. In the example, we change the website.assets_frontend view to link to our CSS and JavaScript files. This view will be pulled to construct all the HTML for the website, so you can be sure that your code is available on all pages.
As we can be sure that the website.assets_frontend view is pulled within a HTML head node, we can simply add the files we need and possibly adjust or add other nodes in the head element, too.
For CSS files, order matters. So, if you need to override a style defined in another addon, you'll have to take care that your file is loaded after the original file you want to modify. This can be done by either adjusting your view's priority field or directly inheriting from the addon's view that injects the reference to the CSS. For details, refer to the Changing the existing views – View inheritance recipe in Chapter 10, Backend Views.
To avoid ordering issues with JavaScript, Odoo uses a mechanism very similar to RequireJS (http://requirejs.org). In your JavaScript file, you call odoo.define(), which receives the namespace you want to define as the first argument, and a function that contains the actual implementation as the second argument.
The name to be defined should be your addon's name. In case you export a lot of logically different parts of functionality, define them in different functions, with your addon's name prepended and separated by dots to avoid naming conflicts in the future. This is what the web module does, which defines, among others, web.core and web.data. The definition function receives only one parameter, require, which is a function you can use to obtain references to JavaScript namespaces defined in other modules or in the core. Use this for all interactions with Odoo and never rely on the global odoo object.
Your own function can then return an object pointing to the references you want to make available for other addons, or nothing if there are no such references. Be lavish with exporting your own objects; few things are more frustrating than having to jump through hoops in order to use some existing functionality just because its developer didn't bother to export it properly. The object you return here is what other code gets when it calls require('yourmodule').
As per convention, your files should be called as your module with the appropriate extension added and live in static/src/css or static/src/js, respectively. Only if your files become large enough to be a maintenance issue should you split them up into smaller chunks.