时间：2021-07-01 10:21:17 帮助过：18人阅读
将20个关键点邮件发给别人，列出所有的bug、功能需求和别人被拒绝的要求，是和商品一样的问题。通常他们会带来指责或者类似“为什么你不解决掉$XY这个问题？我五个周之前不是就提指出了吗？”这样的追问。一旦你的开发经理不把这些对话落实到切实可行的计划，你就可能忘记事情。与其抱怨所有的这些事情你妈妈都没有教过你，不如尝试教给你的客户或者经理如何使用Bug追踪器或者项目管理工具*。那样的话，你不仅将节省无数发送冗长的邮件的时间，接收邮件的人也会更加清楚你最近正在忙于什么工作。
把问题抄送给所有人，意味着: 关于谁能处理这个问题，你没有任何想法。这种做法本身就有问题。如果你这样做了，很可能没有人会回答或者觉得应该对该问题负责。还有:阅读这些邮件浪费了无关人员大量的宝贵时间。尽量找出谁是责任人，然后只给他一个人发邮件。
让某人测试一个功能，而他却不知道该功能最初有什么错误，这是浪费团队成员时间的另一种方式。例如: 有客户抱怨说在IE浏览器中某个按钮不管用。首先接手该问题的一名开发人员解决了这个问题，然后另外一名QA测试它的时候，甚至不知道如何重现该问题。
把你的开发团队分成固定的部分是个坏主意，也是极为不敏捷的(别担心，我们没有使用这个词儿的习惯)。区分‘前端’和‘后端’导致了“Grabenkämpfe” (或者称之为:前后端之间的战争)，毫无疑问这是不符合团队精神的。前端开发者会抱怨说“后台变更的太慢了”，而后台开发人员则会抱怨说“这可是今年第五次修改API了”。
如果仅仅因为这是HiPPO某某(薪水最高的那位)的代码，就发布未经测试的代码，绝对是个糟糕的想法。更为糟糕的是: 这种事发生在周五下班前。当然，除非你是周末加班族，则另当别论了…
是的，听起来有点儿刺耳。但是在没有任何人看过你的页面之前就开始改进CSS动画效果，对于做事情并没有什么好处。如果你还有后台任务或者报告，当服务没有装载完毕时，让它跑个5到10秒并不是什么问题。应当在所有事情都正常工作之后再开始优化。我们还是非常提倡优化的，请参见我们上一篇文章中的第九条!
美国斯坦福大学的已经退休的计算机科学家和荣誉教授Donald Ervin Knuth，是精选著作集´计算机编程艺术(The Art of Computer Programming)´的作者。在他的‘使用goto语句进行结构化编程‘论文中他写到:
程序员们花费了大量时间来思考、或者担心他们的程序中无关紧要的部分的速度，而这会给代码的调试和维护工作带来很大的负面影响。我们应该忘掉细微部分的效率，对于97%的时间来说：过早优化是万恶之源。然而我们也不应该错过那关键的3%。
简而言之：在你弄清楚你到底要优化什么这个问题之前就开始优化，会带来各种各样的不必要的麻烦和错误。
我们应该，我的意思是，我也不会提倡不做备份就对产品进行更改或者没有清晰的思路和说明就进行开发。但幸运的是，你不会经常遇到这些错误。