a.k.a. "Software Professionalism"
I recently read Uncle Bob’s “The Clean Coder”. I have to say, this book slapped me in the face. There’s so much to discuss.
Reaching agreement from a bunch of code
I recently wrote about how to create a good pull request, this is, how to make your code changes easy to review and discuss. Now we’re going to talk about the second part: reviewing someone else’s code. This puts you on the reviewers side, and hopefully the person submitting code did follow our guidelines to make your life easier.
There are several approaches you can take to review the code, but we’re going to enumerate a checklist that you could use to minimize the usage of your time and the efficiency of the code review.
A meta-guide for creating easy to review requests
This has been a common question and a subject of debate since everyone has their opinions on what good code is and what bad code is. Regardless, the pull request is not about the code itself but about the actions of reviewing, adjusting, discussing and assimilating (merging) code, which may be good or bad in itself.
This will be later followed by a set of notes on how to perform a good code review.
Without further ado, let’s start with what is going to be a long article about sending a good pull request.
Aspects of software construction, deconstructed
Code Complete is like the reference manual of software development, regardless of the technology, industry or language you’re working in. And there are really good reasons for that. Let me tell you what I thought of this book.