When you work a lot with something you develop opinions about how things should be done. Here is my list, after two years as an independent contractor, mainly with Qlik Sense extensions and mashup, and of course based on my experience from Qlik.
1. Use version handling
There is no reason not to use version handling of your code. I use Git for everything, but if you are still using something else, that might be OK too. You probably should consider switching to Git, but as a developer that might be a decision taken over your head.
The benefits of using version control are enourmous. You can easily go back and find the reason behind a bug or the implementation behind that feature the customer now wants in another extension too. Invaluable!
You also should keep a version number in your qext file, and change it every time you deploy a new version. The main benefit of this is that you can see what version of your extension is in use in a Qlik Sense installation. I have described how to do this in a previous post.
2. Always test your extension in a browser
The developer console is an excellent tool for extension development. You use it to debug your javascript code, to inspect the HTML and CSS and to analyze the network traffic, including the web socket traffic. It can also be used to turn caching off, so you know that you are running the latest version. The browser included with Qlik Sense Desktop is not of much use for extension development. Even if you can open the console, it’s an environment your users do not use.
3. Stay in your sandbox
The extension framework gives you a HTML element for your extension. Stay inside it, unless you have very good reasons 
not to do so. That goes both for your javascript and CSS.
- do not inject HTML elements outside of your own element
- prefix your CSS rules so that it affects only the extension
- scan only your element, use $element.find() rather than $(), or element.querySelectorAll rather than document.querySelectorAll
- avoid html id’s, since they must be unique within the page. If you must use one (really only when you use a library that needs an id) make sure they are unique for each extension instance (test with multiple instances of the same extension)
There are occasions when you need to break theses rules, but only do it when it’s need for your extension functions.
4. Use modern development tools
Pretty soon after you have started with extension development you will grow out of the Qlik Sense dev-hub extension editor. A modern, nodejs-based environment, with a good text editor gives you a lot of benefits, and works well with version handling software. I would recommend the following:
- a good editor. I mostly use Visual Studio Code, but there are others that probably are just as good.
- a CSS preprocessor like less helps you with prefixing css, add vendor prefixes etc
- a lint tool, to find common errors an enforce good programming practices
- possibly a preprocessor, to allow you to use modern javascript features and still work on older browsers
5. Always keep your extension backwards compatible
After a while your users will most likely want more functionality in your extension. They might want more interactivity, more rendering options, perhaps support for more dimensions and measures. You will probably add new settings giving your extension more flexibility. You might also find that some of the stuff you originalyy programmed was not perfect (that happens to all of us..). But if you have deployed your extension to production, make sure that all your changes are backward compatible. If you don’t you will have huge problems when you deploy the new version, with breaking apps.
If you find it impossible to make your new extension backwards compatible you probably should not be making a new version, but a new extension, with a different name.
6. Base your rendering on only the layout
The model behind Qlik Sense extensions (and the built-in charts too, actually) is that the extension is based on a Generic Object, where you configure the Generic Object in the property panel and use the layout for rendering. Stick to that model, do not break it. If you need more data for your rendering, add it to the properties structure. Avoid:
- creating HyperCubes and ListBox objects programatically, add them to initialProperties and the property panel instead
- fetching variable values programatically, add expressions to the property structure instead (that also gives the app developers more options, like hard-coding values, or making them change automatically as selection state (or data) changes
It is however OK, even recommended, to call API methods for:
- showing lists of available values in the property panel
- making selections etc when the users clicks on buttons, menues or other parts of your UI