重复代码处理模式

最近在整改某项目几十个模块(子项目)的重复代码,整理的一些思路。 其实方法在重构一书早就说过了,我个人认为要多思考方法。类的职责, 用对象间进行协助的思路,来解决重复代码的问题。 对于快速找到某段重复代码的处理模式,这就是关键的地方。

模块之间的重复代码

  • 文件重复,但模块间通用,可推到基础模块,风险小,常见于基础工具类
  • 文件重复,但与具体模块相关,说明依赖其他模块,不适合直接推到基础模块,调整较大,建议延后处理

模块内文件间的重复代码

强相关

  • 直接删除一个,推上上层包结构,作为公共代码
  • 差异为通用扩展时, 合并成一个
  • 差异为特殊扩展时,采用继承方式,虽然不够彻底,但风险小

普通关联

  • 以业务为准,公用包结构
  • 重复部分推到父类,由两边继承
  • 采用协助类,常见于较大粒度的对象协助

弱相关

  • 重复代码进入工具类,适用于通用的场景
  • 采用协助类,参与于较小粒度的对象协助

文件内方法间的重复代码

  • 抽取私有方法作为优先考虑的方法,风险小,可操作性强,需要注意方法命名
  • 抽取协作类,常见于私有方法过多、局部关联性强、复杂度过高等情况
  • 由已经存在的类实现,常见于职责过大的情况
  • 如果适用于通用逻辑,可以推到父类或工具类

小技巧

  • 先抽取小方法,看清结构
  • 有时候用循环代替排山倒海式代码
  • 先简化再深化,分步骤处理
  • 识别真正不一样的地方

对RESTFul多了点理解

简报与REST

上个月春节刚刚回来,就要交技术简报文章了。实在有点不知道写什么好,还好春节回去有准备些东西,不然就要悲剧了。 这次的主题选择的是REST。REST在国内外倒是很火热的主题了,不过在咱们公司里边很多人还是没接触过,完全没概念。 我觉得,这也的确是个不错的主题。

主要内容

RESTFul vs CURD

文章本身没什么特别,主要围绕资源来展开的,主要是给大家对REST,RESTFul等有点概念。 主要有这些部分:

  1. 资源的名称与URI的关系,资源的概念很重要
  2. 获取资源的方式,主要是HTTP标准方法
  3. 资源的表述,如何表达资源的外在形式
  4. 资源的连通性,超媒体的概念一旦忽略就几乎等同于CRUD了
  5. 状态转移,区分应用状态和资源状态

总体来看,在写这个文章的时候,对RESTFul多了点理解,主要是以前一些忽略的地方得到了加强。 整篇文章大概花了10页,主要以github API和ruby on rails作为例子。 个人认为,Github API设计得是相当有参考意义的。值得参与RESTFul API设计的同行参考。

推荐的书籍材料

除了Github API,下面的一些材料也是我很喜欢的。特别是RESTful Web Services这本书, 里边的理论比较具有可操作性,并提出了面向资源的架构(ROA),作为REST的实践方式,不妨学习一下。

git分支让github page用上jekyll插件

git分支让github page用上jekyll插件

本博客已经在2013-3-9转换成octopress了,比这种手动方式要方便很多。

github page是个不错的应用,可惜对jekyll有比较多的限制,特别是插件方面。 为了解决这个问题,我选择了分支来处理这个,大约就是source分支保存未编译的内容, master分支保留生成的网站。下面是大概的操作过程,针对已有博客的迁移。

迁移过程

首先,到github上手动打一个分支出来,叫source分支。

接着,处理master分支,清除所有内容。注意git pull的功能是让本地可以识别到远程分支。 .nojekyll文件是让github page不启用jekyll生成网站,而是直接使用目录下的内容。 并把所有带下划线的目录都过滤掉。

cd mccxj.github.com
git rm -fr *

touch .nojekyll
git add .nojekyll

# add _*/* to .gitignore
vi .gitignore

git commit -a -m "remote all pages"

下面,继续处理source分支,其实基本保持不变就可以了,主要是生成网站内容。 带t的参数是让source跟踪远程source分支。我的jekyll是采用最新源码装的,命令参数有些变化, 请参考jekyll帮助,

git checkout -t origin/source

$ git branch -a
master
* source
remotes/origin/HEAD -> origin/master
remotes/origin/master
remotes/origin/source

# generate page to _site
jekyll build

最后,切回master分支,并拷贝网站内容到根目录,然后把内容提交并push到远程即可。

git checkout master

cp -r _site/* .

# add then commit
git add / git commit

# push to remote branch
git push origin master

新写作流程

现在已经迁移完成了,下面介绍一些新写作流程。

首先,注意要在source分支上工作,在提交到远程之前都是一样。

git checkout source

# rake post title="xxxx"
# write something
git add xxxx.md
git commit -m "add new post"

# jekyll build
jekyll serve

当你确认完成,并生成网站内容后,切换到master分支处理。 注意需要提交两个分支,例如使用git push可以同时提交两个分支。

git checkout master

cp -r _site/* .

# add then commit
git add / git commit

# push to remote branch
git push

还不算麻烦吧,其实我是尝试切换到octopress,发现有不少地方出现问题,才采用这种方式的。Enjoy It!

jekyll插件:支持URL跳转

jekyll插件:支持URL跳转

github page不支持.htaccess功能(参考Blogging on Jekyll: URL Redirects), 所以发生URL调整的时候,无法让原有路径自动跳转到新路径。 Alias generator这个插件提供了一个解决方案,就是生成多一个页面,采用auto refresh的方式跳转到新路径。

这次我也调整了一些博客的路径,我也采用了这个方式。不过我只对当前已有的页面生成一次,以后的就不用这个插件了。 另外,我不想去修改每个页面的alias标签,所以我调整了代码,只对我的url规则进行处理。下面是我使用的版本。