├── Dockerfile ├── Makefile ├── hello_world.py ├── requirements.txt ├── README.md └── make_your_own_cheat_sheet.md /Dockerfile: -------------------------------------------------------------------------------- 1 | FROM ubuntu:16.04 2 | 3 | WORKDIR /tmp/workspace 4 | 5 | COPY . . 6 | 7 | ENTRYPOINT ["/bin/bash"] 8 | -------------------------------------------------------------------------------- /Makefile: -------------------------------------------------------------------------------- 1 | SHELL ?= /bin/bash 2 | 3 | build: 4 | @docker build -f Dockerfile -t local/hntrapr:latest . 5 | 6 | run: 7 | @docker run --name hntrapr -it local/hntrapr:latest 8 | 9 | cleanup: 10 | @docker stop hntrapr 11 | @docker rm hntrapr 12 | -------------------------------------------------------------------------------- /hello_world.py: -------------------------------------------------------------------------------- 1 | #!/bin/bash 2 | 3 | import argparse 4 | 5 | def parse_args(): 6 | parser = argparse.ArgumentParser() 7 | parser.add_argument("name") 8 | return parser.parse_args() 9 | 10 | if __name__ == "__main__": 11 | args = parse_args() 12 | print("Hello {}!".format(args.name)) 13 | -------------------------------------------------------------------------------- /requirements.txt: -------------------------------------------------------------------------------- 1 | awscli==1.11.136 2 | botocore==1.6.3 3 | certifi==2024.7.4 4 | cffi==1.11.4 5 | chardet==3.0.4 6 | colorama==0.3.7 7 | docutils==0.14 8 | enum34==1.1.6 9 | futures==3.1.1 10 | idna==3.7 11 | ipaddress==1.0.17 12 | jmespath==0.9.3 13 | keyring==10.4.0 14 | keyrings.alt==2.2 15 | pyasn1==0.3.2 16 | pycparser==2.18 17 | pygobject==3.26.1 18 | python-dateutil==2.6.1 19 | pyxdg==0.26 20 | PyYAML==5.4 21 | requests>=2.20.0 22 | s3transfer==0.1.10 23 | six==1.10.0 24 | urllib3==2.6.0 25 | -------------------------------------------------------------------------------- /README.md: -------------------------------------------------------------------------------- 1 | # How NOT to Review a Pull Request 2 | 3 | A guide, through negative examples, on avoiding code review pitfalls. 4 | 5 | ## Found Here 6 | 7 | * Slides (see slides section for different versions). 8 | * Review comments used in presentation. 9 | * Where the talk has been accepted/presented. 10 | * How to [make your own code review cheat sheet](make_your_own_cheat_sheet.md). 11 | 12 | ### Slides 13 | 14 | * [Slides (Heartifacts)](https://docs.google.com/presentation/d/1wLlvyI7akh_ybmO0MyzbBROukulH-Tw82RcT8kBuuWg/edit?usp=sharing). 15 | * [Slides (DevOps Midwest)](https://docs.google.com/presentation/d/1NS796mqIxhvx_XrCWJQii5fqbgIBIs5MkD77FsLnk6Y/edit?usp=sharing). 16 | * [Slides (BrightTALK)](https://docs.google.com/presentation/d/1pnnFWhkBuRC2dmyqyRboGGrUW_NR6knkZgzSVTZxyQA/edit?usp=sharing). 17 | * [Slides (All Day DevOps)](https://docs.google.com/presentation/d/1Jjim-KfZkUStvKueRdTnqXyWSaEspFXv2mt1kjXF6oI/edit?usp=sharing). 18 | * [Slides (Abstractions 2019)](https://docs.google.com/presentation/d/14stkV9dDSUsYIURdQNj6QY124Ys2RqLZa3nB_C52RZQ/edit?usp=sharing) 19 | 20 | ### Presentation Description 21 | 22 | There are many opinions and techniques for reviewing code. Instead 23 | of boring you to death with another philosophical rant, we will 24 | explore what not to say to your co-workers through examples. Once 25 | our journey is complete, we will have tools to help recognize these 26 | non-constructive behaviors before hitting send. Areas of interest 27 | will include team trust and safety, active and passive aggression, 28 | and creativity blockers. 29 | 30 | ### Where has the Talk Been Accepted/Presented 31 | 32 | * [Heartifacts April 2018 video](https://youtu.be/sBwbUVG7CDY) 33 | * [DevOps Midwest September 2018 slides](https://docs.google.com/presentation/d/1NS796mqIxhvx_XrCWJQii5fqbgIBIs5MkD77FsLnk6Y/edit) 34 | * [BrightTALK webinar slides](https://docs.google.com/presentation/d/1pnnFWhkBuRC2dmyqyRboGGrUW_NR6knkZgzSVTZxyQA/edit?usp=sharing) 35 | * [All Day DevOps October 2018 slides](https://docs.google.com/presentation/d/1Jjim-KfZkUStvKueRdTnqXyWSaEspFXv2mt1kjXF6oI/edit?usp=sharing) and [youtube video](https://youtu.be/2SZwgcLbVa8?t=1810), [vidyard video](http://play.vidyard.com/Fs7EBxJ7Huv9TA37xyZvKz) 36 | * [Abstractions 2019 slides](https://docs.google.com/presentation/d/14stkV9dDSUsYIURdQNj6QY124Ys2RqLZa3nB_C52RZQ/edit?usp=sharing) 37 | -------------------------------------------------------------------------------- /make_your_own_cheat_sheet.md: -------------------------------------------------------------------------------- 1 | # Make Your Own Code Review Cheat Sheet 2 | 3 | Because it is impossible to provide a code review cheat sheet that will apply 4 | to everyone, this guide is intended as a framework for creating the cheat 5 | sheet that best fits you and your team(s). The difficulty with creating a 6 | cheat sheet that would apply for everyone is each team will develop their 7 | own opinions on what should be required in all code reviews. Example: a 8 | mobile development team may have very different testing concerns from a 9 | team focused on operational tasks. 10 | 11 | Below, you will find lists of code review advice that is broken down by 12 | how applicable they are. When making your own code review cheat sheet, pick 13 | as many or as few of the points as best fit and then stick to those as a group. 14 | It is highly recommended to gather all team(s) who will be following the 15 | chosen code review guidelines to choose what best fits you together. If you 16 | do not have buy-in at the outset, it will be increasingly difficult to have 17 | all members follow your code review cheat sheet. And lastly, do not be afraid 18 | to fit the cheat sheet to your team(s) needs and create your own cheat sheet 19 | do's and don'ts, the below lists are not exhaustive! 20 | 21 | ## Almost Always Applicable 22 | 23 | * Listen to all feedback, even if you disagree with it. 24 | * Pause and consider your response to feedback when you feel negatively 25 | towards a commenter's opinion (active pausing). 26 | * Trust but verify the submitter. 27 | * Remember, we are all human and make mistakes sometimes, so assume good 28 | intentions from the submitter. Treat the submitter as you wish to be treated. 29 | * Don't be a jerk. 30 | * Clearly state the goal of the code change(s). 31 | * Verify the stated goal of the code change(s) match the ticket being worked. 32 | 33 | ## Sometimes Applicable 34 | 35 | * Tests must pass. 36 | * Ensure there is code coverage in the tests. 37 | * Keep the code change(s) as small as possible. The longer the code change(s), 38 | the greater the strain on reviewer attention spans. 39 | * Run the code locally to ensure it does what the submitter says. 40 | * Check the code with a code linter/validate the automated code lint run did 41 | not find any issues. 42 | 43 | ## Niche Considerations 44 | 45 | * Verify the code runs on all operating systems. 46 | * Check the code changes in multiple web browsers. 47 | * Validate the color changes follow your team/company's style guides. 48 | --------------------------------------------------------------------------------