With source control, a commit should never break the build. Most importantly, though, it supports this next principle: Three: Really, Include All of One Issue I’ll include such things as supporting scripts or text files.By doing that, you are more likely to have included every relevant change, which again aids clarity when reviewing the commit history, investigating introduced defects, and so on. Frequently when a colleague sends along a code review to me and claims to have refactored a widget provider into a ligature maker and a scimitar extruder, I will whip out my file scanner of choice and search the entire code base for “WidgetProvider” to see if there are any strays. As an example, refactoring often entails having to rename things. In reality, it is all too easy to miss items in some ancillary files, so you ought to get into the habit of checking. You might think that it is only possible to miss such things as installer tweaks or config file updates: Surely you would never fail to include any changes to the code base proper, because omissions in the main code base would make your code fail to compile or your unit tests just fail. Collect it all together into a single code review.Įverything needs to be included. This would include such things as:Ĭonsider this list to be a starting point rather than an exhaustive enumeration! Add to it generously to meet your own team’s needs. Once you establish the single issue that you are working to fix – or enhance or introduce – you should include everything in your code review, and your eventual code commit, that is connected to that issue. This is the converse of the prior guideline. commit log) to find something, it is much easier to search, either programmatically or manually, when each commit has a single raison d’être.
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |