β

软件开发之道——程序员的坏习惯

The only Unchanged is Change itself 288 阅读

近两个月兼任移动与桌面客户端的架构工作,与以前喜好单打独斗的程序员们打交道的过程中,发现一些程序员常有的一些不好的习惯

不重视单元测试,对测试有误解

开发工程师倾向于完成功能之后,立即交付测试工程师手动测试或者上层调用者测试,测试有问题再打回来修改bug,如果要求交付之前写单元测试,则认为是在阻碍功能交付的进度,仿佛“任何阻碍我尽快的完成功能开发的行为都是与我有不共戴天之仇”。

表面上写单元测试是多花了时间,实际上等发现bug再打回来重写,这中间产生的沟通成本要大得多,于是出现这样的情况:两个星期把一系列功能完成,而真正稳定可发布则要两个月时间,绝大部分时间耗费在测试,修改bug这种来回的扯皮中。

敏捷开发认为单元测试是成本最小的,一个bug在单元测试阶段发现的成本比起功能测试时才发现要小得多。单元测试虽然是一种白盒测试,但是测试点仍然是对象的接口,白盒主要体现在依赖注入上,单元测试的过程本身就是验证接口设计的过程,甚至在TDD里设计本身就是由测试驱动的。单元测试可以细粒度的检测bug,可以把因素锁定在有限的范围内,并最快的速度迭代,比起功能开发完再测试,成本要小一个量级。我们希望看到的是可以持续的交付,两个星期一个迭代完成功能,同时测试也通过。

合理的对象建模,面向接口的设计,Mock注入,Expect框架等测试自动化框架和工具的使用,可以有效的提高测试的效率。

害怕变化

在多人协作,模块化开发中,上层应用的开发者希望下层模块把接口提前设计的完美,接口定了之后最好不要有任何变化,否则改动的影响可能会非常大。这个要求其实也无可厚非,但是敏捷开发告诉我们,这种思路是太理想化的,接口也需要迭代过程中不断完善,需求和架构都是在迭代过程中逐渐清晰的。我们设计领域和事件模型,采纳MVC框架,模块化和层次结构设计,依赖注入等等,无非是为了一点,变化的时候改动的成本尽可能小。快速的迭代,细粒度的重构也是减小变化成本的必须。

程序员不仅不要害怕变化,而且要带着积极的心态拥抱变化。

缺乏安全感

很多程序员不喜欢讨论内部的设计,而喜欢对外的API接口设计。他们认为如果太过透明,一是侮辱自己的智商,二是影响自己在项目中的不可或缺性,最好把自己的实现功能作为一个黑盒子给别人,只要自己能够最快的把这个黑盒子实现,就是个人能力的体现。这实在是很短视的一种思想,不过考虑到国内软件企业的现状,倒也情有可原,因为最终的考核都是基于工作量和在项目中的不可或缺性。程序员应该有更高的追求,作为一个团队的一员,以科学的方法论指导工作,保证促进团队的整体效率。而作为个人考核的度量则是新的技术解决难题,引进了新的方法提高了效率等,只有不断进步才能体现个人价值。