Well designed and maintainable code-base helps in reducing the cost of development (including Change Requests and code enhancements).
(A) What makes a code-base well designed and maintained?
Every software application is developed with an intention of solving a problem. The problem is specified by means of requirements (SRS). It is in the interest of all the stakeholders that the requirements are elicited to the maximum extent possible.
As explained above, if a software is developed against a set of requirements (or use cases if UML is used) then it must be possible to test each and every requirement implemented by the software, distinctly. Testability ------ (1)
Since a software implements a pre-defined set of requirements, technically, it is possible to write the entire application in one single file !!! But then is that a good approach? (If I were to develop a library).
Hence, it is always, better to divide the entire application into smaller parts (layers/modules). So Separation of Concerns (layers) is another key---- (2)
Each module in the software should cater only to a specific functionality. Single responsibility Principle--- (3)
All the modules in the software must be loosely coupled and highly cohesive inorder to create a maintainable application. The impact of a change in one module must be minimal on other modules---------- (4)
Often developers are faced with same kind of problems and scenarios across a multitude of applications. In such scenarios, it is often better to go for tried-and-tested solutions. i.e. Design Patterns -------- (5)
Apart from the above, sufficient documentation by means of code comments and project artefacts, adherence to consistent naming convention, principles of OOP (viz. polymorphism, encapsulation, Inheritance must be used whereever necessary) ---- (6)
But, if somebody is taking a technical interview then simple answers are not understood by the interviewers. So explain them as follows,
A well designed and maintainable software exhibits following principles,
1) Single Responsibility Principle - Every class must serve one responsibility
2) Open/Close Principle - A module must be open for extension but closed for modification
3) Liskov Substitution - instances of derived classes should be able to replace all the base class references without breaking the code
4) Interface Segregation - prefer client specific interfaces over one generic interface.
5) Dependency Inversion - All the modules should be based on abstractions and not concrete classes. Use dependency injection instead of creating instances of temporary 'Helper' classes.
To summarise, a maintainable software must be SOLID in design.
But, if somebody is taking a technical interview then simple answers are not understood by the interviewers. So explain them as follows,
A well designed and maintainable software exhibits following principles,
1) Single Responsibility Principle - Every class must serve one responsibility
2) Open/Close Principle - A module must be open for extension but closed for modification
3) Liskov Substitution - instances of derived classes should be able to replace all the base class references without breaking the code
4) Interface Segregation - prefer client specific interfaces over one generic interface.
5) Dependency Inversion - All the modules should be based on abstractions and not concrete classes. Use dependency injection instead of creating instances of temporary 'Helper' classes.
To summarise, a maintainable software must be SOLID in design.
(B) What underlying principles or qualities do you look for in a system of classes that tells you they are well designed and maintainable?
A software consists of modules/components that act in cohesion to produce the necessary functionality. Now, every module is implemented by means of a set of classes (in OOP languages, structural languages like 'C' do not support 'class').
Classes must be written so that it adheres to the principles of OOP. For instance, having all the data members of the class as 'public' is possible but it is a bad practice and strongly discouraged. Data Hiding -------- (1)
Classes can be inherited from other classes to maximise the code re-use and create a hierachy of similar classes. 'Is-A' relationship, inheritance ------ (2)
If the developer has a reason for not allowing a class to be inherited then he can do so by decorating his class using 'sealed' attribute ( in C#) Usage of appropriate attributes ----(3)
As far as possible, creating 'new' objects of a class within another class must be avoided. Instead inject the dependency by means of constructor/.NET property.------- (4)
No Hardcoding of any sort in the classes ---------------- (5)
Limiting one class to one .cs file is a good practice ------ (6)
Apart from the above, code comments, naming convention and testability (unit testing) of classes still holds true and that cannot be relaxed.
No comments:
Post a Comment