Costumes That Include Crutches

Why Software is degraded?

software problem, which is degraded mainly relates to projects which forgets that we live in a world of changing requirements, and our task is to create software that will be managed to survive these changes.

Yes! Requirements always changing so it should be one of the priorities of the each project. Being aware of this situation, you should always use a certain set of practices that contribute to loosen up the project.

At first let us consider what has to manifest symptoms of the software that actually is doomed to failure:

1. stiffness (rigidity English) - the structure of the project means that the introduction of even the smallest change makes a number of other changes that we forced to implement in modules subsidiaries. What's more, the more we try to make changes, the stiffness of the project grows and the more difficult to estimate the time required even the simplest changes.
2. sensitivity (English Fragility ) - as in the case of stiffness, the problem of small change that this time the cause unexpected faults. Similarly, any attempt to make corrections in such a project makes the situation worse, bringing the project to the inevitable degradation.
3. inflexibility (English immobility ) - a feature of software that due to the functionality of its components could be used in other projects - not because it involves very high risk, such as the lack of independent modules. This constitutes a denial of the concept of software reusability .
4. Failure to reality (English Viscosity) - where there is more than one solution to the problem, right solution, ie, in accordance with the specifications and design are difficult. Easier for us to use other, sometimes the wrong solution, because it was not prepared for the mechanism, providing even a minimal change in functionality. The problem may also affect the environment in which the mismatch between the reality is manifested, for example, a long period of waiting for recompilation difficult cooperation with external software (SVN , bug & issue tracker etc...)
5. Excessive complexity (English needless complexity ) - the problem arises when an apparently legitimate operation, consisting in the anticipation of future functionality, getting unnecessarily complicate the project, as mentioned functionality is never shown, and the introduction of simple changes require modifications to the code, which is not used. The project reaches a significant size unnecessarily and need more time to understand what it actually does.
6. Unnecessary repetition (English needless repetition ) - writing redundant code that pasting, because it has a slightly modified functionality. In such cases, we should always look for another solution (overload methods, application interfaces, classes, etc..) Instead of copying the code that works in a similar or identical way!
7. Opacity (called opacity ) - is writing incomprehensible code. Unreadable code can be caused by too much complexity (combining multiple operators in one statement), the lack of a logical naming convention (Refactoring), ignorance of software architecture ( Domain-Driven Development - DDD , Command and Query Responsibility Segregation - CQRS), etc.. In assessing the clarity of your code, you should ask for such an assessment of another programmer.

To allow work on the project, taking into account the above recommendations were developed by a number of principles, implementation of which greatly facilitates the introduction of any change in the future. Applying these principles, we bring to the situation that instead modify the code, only supplement it with new functionalities.

to these principles include:

1. single responsibility principle (called Single Responsibility Principle - SRP).
   No class can not be modified with more than one reason.
2. Open-Closed Principle (English Open / Closed Principle - OCP).
   software components (classes, modules, functions, etc.) should be open for extension, but closed for modification.
3. Lisková substitution principle (called Lisková Substitution Principle - LSP).
   must be capable of replacing the basic types of subtypes.
4. reversal principle according (English Dependency Inversion Principle- - DIP).
   A. High level modules should not depend on low-level modules. Both groups of modules should depend on abstractions.
   B. Abstractions should not depend on specific solutions. It's the details should depend on abstractions.
5. principle of segregation of interfaces (called Interface Segregation Principle - ISP).
   client should not be forced to, depending on the methods, which are not used.

encourage you to explore these principles and apply them every day in all projects.