在工作中，经常能遇到这两种极端现象：
1，简单事情复杂化
2，复杂事情简单化
这2种极端都是不可取的，需要在工作中进行克服的。
可惜的是，这2种极端又屡次能在工作中遇到，尽管有句话是这么说的：条条道路通罗马。但是不同的道路会导致不同的效果，甚至可能有些道路太过于弯曲而到不了罗马，这种也是存在的。
简单事情复杂化
公司里开一个产品的讨论会，产品经理把该产品的需求、界面原型侃侃说完以后，然后询问下面的开发人员该如何实现。因为以前做个一个类似的产品，只不过那个产品的流程相对固化和简单，而这个产品就复杂多了，业务流程也是多变。然后下面的开发人员发言是相当积极，但是每个人的发言提问都提出了很难实现的说法，然后大家讨论，你说这个解决，那么那个就出现问题；那个解决，这个又出现问题。说来说去，最后都说相当复杂。我听了大家的踊跃发言，一直插不上话，因为太激烈了，各个都是专家啊。到了最后，气氛终于缓点下来，我终于能插上话了，不容易啊，我就这么说（简化了）：“在10多年前，因为没有…技术，所以大家都用那种解决办法，那种解决办法在解决简单固化的流程时效果是不错的；但是此一时彼一时，你们不能拿着这么老掉牙的技术来应付这么复杂的流程和业务。其实，换个思路换个方式，用某种比较先进的技术来做这个产品，大家会发现原来是那么的简单轻松愉快。”，后来大家采纳了我的意见，最后做好的产品所花费时间相当短，相当简单，上线后效果也是非常不错。
这个事情能体现出以下几点：
1，有些技术人员，表现的像是个专家，其实短板很厉害的。
2，有些技术人员，对新的技术没有去学习，一直都用老式的技术，说白了就在单位里混。
3，有些技术人员，看上去好像对新兴技术都精通，好像上知天文下知地理，其实半瓶水在晃悠。
4，有些技术人员，自以为掌握了新技术，就开始滥用技术，不该用的场所用新技术。
上面这几种现象，每个单位都有这样的人可以对号入座，真心希望这样的人能少一点。
复杂事情简单化
有个需求很复杂，数据分析方面的需求，涉及到ETL的复杂度，ETL中还要加入很复杂的业务判断。于是开发人员为了完成这个需求，就千方百计把这个问题给简单化，为了简化，引入了很多约束和限制，最后做好了，用户用起来是相当的别扭，尽管结果能出来，但是整个过程受到了很多制约。
像这样的场景，在每个公司中都大量存在，我有一次去临危受命于一个产品，那个产品已经运转不起来了，我接手后，花了一段时间理顺里面的业务关系和技术，发现整个产品一开始的设计和实现都是还行的，只是在后面的需求开发上就出现了歪的地方，每次的实现都是把复杂事情简单化处理，如此越积越多，导致了到后面不能随便更改一个地方，只要更改了一个地方，N多地方因为简单化处理的弊端导致了都要随之改动。
复杂事情简单化，在某些场景下偶偶用用是没有问题的，为了赶时间赶效率，但是假如一开始不细心耐心的去构建整个流程，不用合适的架构去解决问题，到了后面就会病入膏肓，隐疾越积越多。
上面的这2个极端，希望大家在工作中都要去认真反思，尽力去克服，多想多做多学习，而不要一拍脑袋应付了事。