Over a million developers have joined DZone.
{{announcement.body}}
{{announcement.title}}

Code Archaeology

DZone's Guide to

Code Archaeology

· DevOps Zone
Free Resource

Download “The DevOps Journey - From Waterfall to Continuous Delivery” to learn learn about the importance of integrating automated testing into the DevOps workflow, brought to you in partnership with Sauce Labs.

I love sitting down to review a new codebase. Depending on the age of the codebase, it can be a little like archaeology. There are often distinct sections that have not been touched in many, many years. Sometimes you can almost see rings around the codebase similar to the rings on a tree. One section might be written in one framework, but another section is implemented in a different, newer framework. The following describes how I spend the first hour with some new code.
Archaeologist
First Impressions
The very first thing I typically notice is the style of the syntax. Does the code use the correct industry standard for the given language? Or is this C# project written in the Java style (or vice-versa)? If I see non-standard syntax, I tend to assume that the code was written by novices*. First impressions come quick and are hard to change.

A lot of projects have a “utilities” package or namespace. These packages contain tweaks and helper functions to aid with the rough edges of the language. Prior to Java 8, how many java projects have special classes to handle date/time manipulations? These packages provide some insight on the level of knowledge the original developers had of the language. It is often enjoyable to see how others have solved similar problems. Sometimes they solve it in a similar way I have seen. However, often times it is solved in a completely different manner. Seeing those differences helps me grow and evolve.

Digging Deeper
After getting the initial peek, I look at the dependencies. What external frameworks are being utilized? This gives me a some landmarks to visit. I research any dependency that I do not immediately recognize to determine the approximate age and level of support.

Audibles
A common sore spot in application development is accessing databases. In my experience, database access has been the largest performance bottleneck in most applications. In addition, incorrect handling of connections can cause memory leaks and bring an application down. I look to ensure proper connection handling as well as review the usage of ORM or other database mapping frameworks.

If the application is a web application, I will look at the general configuration. Whether that is the web.xml in Java or the global.asax in dotNET. I am looking for the general entry point for most requests. I follow up with reviewing how the chosen web framework has been implemented. Are the defacto standards followed?

Conclusion
I tend to learn something new regardless of the age of the software, the original developer’s experience, or the chosen language. Often I will see a language feature that I never knew existed or a method on a class that I have never seen. I enjoy reading code almost as much as I enjoy writing it.

* The original developers may have only been novices in the chosen language. They could very well have had many years of software development.

The original article can be found http://www.greenmoonsoftware.com/2014/04/code-archaeology/ 

Discover how to optimize your DevOps workflows with our cloud-based automated testing infrastructure, brought to you in partnership with Sauce Labs

Topics:

Opinions expressed by DZone contributors are their own.

The best of DZone straight to your inbox.

SEE AN EXAMPLE
Please provide a valid email address.

Thanks for subscribing!

Awesome! Check your inbox to verify your email so you can start receiving the latest in tech news and resources.
Subscribe

{{ parent.title || parent.header.title}}

{{ parent.tldr }}

{{ parent.urlSource.name }}