Search for a command to run...
I am an iOS Developer from Egypt, Cairo who likes Apple Products and UX studies
I enjoy reading about Entreprenuership and Scrum.
When no one is looking, I like to play around with Figma and build tools/ideas to help me during get things done quickly.
And I keep repeating epic gaming moments over and over again in my head and repeat narratives out loud in my room to regain a glimpse of how it felt when I first saw it (without altering the script)
No comments yet. Be the first to comment.
Navigating the Complexities of Domain-Driven Design: Bridging Tech and Business with Clarity and Bounded Contexts
And the start of a Journey with another DDD Book
How Command Pattern can be easily translated to Siri features
Breaking the Chains of Massive View Controllers: Lessons for SwiftUI and Beyond
A New day... a new productive day where my tiny blog gains a new post! https://tenor.com/view/terrific-tuesday-gif-25021333 Today is a bit of a quick one, its about a productivity tip you can imply if you work a lot with terminals, so without furth...
On this page
After doing my reading assignment of Lintschool, I read some fantastic articles about Code review.
Code review is a process where team members start reading what you've done for a certain feature and start writing comments and mention some things, it's like a final check before the code is merged, wherein this check there are a couple of things to be checked (that rhymed).
this process is essential for any team as I said in the last post, it helps to build trust and knowledge of the codebase.
But there are some things that hinder this process...
Massive pull requests usually occur when you are working on a big feature alone.
This results in some issues for the reviewer, having to read through large files due to a large pull request is tedious, you just want to get to the end of it and get back to your work, and when the reviewers feel this, you will just give an over-the-surface review
while small and chunked PRs will give you an effective review of what you were missing, and leave too little room for bugs to hide.
But this takes us to the next question, how do we optimize our Code Review process?
Well, there are a couple of good practices when creating PRs
first things first, It is your responsibility to make it easy for your reviewers to review your code, they can't spend as much time as you did digging into the context of the problem your PR is trying to solve, therefore you need to present your PR in a friendly form, hence comes the Pull Request Template, you can find lots of PR templates here you can edit these templates to your use case and add it to your pull requests, doing so gives clear information about what this PR is trying to achieve and what goals it met, so the reviewer knows what the code at hand should output, it also gives you a clear mind of what happend in this PR and organize your train of thoughts of what is needed to tell reviewers I did that
Splitting PRs is a hard process when it occurs midway when you find out that the reviewers won't review your changes because they are simply too big, don't get frustrated when that happens, you should make the effort in tidying it up and make it more reviewable
commit messages are super important in Code Reviews, they are the history of the PR, not just they allow the reviewer to follow in your footsteps, but if you happen to get your PR large, you can split the PR by cherrypicking the branch's commits and to do that easily you need to leave good commit messages to help you do so.
we all do mistakes and to avoid them, you must know them beforehand, here are some mistakes you can avoid in the future...
Too big features (i.e: long feedback loop) You're violating Agile, Agile is mostly about keeping your feedback loo short, you should do what you can to keep it short whenever, use pair programming, sit with the product designers and make sure you understand what they mean and want, make sure you write test cases before you start digging into code and show those test cases to your lead so that when you write the code you know they match the business requirements
You did too much work (i.e: Violating the YAGNI) you worked too much on enhancing the feature, or on cleaning the code, that's still a violation, but cleaning the code should be little by little like the boy scouts rule, leaving the campground cleaner than we found it
It turned out to be harder than estimated
New code wasn't covered by tests Tests have one important aspect, which is documenting the code written, sometimes the way to show the reviewers what the code is about is showing them the tests, if you miss it, they can spend a lot of time figuring out the consequences of every line of code you wrote in the PR, to avoid this mistake, you should introduce a proper test suite to your codebase
Those are some of the things you should follow when creating changes you want to merge to the codebase, but if you happen to make a massive pull request, you should definitely read this article about it
Splitting PRs is a good action that can help you minimize the headaches for your teammates a lot when they are reviewing, and it is your responsibility to make the reviewing process for your teammates easy and quick because they have other work to do than reviewing your PR.
