遇到新的业务需求
面。请相信我，再优美的技术结构，经过几茬这样的迭代，都会变得面目全非，杂乱无章。然后等待下一个神来做整体的重构。
侧重点不同的考量问题
比如说，新人发现一个报表系统效率很低，耗时很长，于是嘲笑，连索引都不会吗，这么烂的结构怎么设计的？但是他不知道的是，这个数据结构首先要满足一个非常巨量的每日数据新增，而后才要满足每周一次的报表生成。那么，如果按照他认为生成报表的优美结构来设计，所增加的索引和数据字段的设计，就会在日常带来大量的i/o开销，数据新增的逻辑就会导致额外几倍十几倍的开销，也就是说需要很多台额外的服务器来支撑，而收效却是，可以每周生成报表的时候从几十分钟缩短到几秒钟，那么如果你是老板，你会同意这样的方案吗？
资源紧缺的作品
大公司也会资源紧缺吗？至少人力资源一直是紧缺的，比如有个紧急的活动，有个紧急的任务，时间特别紧，程序员只好急急忙忙从第三方开源软件抓了一段代码，改改塞进去了，反正业务满足了，至于不好那也实在没时间了，结果这个临时活动效果不错，于是慢慢成为常态活动，而这个工程师又去干别的去了，这个代码反正也没出错，那就一直跑着。新人来一看，这啥玩意啊，代码东一榔头西一棒槌，这程序员不会设计系统吗？
那么，下面要说，新人就不能提出现有系统的问题吗？就不能提出改进的方案和建议吗？当然可以。你进入一个企业就是干这个的，公司花钱养你就是让你来改进系统提升业务支撑能力的。但是，这需要有一个正确的认识和思路在前面。
第一，尽可能更完整地了解系统，查看一套代码的时候，了解所谓的不好的起因是什么，历史演进的过程是什么，了解其在业务系统中的地位和价值是什么，有了一些认识和理解后，再来思考所谓好和不好的问题。
第二，从一个最有把握，结构最简单的地方入手，用你认为正确的方式修改一个最小的结构，先通过测试、发布的流程，然后再通过运维和其他主管人员获得反馈，了解改进是否具备对旧版本的比较优势，以及比较优势究竟有多大，多重要。不重要没关系，但是你要了解是否这个改进是正确的；完成第一个后，努力去完成第二个，当你能够顺利发布完成十个或更多的这样的改进和优化，并确认你的代码比较优势确实明显的时候，再来谈别人的代码的问题，如果你这些都做到了，不需要你来谈，你的主管会看得到的。
第三，轻易不要谈重构。
我讲过一个架构悖论，为了满足所谓高扩展性的原因，开发人员做了一个特别复杂的逻辑关系特别庞杂的系统，他们说这个系统多花点时间是值得的，因为以后你有新的需求可以灵活扩展了！于是产品人员和运营耐心等待。
新系统上线后，市场发生了一些变化，新的热点出现。运营人员说，我们能不能增加一些功能。技术人员说，对不起，这个需求在我们设计的初期完全没有考虑到，因为现在架构太复杂了，所以这个版本肯定不能支持，你放心，下次重构的时候我们会考虑的。
我对架构的原则是，适度灵活，简单至上。你会发现，越是简单的架构，遇到新的业务需求，改动和升级越容易，很简单的一个道理，新的工程师进来看代码理解逻辑的成本低。所谓照顾更多的需求可能性，这么说吧，人家设计了开发语言，就是照顾更多需求的可能性，你难道也要设计一款开发语言？
如果你发现一个巨头依然存在很多技术上连你都觉得不对的问题，你应该高兴才对，这不是你的机会吗？但是你要明白，哪些是真的问题，哪些是你涉世不深的误会，你一步步解决这些问题，在解决过程中一步步理解系统，到一定程度，你会明白更多，理解更深。只是站出来喊，这些垃圾那些垃圾，只能暴露你的浅薄和无知。
走出心理舒适区
我们经常会看到一些新闻，一些学霸在职场出现困境，陷入绝望；身边也经常遇到这样的例子，不少学霸对自己职场状况不满意，会说，我其实很努力，很勤奋，为什么不如当年的学渣同学发展得好。其实很大一个原因就是他们的勤奋，往往是用某种领域的勤奋，去掩盖他们在另一方面的懒惰和怯懦。我用一个词描述——心理舒适区，他们看上去很辛苦，很努力，其实是躲在自己的心理舒适区里。上自习，上课，刷题，刷学分，累但是很满足，这是他们觉得自己最适应最自我满足的一种状态，而沉醉在其中，可一旦外部环境发生了改变，他们所擅长的学习和生活方式发生了根本的变化，他们就会陷入无所适从，不知所措的境地。
当然，实话实说，随着职场的锤炼，99%的这种症状会自愈，但这个过程还是很伤人的，比如怀疑自己，失去信心，以及心态变得消极。心理舒适区往往来自于一种习惯，来自于你所熟悉的场景。很多打工的人觉得自己很辛苦，很努力，但是其实很多时候他们的辛苦和努力也是在掩盖他们拒绝改变的一种怯懦。辛辛苦苦很早起来去上班，很晚回家，辛辛苦苦做很多事情，但是拒绝去学一种新技能，拒绝去尝试一种新的领域和机会，这都是躲在心理舒适区的表现。
每个人都会有自己的心理舒适区，都会有自己习惯的生活方式，沟通交流方式，以及有自己拒绝和不愿意面对的领域，这也不奇怪。从校园到职场，其实可以说是从一个心理舒适区走向另一个心理舒
