The WebExpo 2016 event took place in Prague’s Lucerna Palace in late September 2016. As usual, the two days were dedicated to technologies, development, design and also the web application business. On top of great presentations, the visitors were able to test various new technologies, such as VR and robot control. Networking was an inherent part of this event, like any other event. Even though presentations were being given at three conference rooms simultaneously, it was easy to plan which one to attend because the presentations were grouped by themes.
Those two days were full of real inspiration. Rachel Andrew showed how to use lay-out techniques such as Flexbox a CSS Grid Layout, and how to deal with the insufficient support they get from browsers. Adrian Zumbrunnen demonstrated how animations can tell a story without interruption supporting human perception of space to better navigate our websites and applications. Mark Boulton explained that design is primarily about people, you work with and that you should spend more time fine-tuning proposals and talking to each other before jumping into coding too early. Yovka Pencheva reminded of the benefits of shifting a large part of the testing process to productionbecause it is impossible to detect everything in lab conditions. Footage and slides from all these great presentations are available. I highly recommend taking a look! What I found most inspiring was two presentations dealing with coding from a long-term perspective.
Extremely defensive
Marco Pivetta, whose nickname on the Internet is Ocramius, chose Extremely defensive PHP as the topic of his presentation. Defensive PHP is based on principles similar to defensive driving. No matter how good a driver you are, you’re better off being careful. None of you is the same man or woman that you were six months ago, or will be in five years’ time.
Marco recommends using principles like Poka Yoke, i.e. avoiding mistakes. An example of bad Poka Yoke is the USB, which exists in a 4D space but it’s almost impossible to plug it in right the first time or even the second time. Marco gives the RJ45 connector as an example of a good Poka Yoke because there is only one way to plug it in. He also points out the myth of code recyclability. Specific implementations of abstractions are not as perfect as the abstractions themselves, and will contain errors as a matter of statistics. If you take a look at your own code a few years from now, you will see for yourself that it is far from being perfect. What you can recycle is abstractions like interface and protocol or simply the ideas of interaction and logic. Since implementation always contains errors, Marco recommends you don’t try to solve all the problems of the mankind during coding. Instead, you should focus on your given problem.
In particular, Marco recommends creating all possible states immutable. Avoid using setters and move all you need into the constructor. Don’t use uninitialized variables because anything that may interfere with the state immutability will cause problems sooner or later. Stay away from optional dependencies to avoid unnecessary conditions and reduce code complexity. If you do expect a dependency, expect it in the constructor itself. And if you don’t require it, just insert a fake dependency that does nothing.
The next batch of advice covers the use of created objects:
-
Reduce the number of public methods down to the absolute minimum if the method is redundant or it has multiple uses and should not exist at all.
-
Remove all the logical switches in parameters and create separate methods.
-
In the initial state, all attributes should be private and classes final. By limiting inheritance, you avoid various glitches like massive chaining and breaking of encapsulation. Marco's blow shows the benefits and the instructions step-by-step. If you want to find out if it is really necessary to make a class inheritable, you should first make it's interface and then make it inheritable. If you’ve added no new logic, there is no reason to make your class inheritable.
Marco showed us what we can do to reduce the risk of problems and to provide other coders with legible and usable code. As he says, the use of the above principles is important for anyone whose code will be used by someone else later on, which is ever so important for anyone running public repositories.
How to Successfully Grow a Code Review Culture
So we’ve talked about how we can improve ourselves. But how about our colleagues? This is where Nina Zakharenko and her presentation fits in: How to Successfully Grow a Code Review Culture. Code review is one of the most effective ways to improve code quality, not just within a project but company-wide. It helps you find shortcomings, share know-how, leave a visible trace, and reduce the Bus factor remarkably.
The way you use review is not the same for everyone. What matters is the size of the team, type of product, and tolerance for error. There is no reason, however, to skip review.
So how do you grow a healthy culture? That is the question. Nina recommends the following steps and lessons:
-
Review is universal. Any code should go through a review no matter when it was written and by whom.
-
Review should be carried out by your direct colleagues. Bringing someone you’ve never seen into a review process is useless.
-
Use code style.
-
Don’t blame people for their mistakes. We all make mistakes.
If you are the one doing the review, you should be empathic and objective. Don’t point the finger. Give clear feedback, don’t be a perfectionist, and praise the good code you see. You should review anywhere between 200-400 lines of code within 60 to 90 minutes. Your attention goes down substantially after that. The review itself should not take more than two days after the code was submitted for review. If it takes longer than that, the lessons you take from the review are not as effective.
If you submit your code for a review, you should be careful with legibility. A code should be like a good joke – no explanations necessary. You should defend your code if you don’t agree with the review, but at the same time you should admit mistakes.
The first reviews tend to be difficult or even dreadful for junior coders, which is why Nina recommends inviting a more experienced colleague to be there during the review.
Once the positive review culture grows, you will avoid unpleasant situations.
To conclude...
If you stick to the principles Marco and Nina presented, you’ll be able to write a better code without unnecessary mistakes and room for misunderstandings, and you’ll be doing it in a more friendly and efficient team that keeps pushing you forward. That makes your work comfortable and helps you deliver better results. I really recommend watching Marco’s and Nina’s presentations. This text is just a preview, not a substitute. Thank you for reading this far!
