Big Bug Ban

长久以来，编写php程序最大的一个问题就是php太灵活了。

没有类约束，可以随意引用脚本文件，允许全局变量等等。

直接的结果就是对于相同的功能每个人都可以有一套自己的实现方法。

对语言本身来说或许不是什么大事，但是对于一个项目来说就比较致命了。

编程就像写小说，每个人都会忠于自己的情节，当项目逐渐庞大，各种代码杂乱一通，后续的重构已经不能解决问题的时候，项目本身的维护成本将越来越高。

如何降低一个项目的维护成本呢，一般说来有两种方式解决这个问题。

其一是通过软件工程中的方法，以管理学的思维控制项目质量，比如codereview，svn,利用外部控制软件质量。

其二是通过对现有软件进行改进，包括语法，业务逻辑，效率优化，比如从以前的cgi到php，提升了开发效率，自然也可降低维护的成本。

框架的存在从某种意义上说也有两个目的，其一是封装，把常用的业务或者底层函数封装成函数或者类方便其他人使用，其二是限制，降低不同开发人员的自主性，必须以框架规定的方式构建程序，这样既可以简化开发，也可以提升软件质量。

4月26号上午

4月26号下午

长了很多啊!

然后是昨天的

自己做的小插件.用于wordpress中插入音频或者视频

已经和wp自带的那个添加媒体进行了高度融合

当你点插入文章的时候，如果是音频或者视频会自动用html5标签进行标记

效果如下

http://haku.hk/2012/05/14/%E6%BA%80%E5%A4%A9.html

下载地址

[download id=”41″]

満天
Kalafina
作詞　：　梶浦由記
作曲　：　梶浦由記

Fate/Zero ED3 满天

静かに瞬く  〖星辰沉默地闪烁〗
星たちの散り逝く空  〖一颗颗消逝于夜空〗
届かぬ祈りが  〖无法传达的祈愿〗
天と地を満たしてた  〖充满了天地的角落〗

細い枝に光るのは  〖忘记绽开的未来〗
咲き忘れた未来  〖在嫩枝上闪耀着光彩〗
また名残惜しそうに蕾を落とした 〖依依不舍地 让蓓蕾掉落下来〗

ほら、もう時は満ちて 実る黄金の果実 〖看呐 时臣已至 满树是金黄的果实〗
その手で摘み取るだけで 世界は終わるから  〖只需伸手攀摘 世界变会终止〗

戯れぬものとして降る雪の白さは 〖频繁的白雪 有着纯洁无垢的身姿〗
温もりを知れば消えてしまうの  〖一旦知道温暖为何物 便会消遁于凡世〗
奇麗な夢だけが貴方を切り裂いた 〖只有那美丽的梦境 才会将你撕碎〗
冷たい瞳の優しさと真実  〖它便是那冰冻瞳眸中的温柔与真实〗

激しく瞬く星たちは天に背いて  〖万千星辰 竞相闪耀 陨落凡尘〗
仇なす祈りが 〖直至那终成灾祸的祈愿〗
この空を墜とすまで  〖让这片天空坠入大地〗

私を弔う為の 〖我不需要〗
花束はいらない 〖为我吊唁的花束〗
心が潰えぬうちに願いを叶えて 〖只要在我的心脏破碎之前 这愿望可以实现〗

見届けてみたい 人の望みが 燦々と光に満ちる時を 〖那些希望相见的人们的夙愿 用璀璨的光把时空填满〗

翼を欲しがって誰もが泣いていた 〖人们都在哭泣 因这想要而得不到的翅膀〗
命が奏でる 満天のコーラス  〖那是命运奏响的 满天的合唱〗

焼け焦げた願いが 空を抉じ開ける頃に  〖当被烧焦了的愿望将天空撕裂之时〗
懐かしい故郷は きっと花の盛りでしょう  〖在令人怀念的故乡 一定会有鲜花盛开吧〗

激しく瞬く星たちの夢の跡 〖激烈闪烁着的星之光芒 是梦的轨迹〗

安らぎのあると人の言う  〖如果所谓的和平〗
最果てまで  〖真的可以延续到最后〗
月影優しく 〖那就让温柔的月影〗
行く路を教ぇてよ  〖为我指明前进的道路〗

静かに瞬く星たちの  〖在静静的闪烁着星光的〗
祈りの空  〖夜空下祈祷〗
貴方の叫びで  〖愿你的呼喊〗
この夢が終わるまで  〖可以延续到这梦幻的尽头〗

