最近在看《人人都是产品经理》这本书，书中提到了“开发的Secret Toolbox”概念，作为项目管理人员，也是深有同感，在这里做一个简单记录，作为技术开发人员，应该严格杜绝以下七种操作的出现：
1、 Copy&Paste
不假思索的“复用”，满足当前需求就好，不考虑逻辑的可扩展，比如A和B现在1对1，不考虑将来有可能1对N，即使是业务上已经做出提示的时候。
PS： 另一个重要原因是：拷贝粘贴是BUG扩散的重要途径，在很多专业的团队内部，是不允许互相之间拷贝代码的，也有这方面的考虑。
2、 Hardcode
写死代码，不用配置文件、变量，当你发现某个参数不妥，想要多改几次试试的时候，发现工作量超乎想象，而且怎么都改不干净。
PS：在实际项目中，所有需要做选择和分支的时候，都尽量应该使用配置代码，即使已经明确只有固定的几种情况，也应该考虑未来的扩容，很多项目都是有二期甚至多期的，要为自己留后路！很多人会说，写成可配置的代码会比较费时间，有一种简单的办法就是，可配置的内容可以不与配置文件或数据库联动，而是通过静态类、静态变量、常量的方式实现，这也是符合OOP思想的一种实现。
3、Less Testing
听来一个很搞笑的故事，某位技术同学写完代码做单元测试，第一次没过，百思不得其解，于是再跑一次看看，结果过了，再跑，又过了，于是，就认为第一次是幻觉。
PS：上述这种很难复现的BUG，才是程序中最可怕的BUG，因为开发人员不知道复现步骤，也就意味着不知道问题是什么，如果一个问题连问题本身是什么，就更别提如何解决问题了。所以对于这种“见鬼的问题”，开发、测试、项目管理团队都应该引起足够的重视，以免项目上线后，因为这种问题而引起不可挽回的损失，试想一下如果在一个资金或账目相关的功能模块出现这种问题，面对上线后，真实用户千奇百怪的操作方式，谁又能确保这个问题不会在关键路径上出现？！
4、Skip Error Handling
不考虑异常情况，假设用户都是正常使用（当然，在某些情况下，业务方认可的时候确实可以这样做），举个最简单的例子，输入框没有做安全上限的长度控制，用户可以直接把程序搞挂。
PS：除非你做的是专用系统，并且用户都是愿意学习的、接受过高等教育的、具有极深专业背景的人，否则，你还是在程序中做好边界控制，不要对用户抱有任何幻想，试想一下，如果汽车自动变速箱制造商没有在R档和P档做“防呆”措施的话，你正在高速公路上行驶，却不小心将档位挂进了P档或R档，那你还能看到第二天的太阳吗？！（自动挡汽车一般在有一定正向速度的时候，是无法挂进P档和R档的，即使你轻踩着刹车）
5、Descope
偷摸减需求，不举例了，真的会有，验收的时候产品经理负责，发现了还好，但有时候只验收主要场景是发现不了的。
PS：出来混，迟早是要还的，一方面这是程序猿的职业素养，是道德问题，另一方面，也是项目管理和测试人员没有尽到工作职责的表现。
6、Less Review
减少设计评审、代码Review等，我们认为强技术可以少评审，但会动用secret toolbox的同学往往并不是很厉害的人物。
PS：在项目管理中，往往是前期工作越扎实，后期越少走弯路，如果团队对设计、评审、分析、代码重构的重视度不够，短期内，可能看不到什么影响，但是长远来说，一是不利于个人专业水平提升，二是后期纠正错误成本巨大，往往会伴随着加班、大面积代码重构，甚至会整体推翻重做，最严重的将是项目以失败告终，这可能不会再一期项目中提现出来，但只要项目后续有变动或者调整，无论这个变动是否合理，对于项目团队来说，都如鲠在喉，痛苦异常。
7、No Autotest
无测试自动化，工欲善其事必先利其器，磨刀不误砍柴工，一直不磨刀，整体效率就一直上不去。
PS：一方面，对于测试人员来说，刚入行时，需要掌握和锻炼的技能可能是对需求的理解能力、测试用例的设计能力，主要看测试用例是否能够尽可能多的覆盖程序的所有逻辑节点、分支、路径等，但是当基础概念和能力掌握的差不多时，就需要更加深入一步，毕竟一个人就算一天24小时不睡觉又能执行几个用例呢？而自动化测试，从功能、性能、安全性等方面可以全面逼近真实环境，要相信现代科学永远都是向着人类越来越轻松的方式进化的。另一方面，很多测试人员是因为不想写代码或者写不了代码才去做测试的，但是要知道，只要做测试这行，你必定是绕不过这关的，除非你永远只想做一颗无足轻重的螺丝钉，并且期盼技术的发展在你退休之前还没有达到能用机器代替你的程度。
如果对技术缺少敬畏，就会在不知不觉中背上沉重的技术债务！还是那句话，出来混迟早是要还的！最终整个项目组（包括技术、测试、产品、设计等部门）都将为这些技术债务埋单！