Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

Professional Code Reviews - Bogdan Gusiev

50 views

Published on

Ruby Meditation #20
February 17, 2018
Kyiv

Published in: Software
  • Be the first to comment

Professional Code Reviews - Bogdan Gusiev

  1. 1. CODE REVIEW PROCESSCODE REVIEW PROCESS BOGDAN GUSIEVBOGDAN GUSIEV
  2. 2. CODE REVIEW TENDS TO BE NATURALCODE REVIEW TENDS TO BE NATURAL
  3. 3. CODE REVIEW YOURSELFCODE REVIEW YOURSELF
  4. 4. ASKING FOR HELPASKING FOR HELP
  5. 5. SPONDANUOUS CODE REVIEW PROBLEM:SPONDANUOUS CODE REVIEW PROBLEM: TOO LATETOO LATE
  6. 6. EVERYTHING HAD CHANGED BYEVERYTHING HAD CHANGED BY GITHUBGITHUB
  7. 7. DO I NEED A CODE REVIEW?DO I NEED A CODE REVIEW? IMHO: NEW PROJECTSIMHO: NEW PROJECTS DON'T NEED A FORMAL CODE REVIEW AT ALLDON'T NEED A FORMAL CODE REVIEW AT ALL
  8. 8. CODE REVIEW EVOLUTIONCODE REVIEW EVOLUTION 1. Spontanuous Code Reviews 2. "When I am not sure" code reviews 3. Formal Code Review Process 4. Required code review for certain changes 5. Required code reviews for everything Fails Driven Process
  9. 9. CODE REVIEW PROPERTIESCODE REVIEW PROPERTIES NECESSITYNECESSITY Optional Required PROCESSPROCESS Informal Formal PEOPLEPEOPLE Dedicated Distributed
  10. 10. POSITION IN A PROCESSPOSITION IN A PROCESS 1. Planning 2. Coding 3. Code Review 4. QA 5. Release QA <-> Code Review Formally QA a er Code Review
  11. 11. 1. Make a fork (optional) 2. Create a Branch 3. Open a Pull Request 4. Wait for review 5. Discuss & Fix 6. Merge
  12. 12. CODE REVIEW ISCODE REVIEW IS A PROCESS OFA PROCESS OF REVIEWING AND APPROVINGREVIEWING AND APPROVING CODE CHANGESCODE CHANGES BEFOREBEFORE THEY GET ACCEPTED TO THE MAINSTREAMTHEY GET ACCEPTED TO THE MAINSTREAM
  13. 13. HOW TO REVIEW?HOW TO REVIEW?
  14. 14. FIX COMMON THINGS FIRST?FIX COMMON THINGS FIRST? Typos Whitespace Code Style Wrong Direction!
  15. 15. WHERE TO LOOK?WHERE TO LOOK? Things that are most significant should be reviewed first which are ones that are the most hard to change.
  16. 16. TOP TO BOTTOM CODE REVIEWTOP TO BOTTOM CODE REVIEW 1. Architecture 1. Problem Solution 2. Public APIs 3. Database Schema 4. Object Oriented Design 5. Public Method Signatures 2. Implementation 1. Classes & Methods 2. Views 3. Tests 4. Code Style, Typos, Whitespace
  17. 17. PROBLEM SOLUTIONPROBLEM SOLUTION 1. Problem makes sense 2. Problem Solved 3. High Level Security 4. High Level Performance
  18. 18. ONLY SHOW CUSTOM PROPERTIES WITH AT LEAST ONE VALUE IN SELECTONLY SHOW CUSTOM PROPERTIES WITH AT LEAST ONE VALUE IN SELECT def selectable_product_categories + ProductCategory.with_at_least_one_product - ProductCategory.all end ProductCategory. where("not exists(select * from products where ...)"). count # => 0
  19. 19. HIGH LEVEL SECURITYHIGH LEVEL SECURITY EX. FEATURE:EX. FEATURE: LOGIN USER AUTOMATICALLY WHEN IT CLICKS ON THE LINK IN THE EMAILLOGIN USER AUTOMATICALLY WHEN IT CLICKS ON THE LINK IN THE EMAIL THIS IS NOT VERY SECURETHIS IS NOT VERY SECURE
  20. 20. HIGH LEVEL PERFORMANCEHIGH LEVEL PERFORMANCE CHECK IF THE CHANGECHECK IF THE CHANGE Touches Performance sensitive code Will be slow for particular data No pagination when there are 1000+ records to display
  21. 21. PUBLIC APISPUBLIC APIS USING HTTP API AS EXAMPLEUSING HTTP API AS EXAMPLE 1. Efficiency 2. Logical Endpoints 3. Request Parameters 4. Response Format WHATEVER THAT IS DOCUMENTEDWHATEVER THAT IS DOCUMENTED
  22. 22. API INEFFICIENCY EXAMPLEAPI INEFFICIENCY EXAMPLE EFFICIENT WAY?EFFICIENT WAY? Purchase.has_one :referral GET /purchases/:order_number { id: 1, order_number: '1838382', referral_id: 17 } POST /referrals/:id/approve POST /purchases/:order_number/referral/approve
  23. 23. RESPONSE FORMATRESPONSE FORMAT # Easier render json: @campaign.view_setups.to_json # Extensible render json: {view_setups: @campaign.view_setups.to_json}
  24. 24. BAD API EXAMPLEBAD API EXAMPLE Talkable.publish('talkable_offer_close', null, true); Talkable.publish('offer_close', null, true);
  25. 25. ANALYZE USAGE FIRSTANALYZE USAGE FIRST BUT NOT IMPLEMENTATIONBUT NOT IMPLEMENTATION setCustomProperty: function (person, properties) { ... } setCustomProperty('advocate', {key: value}) setCustomProperty('friend', {key: value}) setAdvocateCustomProperty: function(properties) { private_stuff.setCustomProperty("advocate", properties); }, setFriendCustomProperty: function(properties) { private_stuff.setCustomProperty("friend", properties); },
  26. 26. DATABASE SCHEMADATABASE SCHEMA 1. Relations between tables 2. Data Columns 3. Naming
  27. 27. EFFICIENT RELATIONSEFFICIENT RELATIONS 1. What are the variants? 2. Was the best one selected?
  28. 28. EFFICIENT SCHEMAEFFICIENT SCHEMA add_column :images, :dimension, :string class Image < AR::Base def width dimension.split("x").first end def height dimension.split("x").last end end add_column :images, :width, :integer add_column :images, :height, :integer
  29. 29. DATA SHOULD BEDATA SHOULD BE EASY TO READEASY TO READ EVEN IF IT MAKES ITEVEN IF IT MAKES IT HARDER TO WRITEHARDER TO WRITE
  30. 30. OBJECT ORIENTED DESIGNOBJECT ORIENTED DESIGN 1. Reflects Real World 2. Inheritance 3. Constructors
  31. 31. REVIEWING CONSTRUCTORSREVIEWING CONSTRUCTORS CIRCULAR DEPENDENCYCIRCULAR DEPENDENCY class Field def initialize @cells = Array.new(10) do Array.new(10) { Cell.new(self) } end end end class Cell def initialize(field) @field = field end end
  32. 32. OBJECT CONSTRUCTORS ARE IMPORTANT:OBJECT CONSTRUCTORS ARE IMPORTANT: Which things are required to use an object? What are the object responsibilities? Theoretical limit Which methods can be implemented in the object? Which things would need to be passed to methods as arguments? Constructor defines object API
  33. 33. REVIEWING CONSTRUCTORSREVIEWING CONSTRUCTORS UNDEFINED CONTEXTUNDEFINED CONTEXT class ApplicationController before_action do WhateverRequestAnalyzer.new(request).analyze end end CrawlerRequestAnalyzer.new( request.user_agent, request.url, request.content_type ).analyze
  34. 34. PUBLIC METHOD SIGNATURESPUBLIC METHOD SIGNATURES 1. Placement 2. Arguments 3. Name
  35. 35. METHOD PLACEMENTMETHOD PLACEMENT class User def approve!(referral) end # OR class Referral def approve!(user) end
  36. 36. METHOD ARGUMENTSMETHOD ARGUMENTS this.extractUserData(this.data)
  37. 37. IMPLEMENTATIONIMPLEMENTATION
  38. 38. CLASSES & METHOD BODIESCLASSES & METHOD BODIES Each method or class separately Check one by one: 1. Approach & Algorithm 2. Performance 3. Security 4. Minimalism 5. Local Variable Names
  39. 39. PERFORMANCE & VULNERABILITIESPERFORMANCE & VULNERABILITIES In the ideal world performance and vulnerabilities should not change the code structure. In practice it can but we should try hard to fix performance problems only at the implementation level
  40. 40. GOOD PERFORMANCE PATCHGOOD PERFORMANCE PATCH def core_options - { header: name, description: description, group: group } + @core_options ||= { header: name, description: description, grou end - @campaign.locale_entries.each do + @campaign.locale_entries.preload(:variants).each do
  41. 41. GOOD VULNERABILITY PATCHGOOD VULNERABILITY PATCH -{{ advocate_info.first_name }} +{{ advocate_info.first_name | escape }}
  42. 42. SECURITYSECURITY Approach Security (Step 1) Is it secure to have this feature? Is it secure to implement the feature this way? Vulnerabilities XSS Allowed Parameters Backend Authorisation check Authorisation for UI elements
  43. 43. TESTSTESTS 1. Use Cases Coverage 2. Formal Code Coverage 3. Tests Implementation
  44. 44. TOP TO BOTTOM IDEATOP TO BOTTOM IDEA IT IS BAD TO:IT IS BAD TO: Discuss the method name before the method existence as a fact Discuss Code Style before implementation itself
  45. 45. BOSS CONTROL APPROACHBOSS CONTROL APPROACH Ensure top points from the list are always performed Choose X things on top of the list to double-check and delegate the rest completely
  46. 46. CODE REVIEW CULTURECODE REVIEW CULTURE Be Polite Admit good things First things first Reduce number of cycles Save Author's time Save Your time
  47. 47. TOP TO BOTTOM CODE REVIEWTOP TO BOTTOM CODE REVIEW 1. Architecture 1. Problem Solution 2. Public APIs 3. Database Schema 4. Object Oriented Design 5. Public Method Signatures 2. Implementation 1. Classes & Methods 2. Views 3. Test Coverage 4. Code Style, Typos, Whitespace

×