只放个可执行的包出来.

规则什么的暂时还没整理好文档.

可以参考下shema里面的.基本就这样了呵呵.

用里面的run.bat或者run.sh运行.

会自动寻找jdk目录

如果没有找到请自己手动运行

%JAVA_PATH%/bin/java -jar target/railgun-0.1.jar

[screen shoot]

[download id=”40″]

ps : 谢谢沈大侠给的好东西.之后借鉴下web harvest的界面. ^_^

redis官方说法是不支持win版。

然后有两个patch均不作为它的主干加入。

其实redis原版是可以在win下面编译安装的。

要编译它，我们需要cygwin和mingw。

cygwin这是一个强大的东东，可以在你的电脑上用win的方式模拟出linux的环境

mingw也是一个强大的东东，可以支持跨平台gnu式的c编译

首先去官网吧cygwin下载回来

http://cygwin.com/setup.exe

打开它，前进下一步。选择好你的root目录。整个cygwin的工作目录将被安装在这里。

这里也将作为linux的根目录存在

然后有个local package 目录，从网上下载回来的包会暂时放在这里，随便选

然后是让选择下载站点。国内建议使用http://mirrors.163.com/cygwin/

下面输入后点add就加入好了

然后再下一步选择要安装的包。要编译redis，我们需要gcc,gcc-core,gcc-g++

然后再去下载mingw

http://sourceforge.net/projects/mingw/files/

然后把所有都装上就好，它会自动往cygwin写配置

然后在打开cygwin的环境下，在redis目录下执行make

