<?xml version="1.0" encoding="utf-8" standalone="yes"?><rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom"><channel><title>Internal Quality on Kaan's Blog</title><link>https://kaanbardak.com/tags/internal-quality/</link><description>Recent content in Internal Quality on Kaan's Blog</description><generator>Hugo -- gohugo.io</generator><language>en</language><lastBuildDate>Wed, 17 Feb 2016 03:31:06 +0000</lastBuildDate><atom:link href="https://kaanbardak.com/tags/internal-quality/rss.xml" rel="self" type="application/rss+xml"/><item><title>Effective Code Review</title><link>https://kaanbardak.com/posts/effective-code-review/</link><pubDate>Wed, 17 Feb 2016 03:31:06 +0000</pubDate><guid>https://kaanbardak.com/posts/effective-code-review/</guid><description>&lt;p&gt;&lt;img src="https://kaanbardak.com/posts/effective-code-review/wtf-per-second.jpg" alt="wtf/sec"&gt;&lt;/p&gt;
&lt;p&gt;As we all know, code review is maybe the oldest technique to stepping into the software quality assurance realm. Because of the variety of the technologies, project and team sizes, there is no code-review standard. Nevertheless, I would like to share my version I did practice.&lt;/p&gt;
&lt;p&gt;Disclaimer: This practices make more sense for the projects which use same code-bases over years (product lines) with high maintainability targeted.&lt;/p&gt;
&lt;h1 id="peer-review"&gt;Peer Review&lt;/h1&gt;
&lt;p&gt;Everybody is familiar with the peer review. Once a developer feels that his/her job is done and ready for check-in; he/she&lt;/p&gt;</description></item></channel></rss>