Vagrant使用总结

最开始想要使用Vagrant时,是想要方便地管理和共享开发环境配置,还有一定化的自动化需求。研究了官网,感觉配置还是比较多的,后来就找到puppet,然后又找到一个puphpet(用php开发的一个puppet配置生成工具),就用上了。后来发现,这么使用虽然上手较快,但对Vagrant的配置体系反而似懂非懂,而puppet本身的配置也挺繁琐。

磕磕绊绊倒也是能用,共享开发环境的时候,直接生成一个“笨重的”box,然后发给别人。

provision脚本可以用来初始化环境,而且支持shell、ansible、puppet…,但是本身环境的搭建并不复杂,就没用。所有系统软件都是手动安装的,导致后面只能通过box来进行共享,而不是更优雅的脚本。好在需要共享的人和场景都不多,但每一次都还是很痛的。

最终还是保留使用puppet,相比其它的plugin更灵活、社区也更强一些。

总结一下:

  1. 使用provision初始化环境,需要使用shell或者其它plugin,我使用shell;
  2. 最好别一开始使用工具生成vagrant配置文件,本身并不复杂,否则后面遇到各种蛋疼的问题,搞不清楚到底是生成工具的问题还是配置的问题;
  3. 即便使用了provision脚本,但是如果os升级或者某个软件升级,还是得在shell里操作或者在脚本操作,后续也不得不又通过box共享(或者重新下载新的os镜像+provision);
  4. 一旦维护了脚本,就需要测试。一旦出现了两套东西需要维护,就存在debug由差别(甚至非常细微的差别)造成的各种很猥琐的问题

代码中常见的命名问题

发现在代码命名中有一些常见的错误。我发现大多数是中国人犯这种错误,老外也有。

1. 设计模式后缀

比如 XXXFactory, XXXFacade, XXXObserver 等等,其实完全没有必要增加这种后缀。

2. 拼音命名法

这个我完全是带着个人偏见,相比英文,中文的表达能力更强,也就导致,名字的“意境”更多,更容易误解。倒不是因为使用拼音。

3. 词性错误

类大多数是名词,但如果是command模式,那类名可能会是动词,取决于类的本质行为。方法/函数通常是动词或者动宾短语。

4. 冗余

没有充分使用语言特性,如namespace、package等。比如 AlipayTradeService, AlipayWapTradeService…这种。好不环保哦。

基本上每当出现“重复”时,意味着代码需要重构或者精简了。

5. 直译法

比如,微信的“统一下单”,代码中是 ” unified ” – 统一, “order” – 下单。让我来推测一下这种名字的由来:

最开始,在线上支付和pos系统里有“收单”一说,英文用“acquire”,后来可能pos和线上合并了,也就是“统一”。其实似乎没有增加“统一”的必要。

本质上其实还是收单。