这篇blog几乎跟什么深奥的技术没有关系,甚至可能略显小儿科。

核心是,程序员不应该浪费时间在重复的劳动上,除非这重复工作确实不可避免,并且意义足够重大,比如说拯救地球-,-。而最近的工作中,发现几个违反了懒惰规则的地方,写了几个小工具,记录一下。

  1. phpunit的testSuite.php入口文件
  2. api使用的参数检查checker类
  3. 新修改代码的批量语法检查
  4. 脚本替换

phpunit的testSuite.php入口文件

在一个项目里,发现phpunit的入口文件testSuite.php中,定义了一个继承自PHPUnit_Framework_TestSuite的类,该类的构造函数中,hard code了一些测试用例的声明。每次有新测试用例,都会把之前旧用例注释掉。

//require_once ‘libs/ATest.php';
//$this->addTestSuite(‘ATest’);

require_once ‘libs/BTest.php';
$this->addTestSuite(‘BTest’);

由于是多人开发,还会出现冲突。其实只要一个小小的改动:

      public function __construct() {
          $this->setName('TestsSuite');

          global $argv;
          if (($cnt=count($argv)) > 2){
              for($idx=2; $idxaddTestFile($argv[$idx]);
              }
          }
      }

使用的时候,传入用例的文件名称即可(还可以利用linux的文件名自动补完):

phpunit TestsSuite.php ‘cases/ATest.php’

api使用的参数检查checker类

严格意义上来说,每个方法都不应该信任调用者传来的参数,而进行严格的参数检查。但这真是个体力活!导致的结果,要不然就重复的编码,要不然就是直接省略,把参数检查的责任交给下一级方法或者引入安全问题。其实可以抽象一下。

写了个简单的checker类,调用者配置待检查的参数是否必须存在,若存在使用什么检查handler(比如_check_string检查是多长的字符串,_check_unsignedint检查必须是正整数等),如果不符合要求,返回什么错误码和错误提示。

于是,参数检查不但变得简单,而且该配置本身还起到了代码注释的作用!

新修改代码的批量语法检查

打字快了的时候,难免没有手误,在测试和提交前,可以利用php -l来检查文件里是否有语法错误。但是每次都手工执行,多麻烦啊!写了一个脚本,通过svn st命令获取到新修改文件的名称,再检查所有以”.php”结尾的文件(如果有其他后缀的php文件,也可以添加)。

#!/bin/bash

### 检查新修改的php文件,是否有语法错误(svn st)

svnmodified=$(svn st)

# 错误个数
errnum=0

for line in $svnmodified;do
        pos=${#line}-4
        tail=${line:$pos}

        if [ "$tail" == ".php" ];then
                php -l $line

                if [ $? -ne 0 ];then
                        ((errnum=errnum+1))
                fi
        fi
done

echo -e "\n\n####### Total errors: $errnum ######\n\n" >&2

我们还可以进一步,把它和svn想绑定,每次svn ci的时候,都自动执行一遍。

脚本替换

有时项目里,会有大量文件的内容替换工作,比如这次,我需要将某一类老的方法调用替换到新方法上去,共计500多处,如果手工修改,估计就直接放弃了。

通过分析新老调用的区别,其实用sed命令,可以很容易实现,最后,用了一行代码:

sed -i’.bak’ “s/OldLog::Log\s*(\s*\([^,]\{1,\},\)\{2\}/NewLog::notice(/g” `grep  “OldLog::Log” -rwl * | grep -v svn | grep -v tags`

完成之后,svn diff检查结果,再略微手工调整,工作量大大减少。

结语

程序员的工作,可以很快乐,但乐子是自己找的。

Leave a Reply