当你发现代码中的某些注释完全无用时你会怎么办？
我们经常会犯一个错误：当我们更新代码时，却忘记更新相应的注释。不友好的注释并不会影响代码的执行，但使我们的调试和阅读带来极大困扰，注释描述的是一种逻辑，而代码确是另外一种，结果会浪费我们大量时间来搞懂这段代码的意思，更糟糕的是这样的注释很可能误导我们。
这并不是说注释完全没有必要，优秀的代码有具有相应优秀的注释。我们可以利用某些编程技术来减少我们的注释，使我们的代码更加自解释。这不仅仅使我们的代码更加容易理解，还有助于改善项目的整体设计。
这样的代码通常被称为自解释的代码，下面我将介绍一些编写自解释代码的方法。
more
概览
一些程序猿将注释也作为自解释代码的一部分，注释很
继续阅读 »
SonarQube(Sonar)是一个用于管理代码质量的开源平台。SonarQube目前已支持超过20种主流编程语言，它管理的代码质量主要涉及7个维度:架构与设计、重复、单元测试、复杂度、潜在的bug、代码标准、注释。
本文，笔者将围绕搭建SonarQube这样的代码质量管理平台这个主题展开，结合java代码实例一步步讲述具体的过程，其中涉及Sonar的下载安装、创建对应Mysql数据库以及运行和管理，并对实践过程中出现的一些问题进行了分析和解决。
继续阅读 »
本文翻译自老马(Martin Fowler)的博客文章，该译文现已被博客原文收录在其下方中文翻译处。
在我的职业生涯期间，我曾听过很多关于一个方法(或者说函数，本文针对两者将不做区分)应当有多长的争论。这其实引申到另一个更加重要的问题上：我们应该在什么时候把代码封装在它自己的方法内？有些准则会基于方法的长度，比如方法的长度不应该超出屏幕可以容纳的范围❶。有些会基于复用，即任何被使用超过两次的代码都应该抽出自己单独的方法，而只在一个地方使用过的代码就应当保留在行内。然而，于我而言，最合乎情理的还是这种论点：那就是意图和实现的分离。如果你不得不费点精力查看一段代码，才能弄清楚它具体做了什么，那你就需要把它抽出成一个方法，并且用“它
继续阅读 »
Code Review 是什么？
wikipedia: Code review is systematic examination (sometimes referred to as peer review) of computer source code. It is intended to find mistakes overlooked in software development, improving the overall quality of software.
继续阅读 »