软件开发之道——程序员的坏习惯
近两个月兼任移动与桌面客户端的架构工作，与以前喜好单打独斗的程序员们打交道的过程中，发现一些程序员常有的一些不好的习惯
不重视单元测试，对测试有误解
开发工程师倾向于完成功能之后，立即交付测试工程师手动测试或者上层调用者测试，测试有问题再打回来修改bug，如果要求交付之前写单元测试，则认为是在阻碍功能交付的进度，仿佛“任何阻碍我尽快的完成功能开发的行为都是与我有不共戴天之仇”。
表面上写单元测试是多花了时间，实际上等发现bug再打回来重写，这中间产生的沟通成本要大得多，于是出现这样的情况：两个星期把一系列功能完成，而真正稳定可发布则要两个月时间，绝大部分时间耗费在测试，修改bug这种来回的扯皮中。
敏捷开发认为单元测试是成本最小的，一个bug在单元测试阶段发现的成本比起功能测试时才发现要小得多。单元测试虽然是一种白盒测试，但是测试点仍然是对象的接口，白盒主要体现在依赖注入上，单元测试的过程本身就是验证接口设计的过程，甚至在TDD里设计本身就是由测试驱动的。单元测试可以细粒度的检测bug，可以把因素锁定在有限的范围内，并最快的速度迭代，比起功能开发完再测试，成本要小一个量级。我们希望看到的是可以持续的交付，两个星期一个迭代完成功能，同时测试也通过。
合理的对象建模，面向接口的设计，Mock注入，Expect框架等测试自动化框架和工具的使用，可以有效的提高测试的效率。
害怕变化
在多人协作，模块化开发中，上层应用的开发者希望下层模块把接口提前设计的完美，接口定了之后最好不要有任何变化，否则改动的影响可能会非常大。这个要求其实也无可厚非，但是敏捷开发告诉我们，这种思路是太理想化的，接口也需要迭代过程中不断完善，需求和架构都是在迭代过程中逐渐清晰的。我们设计领域和事件模型，采纳MVC框架，模块化和层次结构设计，依赖注入等等，无非是为了一点，变化的时候改动的成本尽可能小。快速的迭代，细粒度的重构也是减小变化成本的必须。
程序员不仅不要害怕变化，而且要带着积极的心态拥抱变化。
缺乏安全感
很多程序员不喜欢讨论内部的设计，而喜欢对外的API接口设计。他们认为如果太过透明，一是侮辱自己的智商，二是影响自己在项目中的不可或缺性，最好把自己的实现功能作为一个黑盒子给别人，只要自己能够最快的把这个黑盒子实现，就是个人能力的体现。这实在是很短视的一种思想，不过考虑到国内软件企业的现状，倒也情有可原，因为最终的考核都是基于工作量和在项目中的不可或缺性。程序员应该有更高的追求，作为一个团队的一员，以科学的方法论指导工作，保证促进团队的整体效率。而作为个人考核的度量则是新的技术解决难题，引进了新的方法提高了效率等，只有不断进步才能体现个人价值。