This is something that we discovered during the initial versions. We had placed some URL's into the documentation which pointed to some external resources. Then an year later, we got a defect logged into the system, a defect logged by a customer. This was a low level defect, about some URL in a Help Page that was not working, giving a 404 error. However, when the defect got to review, it was the tip of the iceberg, We realized that this had the potential for huge problems further ahead and we needed to change how we do things. Till now, we used to put URL's inside the software and documentation and so far had not seen any problem. However, in this case, the URL was pointing to the page of an external component help file and the external organization had changed the mapping on their site and hence the exiting URL would not work.
Now, this was a minor issue, but it was a pointer to something that was far more serious. There could be numerous reasons why a hard-coded URL might not work:
- Like in the above example, there could be linkages to external sites that are not in control
- Even internal sites could be a problem. We once had a change in the way that the Help file system was working because of a change in the software that they were using (the old software was out of date, and the new one promised a lot of advantages, so there was no option).
- Sometimes there is a change in the Help, and rather than spend a lot of effort to redo the various pages, it makes sense to update the link to point to new pages (which would take far less time).
There can be other advantages once you start thinking about, primarily the increased flexibility you get. So what is the solution ? The solution is to implement a policy of using URL redirects everywhere. What are URL redirects ? These are redirects that instead point to the end URL, but you can change the final destination anytime you want (the redirect is on an internal server and can be modified anytime).
The one thing you need to do is to ensure that you map every redirect URL, where it is used and the final destination on a file along with the date, some comments about what it is for, and who had asked for the redirect. This needs to be saved along with the other components of the code on a source safe kind system, and ensure that any changes to these redirects need to be done through the process of a defect mapping so that the entire information about why the change needed to be made can be mapped.
This policy adds a layer of extra effort, but anytime you need to make a change to the URL and you find that you are not able to make one because it has been hard-coded inside released software, you will realize the advantage of such a policy.
Now, this was a minor issue, but it was a pointer to something that was far more serious. There could be numerous reasons why a hard-coded URL might not work:
- Like in the above example, there could be linkages to external sites that are not in control
- Even internal sites could be a problem. We once had a change in the way that the Help file system was working because of a change in the software that they were using (the old software was out of date, and the new one promised a lot of advantages, so there was no option).
- Sometimes there is a change in the Help, and rather than spend a lot of effort to redo the various pages, it makes sense to update the link to point to new pages (which would take far less time).
There can be other advantages once you start thinking about, primarily the increased flexibility you get. So what is the solution ? The solution is to implement a policy of using URL redirects everywhere. What are URL redirects ? These are redirects that instead point to the end URL, but you can change the final destination anytime you want (the redirect is on an internal server and can be modified anytime).
The one thing you need to do is to ensure that you map every redirect URL, where it is used and the final destination on a file along with the date, some comments about what it is for, and who had asked for the redirect. This needs to be saved along with the other components of the code on a source safe kind system, and ensure that any changes to these redirects need to be done through the process of a defect mapping so that the entire information about why the change needed to be made can be mapped.
This policy adds a layer of extra effort, but anytime you need to make a change to the URL and you find that you are not able to make one because it has been hard-coded inside released software, you will realize the advantage of such a policy.
No comments:
Post a Comment