物极必反
物极必反是很多人都明白的一个道理，在软件开发中也一样，比如过度设计，这也是为什么Fackbook推崇“完成比完美更重要”的原因。
读书
读书绝对是一件好事情，但是读书多就一定有帮助吗？在软件开发领域，读了一本技术书后，如果没有动手再实践一下，那知识永远只存在于理论中，并没有真正成为自己的东西。只有动手做了项目或者demo之后，才能真正记住书里的东西，在动手的过程中可能还能发现比书里更好的方法来解决问题。
人的时间精力是有限的，如果把时间都花在看书上，那实践能力肯定好不到哪里去，代码只有动手写过才能真正记住。“读万卷书不如走万里路”说的也是这个道理。技术领域的发展是迅速的，没有一种技术可以一直保持领先，没有一本技术书可以不过时，所以读书我觉得要看经典的，不用太多，每月保持1~2本是比较合适的。
当然，如果是新项目要了解的技术比较多，那这个时候就要多读几本书恶补一下，但切记读完书后还是要动手实践，这样才能真正巩固自己的知识。
代码覆盖率
最近看到有个大牛说过，百分百的覆盖率就像看报纸时要看完报纸上每个字一样，没有必要。根据二八原则，当你的代码覆盖率达到80%后，你还想往上涨，那意味着你要付出的代价就越大，得到的价值就越小，与其花那么大精力在百分百覆盖率上面，还不如把精力放到其他能保证产品质量的事情上。
百分百的覆盖率不能保证就有好的产品质量，但高的覆盖率肯定是要有很多的测试案例来支持的，越多的测试案例就意味着需要付出越多的精力来维护，会让团队越来越讨厌单元测试。
重复代码
DRY原则大家都知道，Don't repeat yourself，但是不是一发现有重复代码就要抽取成公共代码呢？其实经常做重构的同学应该比较清楚，一开始就想把代码写得很漂亮很完美那是不可能的，漂亮的代码都是重构出来的。先用丑陋的代码把功能实现，然后再用重构的手法把代码写得更具可读性和维护性，这是一个正常可行的过程，如果一开始就想写出完美的代码，那到最后写出来的代码可能是既不好看又不实用。
在编码的过程中，可以稍微让重复的代码增长一些，等重复的代码多到一定的程度后，你会从这些重复代码中发现一定的规律，这个时候再来抽取公共代码，这样的话公共代码的可用性、适用范围会更好一些。
舒适区
以前在一些敏捷开发的书或者培训中经常听到“跳出自己的舒适区”这一说法，意思是要敢于尝试不同的编程语言或技术领域，当你在“不舒适的区域”呆习惯了，你的舒适区就扩大了，从而你的能力也就增强了。
但最近看到有些人开始滥用这个说法，比如有人要求团队没日没夜加班，然后美其名曰说是要逼团队每个人走出自己的舒适区，这种说法我觉得是没搞懂什么是“非舒适区”。把学习新技能（比如学习新的编程语言）作为非舒适区我可以理解，这种一旦掌握了技能就不会像原来一样不适应了，这个过程不舒适程度是随着时间慢慢减少的，是有时间限制的，除非你一直学不会新技能（其实是不想学吧-_-）。
但是加班不一样，加班久了你就会觉得加班很舒服吗？人的精力是有限的，熬夜加班势必导致第二天无法以正常状态上班，更何况长期的加班。加班不是让人呆在一个“非舒适区”，而是一个“不健康区域”或者叫“危险区域”，在这个区域没有办法从“不舒适”变成“舒适”，改变的只有作息规律，可能长期加班后晚上精神一点，但白天就没什么状态了，但这样做又有什么意义。
