搭好测试这个安全网
单元测试是最原始的工程概念之一。单元测试对于互联网应用来说，一般会有一个困难，就是需要大量的“脚手架”，比如为了测试数据库操作，必须要有一段代码 “重置”数据库的状态;为了测试网络打包解包，则需要用一个程序向某个网络端口发数据。而准备这些测试工具代码的时间往往会比较长，需要有足够的耐心去做，但一旦做好了，往往能让开发风险大大降低。
对于单元测试，我认为最少应该覆盖所有正确的路径，以及重点防御的错误路径。覆盖了这些重点关注的地方之后，放手重构代码就很方便了。
单元测试应该是属于代码的一部分，和源代码一起存放。自动构建时也应该进行检查输出结果。提交代码时都会自动运行单元测试，当“版本树”需要合并“分支” 时，单元测试尤为重要，而最重要的是在分支上建立的单元测试。这些测试会大大加强系统的稳定性，因为检验了“合并”功能产生的代码—这些代码是最容易出错的。
自己掌控开发方向
开发工作往往被需求变化“牵着鼻子走”，需求往往会有很多来源：产品策划的想法、老板的意见、用户的反馈、数据统计的结论等。提出的各种需求，往往会对开发团队造成很大压力。这些问题都需要我们对需求做出有效的管理。然而我们应该如何去搜集、记录、过滤、实现这些需求呢?
我们需要很好地搜集记录需求。有的团队会设立两面故事墙，任何方面的需求，都可以减缩成一个故事，写到一张便签纸上，贴到故事墙上，专人处理，而不会石沉大海。
有的公司会试图把这个事情用电子化流程来做，但电子化流程有个显著的缺点，就是为了更多地自动化处理，会加入大量的字段，对于故事这种还未谨慎定义过的东西，要认真填写太多的资料，无疑会给使用者造成额外的负担。
告别救火队员
在产品进入运营期间，最牛的程序员似乎总是在充当救火员，各种各样的突发事件、棘手问题中，我们的“高手”往往疲于奔命，永远都在做一些补救的措施。有经验的人员一直没空做开发，因此大量的代码由那些水平较差的人来完成，反过来埋下了更多的问题。然而，如果不是忙着亡羊补牢，我们的资深程序员就可以把更多的精力放在开发上，这些有经验的程序员所生产的代码，又会进一步降低出故障的概率，这才是走向良性循环的方法。
为了减少运营期间的压力，在系统设计时，就要特别注意关于可维护性的非功能需求。运营事故当中，因为部署错误所导致的占很大一部分，因此降低部署错误需要做到：全代码包发布，每个发布版本要包含所有的可执行文件;所有的服务器上部署的配置文件和数据文件都必须做到完全一致，降低更新文件的复杂度。本机IP地址应该用代码从网卡上直接读取，但应该提供可以配置的选择，预备多个IP的服务器使用;只使用命令行方式来启动不同功能，如选择配置文件路径、输入不同功能进程或服务器的配置;程序支持关闭、重载配置这两个信号。在处理这两个信号时，都不应该让使用者感觉突然“掉线”;开发用于安全关闭程序、重载配置的脚本或功能;开发用户自动重启所部署进程的脚本，以及配置开机自动启动所部署的进程;每个进程都不应该强行锁定某资源，必须要能做到一份安装复制多进程并行运行等。
每天发版
如果你想知道项目每一天的开发进度，你就必须要做到每天发版，测试每天的工作进度，如果要顺利地每天发版，就必须建立一个持续集成的系统。一般来说持续集成系统会有以下的先后步骤：单元测试—自动构建—自动部署—集成测试—自动发布。
单元测试关键是要能坚持覆盖所有新加入的代码;自动构建是由构建脚本、构建服务器、持续集成系统几部分组成。
对于美术、产品或者别的非技术人员，添加的数据往往也需要有自动部署的工具，而且因为通常他们产生的文件比较大，每次的全体打包然后覆盖，可能会非常没效率。虽然事情要做得完美不是很容易，但绝对是物有所值。
版本列车
我们时常只是对技术工作有版本管理的过程，而对于其他环节，常常停留在最原始的状态。我们需要在整个项目开发的每个环节，都进行合理的项目管理。在多个项目的经验积累之后，提出了全过程的项目管理的概念：版本列车。
版本列车的含义是按照项目的工作流程，为每个有产出的环节都定义一个版本“车厢”，然后按照工作流程的先后依赖顺序，形成一个完整的“版本列车”。第一个工作环节负责版本号，然后在这个版本号之下填充版本内容。当工作完成，此版本的工作内容则带着版本号进入下一个“车厢”，依此类推。
这样做的好处是，每个环节的每份产出都可以明确地知道其进度位置，安排在什么时候做。对于需要提前准备市场推广或者别的工作部门，有一个非常明确的长期计划。对于进度管理来说，各个部门也能知道整个项目的当前状态。
论功行赏(绩效评估)
不管是对被评的人，还是对评价别人的来说，绩效评估都非常难做。因为很多工作并非能很准确地列举出一二三来，工作任务也可能有大量临时变更。太过主观会让人觉得草率;非要去依据可量化的数据，又过于死板和片面。但没有一个公司敢不做考核，所以说绩效评估是“明知山有虎，偏向虎山行”。
绩效考核应该重点关注的是做了什么事，而不是做得怎么样。这个让很多按“结果”管理的老板很不接受。绩效考核应该是推动别人去做某件事的工具。对于已经明确的方法或者子目标，通过这种细化的方式去指导下属工作。因为是需要事后算账的，而且是量化的，所以下属会对这个事情很认真，同时那些不好量化的事情，管理者也很难执行绩效考核。所以“去做某些事”，是绩效考核最好的目标。
通过考核结果提供正式的工作方法意见。绩效考核本身有个反馈的过程，这个反馈的过程应该提供给下属针对每个具体事情的建议。这种具体地，单独地，一对一地指导，会提高团队的稳定性，而且也让团队成员获得“受关注”的感觉，这种感觉是形成高效团队的重要工具。
考核不能代替目标，不能阻碍目标，而应该是一个沟通工具。目标达成情况是考核的客观指标，但不应该作为主要绩效考核指标。最简单的绩效考核指标就是收入或者利润率。但这种简单指标除了在动机上提高下属的工作热情外，并没有从方法和经验上帮助团队成员。有效的考核应该是引导下属按照更有经验的方法去实现目标。
想认识全国各地的创业者、创业专家，快来加入“中国创业圈”
|
