One of the many components of which Codacy is comprised started displaying, from time to time, a “Too many open files” exception. This was one of the hardest bug we’ve had to face to date, getting us to the point of pulling out our hair. Today, were sharing how we fixed it so that you can avoid pulling out yours. (more…)
Code reviews are a great tool to achieve higher quality code in a software development project.
Here at Codacy, code reviews are a crucial step of our development process. We’re currently following a software development methodology where each developer’s work is made in a feature branch, and upon feature completion, a pull request is created for that branch.
To be merged, each pull request requires two approves from other members of that team. We’re using this rule since our team had four developers, and it still works great now, with ten developers.
The pull request are the last control point before code joining the master branch, we’re production code lives. As a continuous deployment approach, our methodology assumes that once code is merge into the master branch, it’s ready to be deployed. In our case, after a merge the code is built and deployed to a staging environment. The staging environment is periodically or manually promoted to production at any given moment.
Still, code reviews can be a bottleneck in the feature pipeline and delay their deployment. So here are some best practices that worked for us and can help your team to keep a healthy speed.
Keep a schedule
Creating a schedule to maintain your team organized is a good way of keeping your team engaged. Reviewing code is often regarded as a “boring” activity by some programmers, so make sure you get everyone involved to minimize the load on each individual developer.
Before starting to code a new feature, discuss with your colleagues the major design and algorithm choices. This will help you gain a better understanding of the problem and collectively find better solutions. It also makes that reviewers are already familiar with the decisions you made in the code and have a easier time reviewing it.
I do believe in the “Don’t live with broken windows” motto. When you find a piece of code that you feel isn’t as good as it could be, you should always strive to improve it.
However, don’t do it in the middle of a feature. It’ll pollute your branch with unrelated changes, that the reviewer will have an hard time understand how they relate to the original intent of the pull request.
Instead, you can keep your personal list of things to improve when you’re in between features.
Think like a reviewer
Always be your own reviewer! I can’t stress this post enough. Always review your code before hand it over to the reviewers. It’ll help you get a perspective on the changes you made. Use this opportunity to analysis your code with a critical eye and strive for improvements. Think of what a reviewer would ask and clarify the code and/or add comments to explain your intent. This will also help you make sure that your code is definitely ready for review and prevent you from wasting the reviewers time.
As a team you should automated the review process as much as you can. Automate builds, tests and static analysis (using Codacy of course ). These help to speed reviews immensely. A human reviewer shouldn’t start reviewing if any of those steps fail. (Also, making sure a pull request includes test to feature developed is a critical point.)
I hope you and your team find these rules of thumb useful. If you have more tips on how to improve the productivity of code reviews and the happiness of your team, please share them in the comments below.
Last week we attended the Tricity Scala Users Group scala meetup where I did a short presentation about Codacy’s project structure and architecture. This blog post is a quick summary of the presentation I made. The slides are available here, or you can download them directly as a pdf here if you prefer.
I would like to thank Scalac and Sandra, our Developer Advocate, for the organization of the event. Patryk Jażdżewski also made a presentation about how to use Scala on Android with Scaloid. You can check his slides here.
At Codacy we chose Scala to build our infrastructure. But not all the engineers that we hire are Scala experts. Scala isn’t hard to learn, and good engineers usually pick it up very quickly. We’ve tried a lot of resources and here is a quick overview of what we recommend to learn Scala.
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.
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. The type system is turing complete. This should say enough about its potential.
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. This is because a special spark in a engineer is needed for him/her to be curious and interested in working with new languages. Having said that, Scala is no longer a new language. Its adoption has been growing steadily and fueled by the big data movement and platforms such as Spark.
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.
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.
Scala has been a great decision for us and it’s paying off in many ways.
A few weeks ago the Bitbucket team approached us to become one of the first Bitbucket integrator on Atlassian Connect.
Today we are happy to announce that the Codacy add-on is available on Bitbucket!!
Atlassian Connect for Bitbucket?
Atlassian Connect for Bitbucket is the new (r)evolution for Bitbucket, which is used by over 3 million developers worldwide. It offers developers the possibility to integrate their tools directly and hassle-free into Bitbucket.
Why does it matter?
Developers are spending more and more time switching between tools instead of focusing on what really matters: coding. Atlassian Connect for Bitbucket removes the barriers to integrate and finally unify the tools into the development lifecycle.
At Codacy we are very excited about this new fully integrated Bitbucket. As a provider of an automated code review software our mission is to save time and frustrations out of the code review process. Being able to provide our results on the tools that our users are already using is a priority for us.
Today we are also happy to announce that Pull Requests will be fully supported on Bitbucket. We are already working on a few exciting features to complement this add-on. Stay tuned, add Codacy to your Bitbucket projects, and consider creating your own add-ons!
Hello there, my name is Sandra Wolf and I’m the new team member of Codacy (yay!)
I have joined on the position of Developer Advocate, I will help you with all your #CodeReviews problems, and together we will take care of your technical debt. We will meet during tech conferences, meetups, user groups etc. I’m planning to be everywhere! I would love to help you make you as successful as possible using Codacy, and take advantage of everything that Codacy has to offer and make sure that you have fun using Codacy.