Code SmellsPrasad Narasimhan – Technical Architect

System starts

All the business & technical stakeholders brainstorm a lot.

They want to start somewhere rather than getting into more of design paralysis.

Core level classes gets created, Utility classes, Exception classes…

System grows

System grows based on the usage , features gets added either by extending or changing current code.

Structure is maintained, silos and monolithic code gets created.

With minimal documentation and fear of touching core & utility its duplicated.

System expands

Now more features are needed in short time.

No time to take stock of what is already available how the design could be extended.

If it works don’t touch it syndrome.Some piece of code which lies dead , Silos in

method and class level.Duplicates at class level and variables level

System explodes

Now the business wants maximum use of system , invites users through campaigns and various launch pads.

Application is perfectly scalable to optimum level no issues. The Variables – scope, life time.

Collection handling – creation of collection based on items, customer details which was small now its rapidly increasing.

Loop which process the collection becomes bottleneck.

Explosion handled

Giga bytes of processor, clustered system.Failover mechanism, Caching large

amount of data with latest caching mechanism.

Persist the data when failure happens.Predictive recovery approach.

Code Smells patterns

Particular main functionality gets enhanced without proper refactoring of the base classes and dependent classes

Class & methods violating SRP – Single Responsibility principle.

Open & Closed principle – Base class should be open for extension and closed for changes.

Some thoughts

Refactoring when needed.Test Driven development.Inline Documentation for proper piece.SQALE based cost remediation and code

correction at periodic intervals.Code and design audit at periodic

intervals

Thanks