#### FIXME
-These environments must model the target systems, and they must be as close as is practical to those target systems. That doesn't mean you need to make exact copies of expensive production environments but you do need to have models of production environments that test enough of the pieces your code will come in contact. Having models that mirror production systems means you'll be less likely to introduce changes that have unintended consequences. You'll give yourself some comfort in knowing that the changes you enact in these models will be the same changes that will appear on the target system.
+These environments must model the target systems, and they must be as close as is practical to those target systems. That doesn't mean you need to make exact copies of expensive production environments but you do need to create models of production environments that test most of the pieces your code will come in contact. Having models that mirror production systems means that when you move your code to production you'll introduce fewer changes with unintended consequences. Your changes will have already existed in a production-like environment. You can take comfort in knowing that the changes you enact in these models will be the same changes that will appear on the target system.
-Ideally you'll need to have an environment like this on a machine that you control. This means that you're not competing with other programmers in your organization that are also being brave with their changes. But you'll also want to ensure that you keep your environment up-to-date with their changes (and any production changes) so you're development model matches what's on the target system and what will be on the target system.
+Ideally you'll need to have an environment like this on a machine that you control. This means that you're not competing with other programmers in your organization who are also being brave with their changes. But you'll also want to ensure that you keep your environment up-to-date with their changes (and any production changes) so your development model matches what's on the target system and what will be on the target system. A good model is one that is kept current with what it is modeling. It's the same as a map of a city: it's best when it matches the area its modeling and is kept current with changes that occur in that city. A good map of the city might tell you about the recent construction happening on your route. A useless map doesn't even show your route because it wasn't built when the map was created. If our model of production is constantly falling behind what's in production we will spend more time rectifying the changes that we're making with the changes between our model and production.
-This also means having an environment that you can quickly rebuild and replicate as needed. Having a model that becomes its own separate reality becomes one more system to maintain. This model should be something that you can destroy and rebuild at will in order to remove any previous experiments. It's best to think of it as an ephemeral copy of your target environment that has limited use and can be tossed when no longer necessary. It should be quick to replicate this environment so there's little friction in creating new environments to play in. That can mean scripting the building process for these environments. How you decide to do this is up to you but keep in mind that you want something that's as simple as you can make it and requires as little thought as you can manage to replicate it.
+This also means having an environment that you can rebuild quickly and replicate as needed. Having a model that becomes its own separate reality becomes one more system to maintain. This model should be something that you can delete and rebuild at will in order to remove any previous experiments. It's best to think of it as an ephemeral copy of your target environment that has limited use and can be tossed when no longer necessary. It should be quick to replicate this environment so there's little friction in creating new environments to play in. That can mean scripting the building process for these environments. How you decide to do this is up to you but keep in mind that you want something that's as simple as you can make it and requires as little thought as you can manage to replicate it.
Again, it doesn't have to be perfect - it's only a model. But it does need to be close enough where your code will behave in a similar fashion between the model and the target environment.
+### FIXME
+
## Time machines
There are plenty of other folks who will tell you the benefits of revision control (and many folks who will show you the exact steps for how to set up revision control). Having a good revision control system will allow you to create areas where you can test code without having to merge these tests into production. Good revision control will allow you to create a space (or "branch" in git parlance) based off of existing code that you can use to experiment and develop on. It also allows you to commit to that space and diverge as much as you need to in order to fully explore the changes you're making. What's most important though is that good revision control will allow you to abandon that space if you need to - you're not forced to commit those changes back to a production machine. This allows you to see if something might work and abandon those changes if they don't pan out. Good revision control affords the programmers the ability to branch off from any point in time and explore what happened in the code base. In a sense they're time machines, allowing you to play "what if?" scenarios with your code. This is vital for your learning because you can feel secure in testing and trying things and have the ability to rewind those changes (or delete them entirely) without affecting the work of others.
projects / themediocreprogrammer.git / commitdiff