For the past two months I have reviewed an old Exchange Script, one that took an assessment of Exchange information, and did a major rework. My purpose was two fold. One, the script did stumble in some environments depending on permissions and depending on where it was run from. Two, I had a personal goal to make this script more user friendly, organized and possibly one that could be run by a client with guidance. Now, why would you re-visit a script? Depending on the purpose and scope of the script, there are many reasons to do so:
* Learned new coding methods – as your coding experience grows, you will find new and better ways to write PowerShell coded. These new tricks and coding methods can be put in place. Maybe you were able to calculate how long code sections would take run and found a faster method. Maybe you learned how to write error controls and/or handling into scripts. These new techniques could allow for a more efficient or less error prone script, possibly translating into a better experience.
* Cleanup – If you write like I do, your first iteration is a version that accomplishes a task. It will not be pretty, there will not be any comments or I may even have sloppy variables. Then the script is used for a while and features are added, some additional code is added and not as well organized. What becomes apparent is that after constant use, cleanup is needed. So at that point commenting is added, standardized variables are put in place, reporting is created and maybe even proper documentation is created in the form of a script header).
* Adding Functions – when writing a script, sometimes in the first iteration you may not notice that a repeatable process is being used or a process that could be converted into a repeatable process. In this case, a function could be written to handle this and to allow for multiple sections of the script to call on it and indeed this will also shorten your script and make it more flexible at the same time.
* Better Commenting – This is for sure one of the biggest changes for my scripts as I can provide summaries on each code section as well as use the ‘#’ to help divide up the script into sections and also use it for noting important aspects of a script.
* Output File Formatting – I have a script that exports lots of data files. With that, the fill names were all wacky, the location not idea and inside the files the formatting of the data left much to be desired. With a bit of re-work, the files content flows nicely, the files names are more standardized and I even created a manifest file for this script. The manifest listed all files and their purpose.
Final Thoughts
As with any scripting project, it turns into a process. The best option is when you get to a point that you like a script in the way it handles, use that as a core for future scripts. Have a preset way for output, general script look, etc. can greatly reduce your product / script developing time. So if you write lots of scripts, it will be worth the time to develop these things and incorporate them into all of your scripts. So take the time, invest in a procedure and after some time, revisit your older scripts and give them a refresher from what you have learned.
Revisiting Old Scripts
Categories:
