In software engineering, "refactoring" source code means improving it without changing its overall results, and is sometimes informally referred to as "cleaning it up". Refactoring neither fixes bugs nor adds new functionality, though it might precede either activity. Rather it improves the understandability of the code and changes its internal structure and design, and removes dead code, to make it easier to comprehend, more maintainable and amenable to change. Refactoring is usually motivated by the difficulty of adding new functionality to a program or fixing a bug in it.
When we looked at abstraction of a process or machine over the semester, I understood that if a machine takes X and produces Y, it should not matter how the machine produces Y... what is important is that the machine produces Y (hence the term blackboxing).However, when we look at code refactoring, there is a strong desire against blackboxing in the previous sense, as HOW the machine takes in X and produces Y IS important. I see this process of cutting out dead code and keeping the code that makes the machine work as a process of Terranova's immanent control (122); i.e., the programmer generated a new code that was innovative but also destructive, and refactoring is the process of keeping only the innovate code. Thus, we can look at refactoring as a possible post-processing of the fluid space that produces turbulent phenomenon (108).
In this sense, I am not sure how refactoring relates to production. It seems to solidify the machine in its routines (anti-production), but oddly, it might also free up the machine to allow it to produce something outside of its original self once the refactoring is complete (production). While I do not have a complete grasp of D+G's use of production vs. anti-production, I think their text would be helpful in seeing if refactoring is a process of bureaucratizing code or opening it up to new forms of productionafter we look at refactoring through Terranova's eyes.
No comments:
Post a Comment