然后你会得到一个错误error: `SA_ONSTACK’ undeclared

打开src/redis.c 前面加上一句#define SA_ONSTACK 0

再make

然后就可以在src里面找到make好的文件咯

如果需要在其他地方也运行的话把cygwin的bin目录下的cygwin1.dll一起拷贝走

提供一份已经编译好的redis-2.4.10下载

[download id=”39″]

建议使用里面的bat来运行哈~

一.  什么是重构?

重构（Refactoring）就是在不改变代码外在行为的前提下，通过调整程序代码改善软件的质量、性能，使其程序的设计模式和架构更趋合理，提高软件的扩展性和维护性。

也许有人会问，为什么不在项目开始时多花些时间把设计做好，而要以后花时间来重构呢？要知道一个完美得可以预见未来任何变化的设计， 或一个灵活得可以容纳任何扩展的设计是不存在的。更多情况下我们需要特定的代码去做特性的事情

二. 什么时候重构?

完成某部份功能后，新增或修改某功能前。

一定要写好对应的测试

一定要了解程序代码。

一定要把重构时间加入时程里。

三. 怎么重构？

1.从现有版本分支。

2.决定要实做的方向。

3.小步前进。

4.测试。

5.完成一次小重构后，提交至版本控制系统。

6.继续步骤2 ~ 5 。

7.整个功能完成后，合并回主干。

四. 重构ing

1．  重复代码

这个可能算重构中遇到比较多的问题，代码冗余太多，很多地方都是ctrl+c，ctrl+v搞过去的，以至于越到后面，改个东西就越复杂，比如很典型的逻辑处理。

处理方式：提取重复部分成函数。

2．  过长函数

比如一个拥有1000行的函数。这样的函数和过程化处理无异，而且你很难保证这么长的函数里面不会出现什么错误。而且当你想只用这个函数中的其中一部分的时候将会变得很麻烦，所以你有可能会直接使用复制粘贴，于是，情形一中说的情况就出现了。

处理方式：函数细化，最好能将函数分离

3．  过大的类

我们的项目里面好像还用不到，原因是类都没怎么看见。这种情况一般可能容易出现在一些GUI应用里面，因为这类应用跨类调用很麻烦，而且有很多是在类里面封装的。于是为了省事，方便，这个类的成员函数就不断增多，类也就不断庞大起来。

处理方式：将每个层的职责进行分离，弱化类，细化类关联。

4．  过长的参数列

一般说来，函数的参数最好不要太长，如果确实需要传递那么多的参数。可以使用参数数组，或者参数类。如果是构造方法，可以使用构造器设计模式。让别的类去负责使用类的组装。

5．  发散式修改

这个的意思是如果某个类经常需要在不同的情况下做变动。你的类很有可能还没有考虑到即将到来的变化，所以你不得不做扩展性的修改。

比如一个叫鸭子的类，你只设计了游泳，鸣叫，飞。然后某天出现一个鸭鸣器（可以模仿鸭子的叫声的鸭子型玩具），你这个类就蛋疼了。

处理方式：可以预先想好有可能出现的情况。做好预设

6．  霰弹式变化

这个的意思是我们要改一个小功能，缺不得不改掉很多依赖的地方。比如本来我们设计的数据库只能兼容mysql。现在突然变成mssql了。要怎么去改？你懂的！

这个比较明显的体现可以在我们写的sql语句上。如果我们在数据库修改了一个字段。而且这个字段又是必须的。我们可能不得不去修改掉每一个sql语句。这样造成的后果是如果你一不小心漏掉了某个地方，你可能不会察觉出来。但是后果是这句话有可能就无法成功执行了。

处理方式：对于数据库操作这样的。类似的处理方式是使用模型层，数据模型就是这样诞生的，只负责数据对象的处理，而不用关心具体底层语句。如之前提到的新加字段，可以直接通过复写类成员的方式就可以达到目的了。

7．  If和switch

对于oop来说是应该少用switch。但是对于php而言，个人觉得应该是善于使用switch。If过长的把代码拉开反而降低阅读。

一些比如If else if else if else if 反而不太好

当然，如果条件内的语句过长，分离出个函数出来也是非常不错的选择

8．  注释问题

注释，这里我包含无注释和过度注释两类，其实大多数的情况下，是无注释造成的危害更大。别总是想着让别人通过函数名，参数名就能了解这个函数，参数是做什么的就很好了。必要的注释一定不能少。名字并不能完全传达出你的函数做了什么事情，需要什么参数，返回结果是什么，逻辑上有什么需要注意的地方。如果你写的程序不能让另一个程序员在30秒之内看懂，那么你的代码很应该好好修改下了。

过度注释的一个说法是指将代码中的注释降低到最小，在你想写注释前先通过方法重名，字段提取等方式重构。个人不推荐这种方式。只是有的没有必要注释的地方就没必要写。比如，ifxxx什么之类显而易见的东西就可以省略了，当然，注释多页无妨。个人见解。

9．  业务逻辑相关

这个的重构前提是需要你对代码足够熟悉，别重构出bug哟！

五. after重构

1． 自我测试

测试代码的完整度，有没有重构出bug出来。有没有破坏原有功能

2． 让别人知道你重构了什么东西

3． 见好就收

别把重构最后弄成了重写。

六. 重构工具

非常遗憾，php的自动重构工具都不是特别理想，zend，netbeans改改函数名,变量名还是可以，但是不要太相信这些工具。

有一个rephactor官方网址：http://rephactor.sourceforge.net/ ，但是他只支持php5.2

这个东西的目的是通过撰写xml

然后自动进行目标的数据采集

后续要加入对采集后的数据进行处理和维护

以及可以定义自己的过滤器.对中间或结果数据进行操作变更

用来做毕业设计的其中一部分。

<?xml version="1.0" encoding="UTF-8"?>
<shell>
    <name>3haku.net</name>
    <description>rules for wordpress blog 3haku.net</description>
    <baseurl>*</baseurl>
    <fetch>
        <url>http://3haku.net/</url>
        <cookie>enable</cookie>
        <charset>auto</charset>
        <params>
            <param>
                <key>User-Agent</key>
                <value>RailGun</value>
            </param>
            <param>
                <key>Accept</key>
                <value>gzip</value>
            </param>
        </params>
        <timeout>10000</timeout>
    </fetch>
    <parse method="dom" rule="#content div" filter="net.techest.testFilter">
        <parse method="dom" fork="true" rule=".main">
            <store ext=".html">cache/html/</store>
        </parse>
        <parse method="regxp" fork="true" rule="&lt;img[\s\S]*?src=&quot;([\s\S]*?)&quot;">
            <parse method="regxp" rule="src=&quot;(.*)\/(.*?)[&quot;$]">
                <fetch>
                    <url>$1/$2</url>
                </fetch>
                <store>cache/img/$2</store>
            </parse>
        </parse>
    </parse>
</shell>

fetch后的rescoure可以进行dom解析或者正则解析，然后将得到的数据再进行操作

这个rule是抓取我的博客用的.

效果如下

[download id=”38″]

ps: 用xml还是比较蛋疼..” ‘ 这类的都要用html转义符

最近的时间里感谢大家。

我还是决定踏实走好每一步。

thanks to all of you~