项目中开发团队切忌使用的七种操做

最近在看《人人都是产品经理》这本书，书中提到了“开发的Secret Toolbox”概念，做为项目管理人员，也是深有同感，在这里作一个简单记录，做为技术开发人员，应该严格杜绝如下七种操做的出现：

一、 Copy&Paste
不假思索的“复用”，知足当前需求就好，不考虑逻辑的可扩展，好比A和B如今1对1，不考虑未来有可能1对N，即便是业务上已经作出提示的时候。

PS： 另外一个重要缘由是：拷贝粘贴是BUG扩散的重要途径，在不少专业的团队内部，是不容许互相之间拷贝代码的，也有这方面的考虑。

二、 Hardcode
写死代码，不用配置文件、变量，当你发现某个参数不妥，想要多改几回试试的时候，发现工做量超乎想象，并且怎么都改不干净。

PS：在实际项目中，全部须要作选择和分支的时候，都尽可能应该使用配置代码，即便已经明确只有固定的几种状况，也应该考虑将来的扩容，不少项目都是有二期甚至多期的，要为本身留后路！不少人会说，写成可配置的代码会比较费时间，有一种简单的办法就是，可配置的内容能够不与配置文件或数据库联动，而是经过静态类、静态变量、常量的方式实现，这也是符合OOP思想的一种实现。

三、Less Testing
听来一个很搞笑的故事，某位技术同窗写完代码作单元测试，第一次没过，百思不得其解，因而再跑一次看看，结果过了，再跑，又过了，因而，就认为第一次是幻觉。

PS：上述这种很难复现的BUG，才是程序中最可怕的BUG，由于开发人员不知道复现步骤，也就意味着不知道问题是什么，若是一个问题连问题自己是什么，就更别提如何解决问题了。因此对于这种“见鬼的问题”，开发、测试、项目管理团队都应该引发足够的重视，以避免项目上线后，由于这种问题而引发不可挽回的损失，试想一下若是在一个资金或帐目相关的功能模块出现这种问题，面对上线后，真实用户千奇百怪的操做方式，谁又能确保这个问题不会在关键路径上出现？！

四、Skip Error Handling
不考虑异常状况，假设用户都是正常使用（固然，在某些状况下，业务方承认的时候确实能够这样作），举个最简单的例子，输入框没有作安全上限的长度控制，用户能够直接把程序搞挂。

PS：除非你作的是专用系统，而且用户都是愿意学习的、接受太高等教育的、具备极深专业背景的人，不然，你仍是在程序中作好边界控制，不要对用户抱有任何幻想，试想一下，若是汽车自动变速箱制造商没有在R档和P档作“防呆”措施的话，你正在高速公路上行驶，却不当心将档位挂进了P档或R档，那你还能看到次日的太阳吗？！（自动挡汽车通常在有必定正向速度的时候，是没法挂进P档和R档的，即便你轻踩着刹车）

五、Descope
偷摸减需求，不举例了，真的会有，验收的时候产品经理负责，发现了还好，但有时候只验收主要场景是发现不了的。

PS：出来混，早晚是要还的，一方面这是程序猿的职业素养，是道德问题，另外一方面，也是项目管理和测试人员没有尽到工做职责的表现。

六、Less Review
减小设计评审、代码Review等，咱们认为强技术能够少评审，但会动用secret toolbox的同窗每每并非很厉害的人物。

PS：在项目管理中，每每是前期工做越扎实，后期越少走弯路，若是团队对设计、评审、分析、代码重构的重视度不够，短时间内，可能看不到什么影响，可是长远来讲，一是不利于我的专业水平提高，二是后期纠正错误成本巨大，每每会伴随着加班、大面积代码重构，甚至会总体推翻重作，最严重的将是项目以失败了结，这可能不会再一期项目中提现出来，但只要项目后续有变更或者调整，不管这个变更是否合理，对于项目团队来讲，都如鲠在喉，痛苦异常。

七、No Autotest
无测试自动化，工欲善其事必先利其器，磨刀不误砍柴工，一直不磨刀，总体效率就一直上不去。

PS：一方面，对于测试人员来讲，刚入行时，须要掌握和锻炼的技能多是对需求的理解能力、测试用例的设计能力，主要看测试用例是否可以尽量多的覆盖程序的全部逻辑节点、分支、路径等，可是当基础概念和能力掌握的差很少时，就须要更加深刻一步，毕竟一我的就算一天24小时不睡觉又能执行几个用例呢？而自动化测试，从功能、性能、安全性等方面能够全面逼近真实环境，要相信现代科学永远都是向着人类愈来愈轻松的方式进化的。另外一方面，不少测试人员是由于不想写代码或者写不了代码才去作测试的，可是要知道，只要作测试这行，你一定是绕不过这关的，除非你永远只想作一颗无足轻重的螺丝钉，而且期盼技术的发展在你退休以前尚未达到能用机器代替你的程度。

     若是对技术缺乏敬畏，就会在不知不觉中背上沉重的技术债务！仍是那句话，出来混早晚是要还的！最终整个项目组（包括技术、测试、产品、设计等部门）都将为这些技术债务埋单！

    原连接：         http://www.softeng.cn/?p=227