Is Design Dead?
For this article there is several topics that appeared very interesting to me. For the initial themes treated, one was the difference between the traditional structured design, and the evolutionary design, and it's a matter that I've even seen as a difficult topic because of the different perspectives presented even by my own teachers, some of them teaching me that the planned design is extremely important and even forcing this practices into our projects, but in the other perspective, some professors taught me to be evolutionary, and to make incremental design based on prototypes making really confusing the decision for the design every project I've made.
Also, one of the things that I've found curious into the article is the association that the author makes between the refactoring and the YAGNI's simplicity to the evolutionary design. It's not that usual to understand the "best practices" of programming as supporting any bigger concept than the code itself, but looking at the correlation the it's shown to us by Martin Fowler between the necessity of making the code simpler and more explicit about the things we're coding, with the idea of getting an incremental design for any software project of product, at least made me to question myself about other practices that I took for myself and might be supporting some behavior in my point of view for my own programming habits.
At last, I can notice that the other topics that the article covers, are more related to the last articles we've read, but the perspective changes, considering them as a perspective changers, for example, we have the irreversibility previously stated as a factor of risk, and a main problem for the patterns to be applied at100%, but now I see that also this concept make the necessity for at least some planning behind the evolutionary design. Even when the author is in the side of this kind of design, I can see how it's necessary to understand, or at least to know, every tool that is given to us (as a software professional) and to consider it as a possibility for every work I'm going to perform, just in order to have a wider viewpoint and make the best I can.
Also, one of the things that I've found curious into the article is the association that the author makes between the refactoring and the YAGNI's simplicity to the evolutionary design. It's not that usual to understand the "best practices" of programming as supporting any bigger concept than the code itself, but looking at the correlation the it's shown to us by Martin Fowler between the necessity of making the code simpler and more explicit about the things we're coding, with the idea of getting an incremental design for any software project of product, at least made me to question myself about other practices that I took for myself and might be supporting some behavior in my point of view for my own programming habits.
At last, I can notice that the other topics that the article covers, are more related to the last articles we've read, but the perspective changes, considering them as a perspective changers, for example, we have the irreversibility previously stated as a factor of risk, and a main problem for the patterns to be applied at100%, but now I see that also this concept make the necessity for at least some planning behind the evolutionary design. Even when the author is in the side of this kind of design, I can see how it's necessary to understand, or at least to know, every tool that is given to us (as a software professional) and to consider it as a possibility for every work I'm going to perform, just in order to have a wider viewpoint and make the best I can.
Comentarios
Publicar un comentario