{"id":2294,"date":"2020-03-26T06:38:59","date_gmt":"2020-03-26T06:38:59","guid":{"rendered":"https:\/\/lgconsultancy.wpcomstaging.com\/?p=2294"},"modified":"2022-08-02T12:53:35","modified_gmt":"2022-08-02T12:53:35","slug":"code-review","status":"publish","type":"post","link":"https:\/\/lng-consultancy.com\/staging\/5474\/code-review\/","title":{"rendered":"Code Review"},"content":{"rendered":"\n

The activity of systematically examining computer source code with the intent of finding mistakes <\/strong>created or overlooked during the development process, thus improving<\/strong> the overall quality of the software.<\/p>\n\n\n\n

Processes to do it <\/h2>\n\n\n\n

There\u2019re commonly three processes to do Code Review.<\/p>\n\n\n\n

  1. Pair Programming (Mostly used in the Extreme Programming)<\/ins><\/li>
  2. Informal Walk through<\/li>
  3. Formal Inspections<\/li><\/ol>\n\n\n\n

    We commonly use following ways during code review:<\/strong><\/h4>\n\n\n\n
    • Over-the-shoulder<\/strong> \u2013 One developer looks over the author\u2019s shoulder as the latter walks through the code. In case of remote working, Visual Studio live share<\/strong> is one of the common ways to do it.

      <\/li>
    • Email pass-around<\/strong> \u2013 Source code management system emails the code to reviewers automatically after check-in is made.

      <\/li>
    • Pair Programming<\/strong> \u2013 Two authors develop code together at the same workstation, either on same desk or remote. This is common in Extreme Programming.

      <\/li>
    • Tool-assisted code review<\/strong> \u2013 Authors and reviewers use specialized tools designed for peer code review. Pull requests on Github<\/strong> and azure Devops<\/strong> are good examples of this.<\/li><\/ul>\n\n\n\n

      Why do we\nneed to do code review?<\/strong><\/h2>\n\n\n\n
      1. Consistent design and implementation throughout the project:<\/strong><\/span> There\u2019s no one right way of writing code. Every developer has his\/her own style of doing it. This can sometimes lead to a lot of different styles of implementations\/designs to a similar problem, in one project. Code Reviews and discussions toward implementation, will help bringing consistency to that.
        <\/li>
      2. Minimizing your mistakes and their impact:<\/strong><\/span> The most obvious benefit of code reviews is that it will pick up mistakes very quickly. A wrong checked-in code will waste time in many ways. For example; Wasting your time in deploying or QA\u2019s time in prioritizing your task and the focus gets shifted to not-so-worthy areas. Hence, code review is an opportunity to reduce that impact.
        <\/li>
      3. Ensuring project quality and meeting requirements:<\/strong><\/span> It\u2019s very common for developers to misunderstand the requirements and make assumptions about future requirements. Picking up issues at an early stage will improve the quality. Picking up late will make it patches.
        <\/li>
      4. Improving code performance:<\/span> <\/strong>One of the key focus of code review is performance of the code. So, code reviews always result in better Performance.
        <\/li>
      5. Sharing new techniques:<\/span> <\/strong>Sharing is Caring. Code review gives you a lot of opportunities to share trickiest tips\/techniques with your colleagues. It also gives you equal chances to read your colleagues codes and learn from their techniques.
        <\/li>
      6. Code reviews helps with better estimates:<\/span> <\/strong>When it comes to estimating a problem\u2019s solution; Consistency in Project structure, knowledge of your team member\u2019s modules and equal understanding of the techniques helps a lot. All of the three things improve with code review.
        <\/li>
      7. Code reviews enable time off:<\/strong><\/span> With code review, you start owning your teammate\u2019s modules. There\u2019s no one guy who owns a modules\/page. Which means everyone gets to take some time off without creating a Business Risk.
        <\/li>
      8. Code reviews mentor new engineers:<\/strong><\/span> It mentors new developers in many ways. It creates awareness about the things that senior developers focus on. It gives new developers the scope to learn from their Sr. fellows. It gives them opportunities to ask questions like why things are being done differently from their understanding. Important<\/code>: <\/strong>It\u2019s very important the Jr. developers\u2019 comments on Pull requests are taken as seriously as a Sr. developer.
        <\/li>
      9. Code Reviews Reduce Bugs\/Defects (by 60% as per global stat):<\/span> <\/strong>Yes, you\u2019re right, I do not have any data to back this up. But I read in many blogs that Code Reviews reduce the bug count by 60 to 80%. I decided to believe the 60%.
        <\/li>
      10. Code Reviews Improve the Speed of Development:<\/span> <\/strong>If we measure, speed of development= number of lines of code. It\u2019s the number of Stories that met definition of done. With reducing bugs, high quality code, reusing of code, focusing on right solutions \u2013 it\u2019s a No-brainer to understand that it improves speed of Software Development.
        <\/li>
      11. Code Reviews Encourage a Healthy Engineering Culture:<\/span> <\/strong>This is one of the biggest gains of a Code Review process. It encourages a healthy engineering culture.
        A culture where team members care about each other\u2019s task. A culture where giving critique feedback is seen as a positive thing. A culture of Collaboration, Courage, Trust, Growth and Continuous Improvement.<\/li><\/ol>\n\n\n\n

        \u201cCode reviews help spread knowledge through a development team. Reviews help more experienced developers pass knowledge to less experienced people. They help more people understand more aspects of a large software system. They are also very important in writing clear code. My code may look clear to me, but not to my team. That\u2019s inevitable\u2013it\u2019s very hard for people to put themselves in the shoes of someone unfamiliar with the things they are working on.\u201d <\/em>\u2013 <\/p> Martin Fowler, Refactoring: Improving the Design of Existing Code<\/strong> <\/cite><\/blockquote>\n\n\n\n

        <\/p>\n\n\n\n

        So, what\nexactly is a code review?<\/strong><\/h2>\n\n\n\n
        • Are there any obvious logic errors in the code?<\/li>
        • Looking at the requirements, are all cases fully\nimplemented?<\/li>
        • Are the new automated tests enough for the new\ncode? Do existing automated tests need to be rewritten to account for the\nchanges in the code?<\/li>
        • Does the new code conform to existing style\nguidelines?<\/li><\/ul>\n\n\n\n

          Four\nsure-shot Rules in the Process of Code Review<\/strong><\/h4>\n\n\n\n

          In my opinion, four rules must be followed without exception,\nto successfully integrate code reviews into a team:<\/p>\n\n\n\n

          • Everyone gets code reviewed:<\/strong><\/span> If you write a code, whether it\u2019s x86 assembler or HTML; whether you\u2019re an intern or the CEO; Every one of your commits needs to be reviewed.

            <\/li>
          • Everyone reviews code:<\/strong><\/span> We can all learn from code and we all have something to teach. Making sure that everyone on the team participates in reviews & ensures that teaching and learning happens.

            <\/li>
          • Every PR gets reviewed:<\/span> <\/strong>To say that some PRs don\u2019t need to be reviewed is to say that you know which PRs will have defects. Every PR should be reviewed, so flip the switch in your SCM tool of choice and require every PR entering the project to be code reviewed.

            <\/li>
          • Every change gets reviewed:<\/strong><\/span> Like the previous but at a lower level and just as important. Every change made within a PR needs a review. Be it code or comment, it all needs a once-over.<\/li><\/ul>\n\n\n\n

            Submitting\na Pull Request<\/strong><\/h4>\n\n\n\n

            All code reviews start with a pull request (PR). Every tool\nhandles them a little differently, so you\u2019ll want to check the documentation\nfor the specifics for your tool. When submitting a PR, there are three\nguidelines you need to follow:<\/p>\n\n\n\n

            1. Review your changes:<\/span> <\/strong>Do this to avoid unnecessary follow up commits. Here you should double check to make sure everything is included in the PR; all caveman debugging code is removed (i.e. Logger.info \u201cgot here\u201d); and all the tests pass.

              <\/li>
            2. Describe your changes:<\/span> <\/strong>There was a reason for the changes you made, those need to be provided in the subject and description of the PR. Oftentimes, it makes sense to give reference to the \u201cticket\u201d associated with the changes. Also, if there are areas you believe warrant greater attention or require clarification, make a note about them in the description.

              <\/li>
            3. Request the right reviewers:<\/strong><\/span> It seems obvious, but you want the right people reviewing your code; people who will have a background in the PR. It probably wouldn\u2019t make sense for an iPhone developer to request an Android developer to review his or her code.

              <\/li>
            4. Keep the Pull Request as short as possible:<\/strong><\/span> Try to divide your task into small logical tasks. Submitting your PRs in small portion helps with a quicker feedback cycle.<\/li><\/ol>\n\n\n\n

              Reviewing\na Pull Request<\/strong><\/h4>\n\n\n\n

              Once a pull request has been submitted, it\u2019s time to review\nit. To do that, you\u2019ll want to first be mindful off these four things:<\/p>\n\n\n\n

              1. Know what the problem is<\/span>:<\/strong> It\u2019s hard to tell if a solution will solve the problem if you don\u2019t know what the problem is. To that end, read the description provided in the PR and any associated documentation provided in the ticket.

                <\/li>
              2. Complete the review within 4-6 hours:<\/strong><\/span> This means exactly what it says. A short feedback loop allows developers to keep focused on the issue at hand. There\u2019s nothing worse than submitting a PR, starting a new feature, and then finally getting feedback a week later.

                <\/li>
              3. Take your time:<\/strong><\/span> Reading code is mentally demanding and there\u2019s only so much you can do before your focus begins to deteriorate. Try not to exceed 500 lines an hour, and if you must break up the review into multiple sessions. Your brain will thank you, and so will your teammates.

                <\/li>
              4. You\u2019re accountable:<\/strong><\/span> When you click the \u201cApprove\u201d button, you\u2019re saying that you not only reviewed the code, but that it solves the problem and it is good enough to be included in the code base. You are also taking partial responsibility for problems that arise from it.<\/li><\/ol>\n\n\n\n

                What\nto Look For<\/strong><\/h4>\n\n\n\n

                When you receive a request for review and you begin looking\nthrough the code, what should you look for? Rather than providing you with a\nlist of a hundred code smells, potential problems, or gotchas you might see, I\nthink it makes sense to provide a high-level view of what to look for:<\/p>\n\n\n\n

                1. Does the code do what it\u2019s supposed to do?<\/span><\/strong> This doesn\u2019t mean you need to start the app and enter into a full QA cycle. You should be able to tell from the code if it is likely to solve the problem or not.

                  <\/li>
                2. Are there tests?<\/span><\/strong> If so, that\u2019s great. Do they pass? Do they make sense? If tests aren\u2019t provided for the code, reject it and explain why.

                  <\/li>
                3. Has the documentation been updated to reflect the changes?<\/span><\/strong> If your project has documentation, make sure the changes in the PR are reflected in it. The only thing worse than no documentation is wrong documentation.

                  <\/li>
                4. Are things named well?<\/span><\/strong> Naming is one of the hardest things about programming, do the names used in the PR accurately describe what they represent or what they do?

                  <\/li>
                5. Is there duplicate code?<\/span><\/strong> As you are reviewing the code, do you see blocks which are duplicated? Would it make sense to extract them into their own class, module, or function?

                  <\/li>
                6. Are there potential performance issues?<\/span><\/strong> If so, explain what they are and provide a solution.

                  <\/li>
                7. YAGNI (You Ain\u2019t Gonna Need It)<\/span><\/strong> Has code been added which isn\u2019t needed yet and isn\u2019t part of the solution? Comment on it. If it isn\u2019t needed yet, it shouldn\u2019t be there.

                  <\/li>
                8. The Boy Scout rule<\/span><\/strong> If there is one of the guidelines you should remember, it\u2019s this: \u201cHas the code been left in a better state than what the developer found it?\u201d<\/li><\/ol>\n\n\n\n

                  Giving\nFeedback<\/strong><\/h2>\n\n\n\n

                  If you\u2019re performing a code review, you\u2019re going to have to give feedback. It may be as simple as \u201cLooks good!\u201d, \u201cship it!\u201d, or even just a \u201c\ud83d\udc4d\u201d, but more often than that; you\u2019ll need to critique the code, point out issues, and ask questions. As developers, we tend to rush through the communication related tasks to get back to what we\u2019re most comfortable with. In our haste, we become terser and more direct; resulting in unnecessary problems. To avoid any potential problems, try following these guidelines:<\/p>\n\n\n\n

                  \n

                  1. Ask Questions<\/strong><\/h4>\n\n\n\n

                  Just because someone\u2019s asked you to review their PR doesn\u2019t\nmean your initial response must be either \u201cApprove\u201d or \u201cReject\u201d. Instead, think\nof it as the beginning of a conversation<\/strong>. Like any conversation, there will\nbe points you will need clarification on, in order to keep moving forward. The\nsame is true for PRs. If there is logic or design choices you don\u2019t understand,\nask the author to clarify those choices. It may be that he or she doesn\u2019t fully\nunderstand it either. If you don\u2019t understand it now, what\u2019s the likelihood\nyou\u2019ll understand it the next time you encounter it?<\/p>\n\n\n\n

                  2.\u00a0\u00a0Be Articulate<\/strong><\/h4>\n\n\n\n

                  Text can\nbe a horrible medium for communication. It doesn\u2019t convey facial expressions,\ntone of voice \u00a0or any sort of body\nlanguage. It\u2019s just text. The meaning of a sentence can vary just by where we\nas the reader put emphasis. For example, read the sentence \u201cWhy did you write\nit this way?\u201d in the following ways:<\/p>\n\n\n\n

                  • Why did\n you\u00a0write it<\/em>\u00a0this way?<\/li>
                  • Why<\/em>\u00a0did you write it this\n way?<\/li>
                  • Why<\/em>\u00a0did you write it\u00a0this<\/em>\u00a0way?<\/li>
                  • Why did\u00a0you<\/em>\u00a0write\n it this way?<\/li>
                  • Why<\/em>\u00a0did you write it\u00a0this\n way<\/em>?<\/li><\/ul>\n\n\n\n

                    Do you\nhear the difference? It\u2019s the same text, just read with different emphasis. As\nmuch as we hate to admit it, we\u2019re emotional creatures, and as such we bring\nour emotions with us into whatever activities we do, including reading. If\nwe\u2019ve had a bad day or didn\u2019t sleep well, it\u2019s easy to read feedback in a more\nnegative light than what was intended. It\u2019s therefore incumbent upon the\nreviewer to take extra care when writing comments.<\/p>\n\n\n\n

                    By taking\nmore time to clearly communicate about what\u2019s good or bad in the code, ask\nclear questions and provide potential solutions; it reduces potential\nback-and-forth between you and the submitter. This leads to faster development\ntimes. Furthermore, adding clear explanations gives the submitter context and\ninsight into what you were thinking at the time of the review, reducing the\nlikelihood of them taking things the wrong way.<\/p>\n\n\n\n

                    3.\u00a0\u00a0Critique the Code, Not the Coder<\/strong><\/h4>\n\n\n\n

                    I\u2019ve never\nseen this played out within an organization, but I\u2019ve heard stories and I\u2019ve\nseen it in open source projects. I hate that I even must mention it, but\nreviewing code is neither time for the reviewer to play a game of \u201cGotcha\u201d Nor\nshould it be used as an opportunity to belittle the submitter.<\/p>\n\n\n\n

                    We all\nmake mistakes and there isn\u2019t a single individual that gets to know the right\nway to do everything. When a developer submits their code for review, they\u2019re\ntrusting the reviewer to be fair and provide honest and helpful feedback. Don\u2019t\nbetray that trust.<\/p>\n\n\n\n

                    4.\u00a0\u00a0Compliment Good Code<\/strong><\/h4>\n\n\n\n

                    The last\nthing to remember to do as a reviewer is compliment good work when you see it.\nSimple comments like \u201cThat\u2019s cool!\u201d, \u201cI didn\u2019t know you could do that!\u201d, or\neven just, \u201cGood job\u201d can be great encouragements to the submitter. It doesn\u2019t\nhave to be done in every code review, but when you see something good, call it\nout.<\/p>\n<\/div><\/div>\n\n\n\n

                    As my mom likes to say, \u201cA candle loses nothing by lighting another candle.\u201d<\/p>Someone\u2019s mom \ud83d\ude42<\/cite><\/blockquote>\n\n\n\n

                    Receiving\nFeedback<\/h2>\n\n\n\n

                    Choose not to be harmed \u2014 and you won\u2019t feel harmed.
                    Don\u2019t feel harmed \u2014 and you haven\u2019t been.<\/p> \u2013\u00a0Marcus Aurelius <\/cite><\/blockquote>\n\n\n\n

                    This piece of the code review process is the hardest: it\u2019s how to receive feedback. It\u2019s the hardest because it involves our emotions and our ego. Unlike other creative endeavors which are subjective in their nature, programming has a strong objective element to it. When an art critic gives a negative review of a piece of work, the artist can always respond with, \u201cThe critic failed to see my vision.\u201d With programming, on the other hand, a code reviewer can say a piece of code is wrong and then provide evidence to support the argument. There isn\u2019t a comeback for facts.<\/p>\n\n\n\n

                    On a\npersonal level, receiving code reviews is the most important part of the code\nreview process. It\u2019s at this point that you have the opportunity to grow. Will\nyou listen to the suggestions offered or disregard them? Listening will require\nhumility; you might have to admit that you\u2019re wrong about some piece of your\nwork. You might have to change how you\u2019ve \u201calways done it\u201d. But it\u2019s the only\nway to grow.<\/p>\n\n\n\n

                    In most\ncases, the feedback we receive is done with the best intent. Most of the time\nwe review code, we\u2019re just looking for potential problems \u2013 it\u2019s rare that\nsomeone has a personal grudge against the submitter \u2013 so try to see it in that\nlight. Furthermore, both submitter and reviewer want the same thing: high\nquality functioning software \u2013 Hence, focus on that.<\/p>\n\n\n\n

                    In Closing<\/strong><\/strong><\/h2>\n\n\n\n

                    Code\nreviews are the most effective activity development teams can adopt to drive\ndown defects. Perhaps more importantly, they\u2019re the best pursuit your team can\nengage in; to transfer knowledge, increase overall development speed, promote a\nhealthy engineering culture and build a sense of ownership within the team.\nNone of this should be underestimated as healthy engineering cultures are far\nmore effective at attracting and keeping the best developers.<\/p>\n\n\n\n

                    When\nincorporating code reviews into your organization, remember the four rules.<\/p>\n\n\n\n

                    \n
                    • Everyone\u2019s code gets reviewed<\/li>
                    • Everyone reviews code<\/li>
                    • Every PR gets reviewed<\/li>
                    • Every change gets reviewed<\/li><\/ul>\n<\/div><\/div>\n\n\n\n

                      Whether your submitted code is to be reviewed or you have been asked to do the review, remember foremost that your teammates all have the same goal: doing quality work to create a substantial product. You\u2019re on the same team. Encourage one another, hold each other accountable, and regardless of whether you\u2019re the submitter or reviewer you can learn and grow from each Pull Request.<\/p>\n\n\n\n

                      Be humble enough to do so.<\/p><\/blockquote>\n\n\n\n

                      Gaurav Sharma<\/strong><\/p>\n","protected":false},"excerpt":{"rendered":"

                      The activity of systematically examining computer source code with the intent of finding mistakes created or overlooked during the development process, thus improving the overall quality of the software. Processes to do it There\u2019re commonly three processes to do Code Review. Pair Programming (Mostly used in the Extreme Programming) Informal Walk through Formal Inspections We […]<\/p>\n","protected":false},"author":20,"featured_media":7317,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"quote","meta":{"_acf_changed":false,"nf_dc_page":"","om_disable_all_campaigns":false,"_monsterinsights_skip_tracking":false,"_monsterinsights_sitenote_active":false,"_monsterinsights_sitenote_note":"","_monsterinsights_sitenote_category":0,"_jetpack_memberships_contains_paid_content":false,"footnotes":""},"categories":[32],"tags":[31,33],"class_list":["post-2294","post","type-post","status-publish","format-quote","has-post-thumbnail","hentry","category-software-development","tag-codereview","tag-softwaredevelopment","post_format-post-format-quote"],"acf":[],"yoast_head":"\nCode Review - L&G Consultancy<\/title>\n<meta name=\"robots\" content=\"index, follow, max-snippet:-1, max-image-preview:large, max-video-preview:-1\" \/>\n<link rel=\"canonical\" href=\"https:\/\/lng-consultancy.com\/code-review\/\" \/>\n<meta property=\"og:locale\" content=\"en_US\" \/>\n<meta property=\"og:type\" content=\"article\" \/>\n<meta property=\"og:title\" content=\"Code Review - L&G Consultancy\" \/>\n<meta property=\"og:description\" content=\"The activity of systematically examining computer source code with the intent of finding mistakes created or overlooked during the development process, thus improving the overall quality of the software. Processes to do it There\u2019re commonly three processes to do Code Review. Pair Programming (Mostly used in the Extreme Programming) Informal Walk through Formal Inspections We […]\" \/>\n<meta property=\"og:url\" content=\"https:\/\/lng-consultancy.com\/code-review\/\" \/>\n<meta property=\"og:site_name\" content=\"L&G Consultancy\" \/>\n<meta property=\"article:published_time\" content=\"2020-03-26T06:38:59+00:00\" \/>\n<meta property=\"article:modified_time\" content=\"2022-08-02T12:53:35+00:00\" \/>\n<meta property=\"og:image\" content=\"https:\/\/lng-consultancy.com\/wp-content\/uploads\/2020\/03\/Untitled-design-33.jpg\" \/>\n\t<meta property=\"og:image:width\" content=\"1200\" \/>\n\t<meta property=\"og:image:height\" content=\"628\" \/>\n\t<meta property=\"og:image:type\" content=\"image\/jpeg\" \/>\n<meta name=\"author\" content=\"Gaurav Sharma\" \/>\n<meta name=\"twitter:card\" content=\"summary_large_image\" \/>\n<meta name=\"twitter:label1\" content=\"Written by\" \/>\n\t<meta name=\"twitter:data1\" content=\"Gaurav Sharma\" \/>\n\t<meta name=\"twitter:label2\" content=\"Est. reading time\" \/>\n\t<meta name=\"twitter:data2\" content=\"13 minutes\" \/>\n<script type=\"application\/ld+json\" class=\"yoast-schema-graph\">{\"@context\":\"https:\\\/\\\/schema.org\",\"@graph\":[{\"@type\":\"Article\",\"@id\":\"https:\\\/\\\/lng-consultancy.com\\\/code-review\\\/#article\",\"isPartOf\":{\"@id\":\"https:\\\/\\\/lng-consultancy.com\\\/code-review\\\/\"},\"author\":{\"name\":\"Gaurav Sharma\",\"@id\":\"http:\\\/\\\/sh024.global.temp.domains\\\/~landgcon\\\/#\\\/schema\\\/person\\\/3a0c843cc8fdd00620a3e31669989cee\"},\"headline\":\"Code Review\",\"datePublished\":\"2020-03-26T06:38:59+00:00\",\"dateModified\":\"2022-08-02T12:53:35+00:00\",\"mainEntityOfPage\":{\"@id\":\"https:\\\/\\\/lng-consultancy.com\\\/code-review\\\/\"},\"wordCount\":2898,\"commentCount\":2,\"image\":{\"@id\":\"https:\\\/\\\/lng-consultancy.com\\\/code-review\\\/#primaryimage\"},\"thumbnailUrl\":\"https:\\\/\\\/i0.wp.com\\\/lng-consultancy.com\\\/staging\\\/5474\\\/wp-content\\\/uploads\\\/2020\\\/03\\\/Untitled-design-33.jpg?fit=1200%2C628&ssl=1\",\"keywords\":[\"CodeReview\",\"SoftwareDevelopment\"],\"articleSection\":[\"Software Development\"],\"inLanguage\":\"en-US\",\"potentialAction\":[{\"@type\":\"CommentAction\",\"name\":\"Comment\",\"target\":[\"https:\\\/\\\/lng-consultancy.com\\\/code-review\\\/#respond\"]}]},{\"@type\":\"WebPage\",\"@id\":\"https:\\\/\\\/lng-consultancy.com\\\/code-review\\\/\",\"url\":\"https:\\\/\\\/lng-consultancy.com\\\/code-review\\\/\",\"name\":\"Code Review - L&G Consultancy\",\"isPartOf\":{\"@id\":\"http:\\\/\\\/sh024.global.temp.domains\\\/~landgcon\\\/#website\"},\"primaryImageOfPage\":{\"@id\":\"https:\\\/\\\/lng-consultancy.com\\\/code-review\\\/#primaryimage\"},\"image\":{\"@id\":\"https:\\\/\\\/lng-consultancy.com\\\/code-review\\\/#primaryimage\"},\"thumbnailUrl\":\"https:\\\/\\\/i0.wp.com\\\/lng-consultancy.com\\\/staging\\\/5474\\\/wp-content\\\/uploads\\\/2020\\\/03\\\/Untitled-design-33.jpg?fit=1200%2C628&ssl=1\",\"datePublished\":\"2020-03-26T06:38:59+00:00\",\"dateModified\":\"2022-08-02T12:53:35+00:00\",\"author\":{\"@id\":\"http:\\\/\\\/sh024.global.temp.domains\\\/~landgcon\\\/#\\\/schema\\\/person\\\/3a0c843cc8fdd00620a3e31669989cee\"},\"breadcrumb\":{\"@id\":\"https:\\\/\\\/lng-consultancy.com\\\/code-review\\\/#breadcrumb\"},\"inLanguage\":\"en-US\",\"potentialAction\":[{\"@type\":\"ReadAction\",\"target\":[\"https:\\\/\\\/lng-consultancy.com\\\/code-review\\\/\"]}]},{\"@type\":\"ImageObject\",\"inLanguage\":\"en-US\",\"@id\":\"https:\\\/\\\/lng-consultancy.com\\\/code-review\\\/#primaryimage\",\"url\":\"https:\\\/\\\/i0.wp.com\\\/lng-consultancy.com\\\/staging\\\/5474\\\/wp-content\\\/uploads\\\/2020\\\/03\\\/Untitled-design-33.jpg?fit=1200%2C628&ssl=1\",\"contentUrl\":\"https:\\\/\\\/i0.wp.com\\\/lng-consultancy.com\\\/staging\\\/5474\\\/wp-content\\\/uploads\\\/2020\\\/03\\\/Untitled-design-33.jpg?fit=1200%2C628&ssl=1\",\"width\":1200,\"height\":628},{\"@type\":\"BreadcrumbList\",\"@id\":\"https:\\\/\\\/lng-consultancy.com\\\/code-review\\\/#breadcrumb\",\"itemListElement\":[{\"@type\":\"ListItem\",\"position\":1,\"name\":\"Home\",\"item\":\"https:\\\/\\\/lng-consultancy.com\\\/staging\\\/5474\\\/\"},{\"@type\":\"ListItem\",\"position\":2,\"name\":\"Code Review\"}]},{\"@type\":\"WebSite\",\"@id\":\"http:\\\/\\\/sh024.global.temp.domains\\\/~landgcon\\\/#website\",\"url\":\"http:\\\/\\\/sh024.global.temp.domains\\\/~landgcon\\\/\",\"name\":\"L&G Consultancy\",\"description\":\"Your Technology Partner\",\"potentialAction\":[{\"@type\":\"SearchAction\",\"target\":{\"@type\":\"EntryPoint\",\"urlTemplate\":\"http:\\\/\\\/sh024.global.temp.domains\\\/~landgcon\\\/?s={search_term_string}\"},\"query-input\":{\"@type\":\"PropertyValueSpecification\",\"valueRequired\":true,\"valueName\":\"search_term_string\"}}],\"inLanguage\":\"en-US\"},{\"@type\":\"Person\",\"@id\":\"http:\\\/\\\/sh024.global.temp.domains\\\/~landgcon\\\/#\\\/schema\\\/person\\\/3a0c843cc8fdd00620a3e31669989cee\",\"name\":\"Gaurav Sharma\",\"image\":{\"@type\":\"ImageObject\",\"inLanguage\":\"en-US\",\"@id\":\"https:\\\/\\\/secure.gravatar.com\\\/avatar\\\/1dfc08a5282352cec5cd9863b7d6672a5a4891b8fd70c998721f20e944e9e68e?s=96&d=mm&r=g\",\"url\":\"https:\\\/\\\/secure.gravatar.com\\\/avatar\\\/1dfc08a5282352cec5cd9863b7d6672a5a4891b8fd70c998721f20e944e9e68e?s=96&d=mm&r=g\",\"contentUrl\":\"https:\\\/\\\/secure.gravatar.com\\\/avatar\\\/1dfc08a5282352cec5cd9863b7d6672a5a4891b8fd70c998721f20e944e9e68e?s=96&d=mm&r=g\",\"caption\":\"Gaurav Sharma\"},\"url\":\"https:\\\/\\\/lng-consultancy.com\\\/staging\\\/5474\\\/author\\\/gauravsharma497b1b31db\\\/\"}]}<\/script>\n<!-- \/ Yoast SEO plugin. -->","yoast_head_json":{"title":"Code Review - L&G Consultancy","robots":{"index":"index","follow":"follow","max-snippet":"max-snippet:-1","max-image-preview":"max-image-preview:large","max-video-preview":"max-video-preview:-1"},"canonical":"https:\/\/lng-consultancy.com\/code-review\/","og_locale":"en_US","og_type":"article","og_title":"Code Review - L&G Consultancy","og_description":"The activity of systematically examining computer source code with the intent of finding mistakes created or overlooked during the development process, thus improving the overall quality of the software. Processes to do it There\u2019re commonly three processes to do Code Review. Pair Programming (Mostly used in the Extreme Programming) Informal Walk through Formal Inspections We […]","og_url":"https:\/\/lng-consultancy.com\/code-review\/","og_site_name":"L&G Consultancy","article_published_time":"2020-03-26T06:38:59+00:00","article_modified_time":"2022-08-02T12:53:35+00:00","og_image":[{"width":1200,"height":628,"url":"https:\/\/lng-consultancy.com\/wp-content\/uploads\/2020\/03\/Untitled-design-33.jpg","type":"image\/jpeg"}],"author":"Gaurav Sharma","twitter_card":"summary_large_image","twitter_misc":{"Written by":"Gaurav Sharma","Est. reading time":"13 minutes"},"schema":{"@context":"https:\/\/schema.org","@graph":[{"@type":"Article","@id":"https:\/\/lng-consultancy.com\/code-review\/#article","isPartOf":{"@id":"https:\/\/lng-consultancy.com\/code-review\/"},"author":{"name":"Gaurav Sharma","@id":"http:\/\/sh024.global.temp.domains\/~landgcon\/#\/schema\/person\/3a0c843cc8fdd00620a3e31669989cee"},"headline":"Code Review","datePublished":"2020-03-26T06:38:59+00:00","dateModified":"2022-08-02T12:53:35+00:00","mainEntityOfPage":{"@id":"https:\/\/lng-consultancy.com\/code-review\/"},"wordCount":2898,"commentCount":2,"image":{"@id":"https:\/\/lng-consultancy.com\/code-review\/#primaryimage"},"thumbnailUrl":"https:\/\/i0.wp.com\/lng-consultancy.com\/staging\/5474\/wp-content\/uploads\/2020\/03\/Untitled-design-33.jpg?fit=1200%2C628&ssl=1","keywords":["CodeReview","SoftwareDevelopment"],"articleSection":["Software Development"],"inLanguage":"en-US","potentialAction":[{"@type":"CommentAction","name":"Comment","target":["https:\/\/lng-consultancy.com\/code-review\/#respond"]}]},{"@type":"WebPage","@id":"https:\/\/lng-consultancy.com\/code-review\/","url":"https:\/\/lng-consultancy.com\/code-review\/","name":"Code Review - L&G Consultancy","isPartOf":{"@id":"http:\/\/sh024.global.temp.domains\/~landgcon\/#website"},"primaryImageOfPage":{"@id":"https:\/\/lng-consultancy.com\/code-review\/#primaryimage"},"image":{"@id":"https:\/\/lng-consultancy.com\/code-review\/#primaryimage"},"thumbnailUrl":"https:\/\/i0.wp.com\/lng-consultancy.com\/staging\/5474\/wp-content\/uploads\/2020\/03\/Untitled-design-33.jpg?fit=1200%2C628&ssl=1","datePublished":"2020-03-26T06:38:59+00:00","dateModified":"2022-08-02T12:53:35+00:00","author":{"@id":"http:\/\/sh024.global.temp.domains\/~landgcon\/#\/schema\/person\/3a0c843cc8fdd00620a3e31669989cee"},"breadcrumb":{"@id":"https:\/\/lng-consultancy.com\/code-review\/#breadcrumb"},"inLanguage":"en-US","potentialAction":[{"@type":"ReadAction","target":["https:\/\/lng-consultancy.com\/code-review\/"]}]},{"@type":"ImageObject","inLanguage":"en-US","@id":"https:\/\/lng-consultancy.com\/code-review\/#primaryimage","url":"https:\/\/i0.wp.com\/lng-consultancy.com\/staging\/5474\/wp-content\/uploads\/2020\/03\/Untitled-design-33.jpg?fit=1200%2C628&ssl=1","contentUrl":"https:\/\/i0.wp.com\/lng-consultancy.com\/staging\/5474\/wp-content\/uploads\/2020\/03\/Untitled-design-33.jpg?fit=1200%2C628&ssl=1","width":1200,"height":628},{"@type":"BreadcrumbList","@id":"https:\/\/lng-consultancy.com\/code-review\/#breadcrumb","itemListElement":[{"@type":"ListItem","position":1,"name":"Home","item":"https:\/\/lng-consultancy.com\/staging\/5474\/"},{"@type":"ListItem","position":2,"name":"Code Review"}]},{"@type":"WebSite","@id":"http:\/\/sh024.global.temp.domains\/~landgcon\/#website","url":"http:\/\/sh024.global.temp.domains\/~landgcon\/","name":"L&G Consultancy","description":"Your Technology Partner","potentialAction":[{"@type":"SearchAction","target":{"@type":"EntryPoint","urlTemplate":"http:\/\/sh024.global.temp.domains\/~landgcon\/?s={search_term_string}"},"query-input":{"@type":"PropertyValueSpecification","valueRequired":true,"valueName":"search_term_string"}}],"inLanguage":"en-US"},{"@type":"Person","@id":"http:\/\/sh024.global.temp.domains\/~landgcon\/#\/schema\/person\/3a0c843cc8fdd00620a3e31669989cee","name":"Gaurav Sharma","image":{"@type":"ImageObject","inLanguage":"en-US","@id":"https:\/\/secure.gravatar.com\/avatar\/1dfc08a5282352cec5cd9863b7d6672a5a4891b8fd70c998721f20e944e9e68e?s=96&d=mm&r=g","url":"https:\/\/secure.gravatar.com\/avatar\/1dfc08a5282352cec5cd9863b7d6672a5a4891b8fd70c998721f20e944e9e68e?s=96&d=mm&r=g","contentUrl":"https:\/\/secure.gravatar.com\/avatar\/1dfc08a5282352cec5cd9863b7d6672a5a4891b8fd70c998721f20e944e9e68e?s=96&d=mm&r=g","caption":"Gaurav Sharma"},"url":"https:\/\/lng-consultancy.com\/staging\/5474\/author\/gauravsharma497b1b31db\/"}]}},"jetpack_featured_media_url":"https:\/\/i0.wp.com\/lng-consultancy.com\/staging\/5474\/wp-content\/uploads\/2020\/03\/Untitled-design-33.jpg?fit=1200%2C628&ssl=1","jetpack_sharing_enabled":true,"_links":{"self":[{"href":"https:\/\/lng-consultancy.com\/staging\/5474\/wp-json\/wp\/v2\/posts\/2294","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/lng-consultancy.com\/staging\/5474\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/lng-consultancy.com\/staging\/5474\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/lng-consultancy.com\/staging\/5474\/wp-json\/wp\/v2\/users\/20"}],"replies":[{"embeddable":true,"href":"https:\/\/lng-consultancy.com\/staging\/5474\/wp-json\/wp\/v2\/comments?post=2294"}],"version-history":[{"count":1,"href":"https:\/\/lng-consultancy.com\/staging\/5474\/wp-json\/wp\/v2\/posts\/2294\/revisions"}],"predecessor-version":[{"id":7318,"href":"https:\/\/lng-consultancy.com\/staging\/5474\/wp-json\/wp\/v2\/posts\/2294\/revisions\/7318"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/lng-consultancy.com\/staging\/5474\/wp-json\/wp\/v2\/media\/7317"}],"wp:attachment":[{"href":"https:\/\/lng-consultancy.com\/staging\/5474\/wp-json\/wp\/v2\/media?parent=2294"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/lng-consultancy.com\/staging\/5474\/wp-json\/wp\/v2\/categories?post=2294"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/lng-consultancy.com\/staging\/5474\/wp-json\/wp\/v2\/tags?post=2294"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}