I have a question about the best practice in this situation.
At one point, my small application allowed the client to upload a file to a server, and download a file from the server (it would also compress / decompress as well).
This was created in 1 solution which consisted of 4 projects:
- FTP
- CompressDecompress
- UI
- Tests
Now, the spec has changed and there will 2 end users, one who only wants to upload, the other who only wants to download and they should never have access to anything else (ie downloading people cannot upload and vice versa).
So, I have a few choices here. I could either
-
Keep it as 1 solution, and ask users to login, based upon the credentials will display a different UI
-
Alter my UI so it only shows tools to download, create a new solution which consists of just a UI project and reference my .dll accordingly.
-
Delete my UI, create 2 new solutions, each solution being created for either download or upload (and each solution probably only consisting of just 1 project, the UI) and again, referencing the .dll
Does any one have any suggestions? Would any guidelines have allowed me to have not gotten into this situation in the first place (or at least made me more aware of the potential disasters)?
I am mildly surprised by the requirement that the uploading user is only allowed to upload. I can see a use-case for read-only access (download only), but much less for write-only access (upload only), unless that role is to be filled by an automated system.
With that in mind, I would weigh my options as follows
- If both users are expected to be human, extend the UI with login functionality and provide either the upload or download functionality, depending on the user credentials. This keeps the project future-proof for the case that there will be another requirements change to support both up- and download again for one user.
- If one of the users is expected to be a machine, add another project to the solution, providing an API that is tailored for machine-machine communication, parallel to the functionality you currently have in the UI. The unneeded functionality should be stripped from the UI.
Big scope-changes like this can usually not be foreseen during the initial development of a project, so there are no guidelines to prepare your codebase for them.
What you can prepare for are requirements that seem oddly restricting (like the write-only user you have now), and write your code in such a way that the requirement can change without forcing a complete rewrite of a project.
0