答疑解惑【程序员成长之道系列文章之3】

引言

人生来彷徨。每个人要走的道路都是不同的，在未走过的路上走着，一路都是陌生的风景，陌生的路人，还有许许多多陌生的坎横在路中间，怎么会不徘徊彷徨？作为程序员，在我们职业成长的道路上，同样也会迷茫。
一个朋友曾向我提出过3个问题，在思考这几个问题的同时，我感觉到，这应该是所有程序员都可能会遇到的问题。这几个普遍的问题，可以称得上是我们“成长的烦恼”。
下面的篇幅中，会介绍我对于这几个问题的看法，期望能解决掉大部分程序员都会有的几个疑问。看后，大家如果有什么问题，欢迎回复讨论。

一 技术&业务

任何技术开发工作都离不开一定的业务场景。
很多程序员可能会有这样的疑问：整天都忙着讨论业务，真正能用来写代码的时间并不多，这会不会耽误我的技术成长？我是否应该换个工作，我希望新工作能让我专注在开发上，我能有足够的时间研究技术。
对于这一类的疑问，我给大家的回答是：业务不会耽误技术成长。这个问题很经典，可以说跟“先有蛋还是先有鸡”有异曲同工之妙。技术第一还是业务第一？
我的看法是，技术和业务同样重要，两手都要抓，两手都要硬。大家应该思考如何能在复杂的业务需求中实现技术成长，这才是职业发展的关键因素。
技术离不开业务，没了业务，谁会需要你的技术？就如同，没有蛋，怎么孵化小鸡呢？同样，没有技术，你的业务永远解决不了。如果只懂业务，不懂技术，顶多是个产品经理，不能称为程序员。这个道理就如同，没有鸡，谁来下蛋？
那为什么技术和业务都要抓呢？只搞好技术不可以吗？不是不可以，但是这样会限制你未来的发展。限制点是：1）不能深入了解业务，选择的技术架构可能不能支持未来业务的发展；2）不能理解业务，就没办法将真实的业务建模转化为数据模型和相应的代码结构。这些工作都是架构师应该干的活。没错，没有业务思维会限制你，让你很难做一个合格的架构师。试想，如果你只懂技术，不关心业务，你是不是只能干别人给你分配好的需求和现成的工作？你理解你做的工作有什么意义吗？解决了哪些业务需求呢？
大家可能还有这样一个疑问？难道我支持的业务这么重要吗？了解这些业务对我有用吗？我该怎么样有业务思维，培养架构师思维呢？下面给大家说一下如何去评判业务的重要性的方法，以及如何培养架构师思维。
先说一个题外话，建议大家去阅读一下王概凯的《架构漫谈》，里面系统的介绍了如何架构师思维。下面我说一下我对架构师工作的理解，架构师需要具备将业务需求落地为技术架构，并能保证业务需求得到很好的支持。这些能力包括：1）理解业务，明白需求是什么，要解决什么问题；2）对业务需求建模，每个模型能够用一定的技术工具去实现和支持相应的功能；3）工作统筹安排，落地整个技术架构；4）支持不断演变的业务需求。是不是感觉头大了？说的我自己都感觉很绕口。通俗点说就是，当业务上有了需求，架构师就负责分析这些需求，想明白如何能最好的支持这些需求，并带着大家把技术落地，并且能够运维和优化这些系统，以便能支持不断变化的需求。
关于架构师的职责，就此打住吧，本文的中心在于强调业务对于我们职业发展的重要性。说了这么多，大家应该理解我的观点了 —-了解业务需求是设计架构的基础。
这里，我想提出我的观点，一个价值连城的思维方式，模型思维。
每种技术都可以认为是一个模型，多个小模型组合，又可以组合出一个大模型。我们都玩过积木，每一块最小的积木都可以认为是一个模型，把这些小模型按照一定的结构进行拼装，可以组装成一个大模型。以此类推，多个大模型按照一定的结构进行拼装，可以组装成一个更大的模型......技术的架构也是同样的道理，每个架构都是由一个个的小工具、技术按照一定的结构组合得到的。
要想学习架构师思维，就要理解”模型思维”这种思维方式。
不同的架构如同一个个的模型，这些模型之间多多少少都会有一定的差异性，他们存在的意义在于解决业务的需求。所以，学习一种架构，首先要理解它要解决的业务需求。理解了需求，就学习到了这种架构的应用场景，以后遇到类似的场景，我们便能回忆起来这种架构的可用性。理解了一种架构不足以成为架构师，我们需要不断的积累，积累各种各种的需求场景的架构方案。然后在我们的大脑中，训练出一个个的模型，遇到A这种业务场景，就用A的解决方案，遇到B的业务场景，就用B的解决方案......当我们积累了很多架构方案之后，便可以从这些业务场景和架构方案中提取共性，然后把这些共性加以理解，积淀成我们自己的理解和知识。
关于业务的理解和架构的积累，关于“模型思维”，上面的介绍有些抽象。后面，我会添加一些实例来形象描述这个模型思维。
如何评估我在当前的工作中是否还有成长空间呢？我是否该换工作呢？
依我看，这个评估标准是：
1）我是否充分掌握了目前的技术架构，评估是否掌握技术架构的方法可以是：如果让我完整的从0到1的把这套技术架构实现，我能否在一定时间内做完？
2）如果第一点是肯定的，我们还可以看第二点：是否有机会接触新的技术架构？
如果我们充分的掌握了现有的技术架构，而且没有机会接触新的技术架构。那就是时候考虑换工作了。

二 新东西&旧东西

有了前面的铺垫，这个问题就很好回答了。
如果只对做新东西感兴趣，可以多问几个问题：旧的东西，我是否完全掌握了呢？旧的技术和架构，我能否完全应用到其他业务上？如果不能做到这两点，同时对旧的业务不感兴趣，而只想做新东西，那么就有眼高手低的嫌疑了。
当有这个想法时，多问自己几个问题。

三 团队合作

我们都怕在工作中遇到难相处的同事，遇到了怎么办呢？这个问题很难回答。
多说无益，关于这个问题，我只建议大家尽量避免无效的沟通，所有不以解决问题为目的的讨论、争吵、推诿都是无意义的。做到这一点，我们应该就能和绝大部分同事友好合作了。
多和正能量的同事合作，远离负能量源。