After a few months of development I’ve published my new app called Forehand. It’s an app for table tennis players and enthusiasts. It gives you an access to:
– daily news from table tennis world,
– videos showing how to improve skills – you can submit your links as well!
– tips what bats to choose,
– tournament sheets to help you with organising the tournaments.
There is a social aspect of the app as well. You can comment and interact with other users’ videos, you can personalise your profile.
I have just started working on the new app called Forehand. It’s going to be an app for table tennis players willing to stay up to date with table tennis news and to develop their skills. There are 2 versions of Forehand app coming: iOS and Android one. I put a placeholder landing page at forehand.app already. I’m aiming to release the app on both platforms in June this year.
My new iOS app has been approved by Apple and is live in the App Store. It’s EasierSelfies. Thanks to this app you can take selfies much easier and quicker than with the default iOS camera. I noticed while travelling with a friend that it’s hard to take a selfie with an iPhone because of its camera button’s position and I decided to create an app with a movable take photo button.
One week ago I added Dark Mode support to 2 of my apps: Quick10 and DMProjects. It adjusts automatically to iOS device settings. In the next update I might add a manual switch to turn it on / off as well.
We do it (almost) every day, we review someone else’s code and our code is being reviewed by our colleagues. It might be a bit tricky for junior developers to get used to it at the beginning though. Let’s write down some useful tips about code reviews.
We do it to improve a codebase.
A main purpose of a code review is to get a feedback on your code from a colleague from the team. The is no developer who writes perfect code, we all sometimes miss something, forget to test some edge case or commit some unneeded code. This is why code review is helpful – you get someone else looking at the same code, someone who approaches code in a bit different way, who tests different cases, someone who didn’t spend on your branch 4 last days and looks at it with a fresh mind.
Try to teach, not blame.
Blaming someone because of not perfect (in your opinion) code doesn’t help anyone. It destroys that code author’s day, it destroys your day too. Try to phrase your comments in a way you would like to get feedback too, the way it can be useful, full of knowledge. I think it often sounds nicer when you use plural form rather than a singular one while requesting some changes: for example “Can we move it to a class level?” rather than “Can you move it to a class level?”. It shows that the author of the code is not left alone, that you are trying to improve this code with them.
Link documentation pages, blog posts.
Different developers have different opinions how particular code could be improved, changed. There are many cases when it’s just subjective, there are a few different opinions and none of them is the only “right” one. On the other hand, there are certain well known patterns, that experienced developers just use automatically. Less experienced developers might not know about them. While trying to suggest such options try to give a link to documentation page, blog post or similar. It may have one nice side effect – author of the code may save this link in their notes, keep it for the future and learn quicker.
I think I will conclude the post at this point. Feel free to add your own tips in comments. Happy code-reviewing 🙂
I just published my second iOS game – its name is Postcardful 🙂
In Postcardful you are a traveler. You need to collect as many postcards as possible before you lose all 5 lives. Be careful, the planes aren’t your friends, better to avoid them. You can compete with your friends as well. Just keep an eye on a leaderboard.