As a crew of passionate developers, we’re always excited to highlight companies that seek to make coding more beautiful and simple. Today, we’re excited to share an interview with Jaime Jorge from Codacy where we discuss how they make it easier to do code reviews by automating the process. Codacy helps developers to enforce a coding standard, save time in code reviews and ship higher code quality.
-
Q: Tell us a little bit about the origins of Codacy- how did the idea for the company come together? What challenges or market gaps were you trying to solve for developers?
A: Codacy started because my co-founder, Joao Caxaria, and I have a deep love of programming efficiency and tools. But we found that a big part of development - more than 20% - is spent on reviewing code.
Joao, who previously worked for several big banks, attested for how inefficient code reviews were. The time spent blocking others and not shipping code would cause many projects to fall behind schedule. Furthermore, talking to hundreds of developers kept confirming that they spend too much time reviewing code style, best practices and common errors.
So, we decided to start tackling this problem with static code analysis that could be applied to any commit or pull request and would make it easier for people to save considerable time on their code reviews and code quality analysis.
Q: We hear you are big Scala fans at Codacy, recently sponsoring Scala Days in San Francisco! What drew your team to the language? What Scala feature are you most excited for?
A: We truly love Scala. Scala has been one of the pillars of Codacy from the start. Joao, who has an Enterprise Java background, has loved the language from the beginning and we’ve since taught Scala to new people joining in the company. Scala has also helped us with hiring; typically, if someone is interested in working with Scala, they will probably be a good fit for us as a company.
Initially, we wanted to have the expression power of dynamic languages without losing static type safety.
We placed our bets on Scala and, judging from adoption rates, we believe this was a good decision.
We are especially excited about the great work from the Scala team on Abide, Scala-Meta from Eugene Burmako and his team, and about the TASTY spec announced by Martin Odersky. It has many things we’ve been looking for to support customers interested in deeper code analysis.
Q: Codacy is built using Scala, Play Framework and Akka- how did you decide to use those technologies for your application architecture?
A: When defining Codacy’s architecture, we knew that the system we would have to build to analyze millions of lines of code per hour and would have to treat scalability, distribution and concurrency as first class citizens.
We were already sold on Scala, since as I mentioned, we’ve been fans of the language for a long time. The process of choosing Play and Akka was simple: both are built for massive operations and have the backing of a strong growing company such as Typesafe.
We treat every single operation as an immutable task for an actor. From parsing code, to dealing with code repositories, to applying code patterns to ASTs: everything is a task for us that we distribute to pools of actors. Akka excels at this job.
Now, we’re in a position where our current infrastructure demands further decomposition into services and that we break a monolith. Because we’ve modeled our system already in components, this has been easy from the architecture standpoint.
Q. What is the most surprising use of Codacy that you didn’t expect from the beginning? Any customers or users that have blown your socks off?
A: We designed Codacy around what we wanted to have for ourselves but also around what people have been asking us for a long time: save me time off code reviews. But this doesn’t mean developers only use Codacy for that purpose.
I would say one of the most surprising use cases of Codacy is helping on-board software engineers into a company.
We found that companies growing their engineering teams wanted a way to avoid spending the senior engineer’s time teaching (and enforcing) best practices, code style and common errors to new team members. The huge hiring spree currently occurring in the market only increases the time required to get new developers up to full speed inside a company while not spending too much of management’s time.
These companies started using Codacy to on-board their most recent Scala developers, who are very often new to the language, using our code analysis documentation to help each developer learn on his own. This documentation is served on each issue and explains: “Why is this an issue.” We also link to outside community websites, like Stackoverflow and blog posts when further information is needed.
So, we designed our goals system to suit a variety of needs. Our goals system is not only a way for teams to decompose their technical debt into bite sized chunks and assign team members, but is also a way for a developer to ease into a code base and learn by correcting the low hanging fruit.
Q: Back in January, Codacy launched Code coverage- can you speak more to the value of having that feature integrated into your product?
A: Developers are always looking for ways to centralize their tools and have everything play nicely together.
When reviewing code, you want to know: How is this influencing code quality? Is it respecting our code style? Does it follow community standards? How is this influencing our code coverage?
We’re very reactive regarding feature requests, so we ended up implementing code coverage into our product. This has been a critical feature for many companies and Open Source projects using us today.
There are also other very important questions such as: Is this duplicate code? How many times has this code fragment changed?
So, we launched code coverage, but also code duplication, churn and code complexity for Scala. We believe all of these indicators are part of the code quality overview that every team should track because they give a good snapshot of the code quality that is shipped.
Q: Can you give us a sneak peak into any other upcoming features in your 2015 roadmap?
A: We are very excited to integrate the great tool that the Scala team created: Abide. Abide is a next generation linting tool, and Codacy will centralize the results and show only the most relevant information after each commit or Pull Request.
We are also currently developing new code patterns that will target specific security concerns in Scala.
Furthermore, we are finally launching one of the most asked for feature: Team Kpis. This will allow developers to track their performance and compare each other to the team, hopefully creating some a healthy competition to increase the quality of the code shipped.
Lastly, we’re very excited to allow our users to easily create their own static analysis rules- coming soon!
--
Thanks Jamie! Check out Codacy for your next code review.
