Any kind of hardcoded path is, in general, opposite from best practice so opening a SPWeb or SPList object directly from its full server URL is a no-no.
To get the SPWeb object, if you are sure your code will always run in your desired web it is perfectly okay to use SPContext.Current.Web. In all other cases, you might want to look at something like the Service Locator pattern, or some other way of finding your way (property bag, list item in a central config list, etc.). Storing web URLs in the web.config is IMHO not best practice.
You should always avoid using SPWeb.Lists[string listName], as it enumerates all lists (which is slow, and will throw AccessDenied if the user does not have proper privileges for that). Use SPWeb.Lists[Guid uniqueId] instead, or SPWeb.GetList().
For SPList objects from a definition that you control (such as a pre-defined list in an applicative site), the site-relative URL of the list is known and fixed so it's okay to open it with GetList(SPWeb.ServerRelativeUrl + "/lists/myListUrl").
One important caveat, SPWeb.ServerRelativeUrl is not always terminated by a slash. If you are at the root, it will be "/", and in all other cases it will be "someUrl/subsite" without an ending slash. So to properly concatenate with the list's Web-relative Url you need to handle that case for example by using SPUtility.ConcatUrls.
If your product exposes webparts or application pages (in _layouts), they are potentially accessible from other site collections (where they would not make much sense) and you should protect against that, for example by setting a SPWeb property bag entry upon provisioning the site and verifying against that in the applicative pages.
Now, all that being said, for real best-practice advanced kung fu (but unfortunately rarely seen), you should encapsulate all your SP* accesses in repository patterns. Instead of sprinkling SPWeb.GetList() everywhere in your code, use e.g. ImageRepository.Current() which will return your product's image store. That repository should return custom (POCO) 'Image' objects tailored to your needs, abstracted away from SPListItem objects.
Be aware that handling SPList or SPListItem objects outside of the scope of their SPWeb or SPSite is a sure way of running into SPDispose leaks and performance hits, as a number of methods in those objects re-open their parent web without disposing it (but internal caching mitigates that a bit).
Sorry for all these odd bits thrown together. I'll gladly elaborate on any of those points.