架构师的御人之道
一个团队的成员有很多人，其中包括项目经理，架构师，组长，组员等等其他人员。就纯开发而言，编写代码的人员只有架构师和组长、组员三个角色。要完成架构，就要利用好三种角色的关系，并且使用正确的人。架构师的责任是架构，构建出框架的摸样，而架构在实际应用中包含着两个概念：业务和开发。
业务是架构设计的重要依据，在设计时必须要有一个业务管控的角色和架构师一起进行，而这个业务管控的角色即可以是一个人也可以是多个人。
举个例子，我们在实际开发中经常遇见开发人员说设计不合理，从而产生反感情绪，有甚者拒绝开发。为什么？因为设计违背了开发人员对项目的理解，这些设计指什么？可以是数据库设计，可以是流程设计，也可以是其他。但如果在设计时和对应的业务管控角色一起进行，那么会很大程度的降低这种现象。
开发就是实际编码，实际编码分为两部分，框架编写和项目实现编写，框架编写时很多人有个误区，框架要由架构师完成。实际上框架编写架构师应该只参与一部分，那么就需要在团队中找到一个技术优秀的人和你一起完成框架，这里就是一个人而不是一个角色了，而之后其他组员的疑问，和框架的扩展就由这位成员来解答和完成，这样不但是对这位组员技术的一种锻炼，也节约了架构师的时间。
为什么需要这么一个人呢？举个例子，我们在实际开发中经常遇见开发人员抱怨框架设计不合理，不够细节，这时架构师做的任何解释其实都是惘然，因为一个人的话语永远是苍白无力的，而开发人员对技术的质疑和对业务的质疑对项目进行速度的影响是截然不同的，前者远远大于后者，但如果加一个开发人员和你一起去解释就不同了，它会保证项目顺利的进行。
理论中的架构和实际中的架构差距太大，在理论中，它没有人员的矛盾预测，没有成员的技术能力的预判，也没有人类情绪的设定，理论从来不会告诉你如何实现一个任何人都不理解的框架需要哪些谈判和沟通，他只会告诉你如何制作。而现实中，我们需要谈判，需要沟通，需要技巧，而这些不是一个人能完成的，它需要有人支持，有人理解，我们不能期盼每一个项目都有完美的领导和技术团队，我们只能通过沟通引领一部分人站到我们的身边，在面对困难的时候，能够屹立不摇。
----------------------------------------------------------------------------------------------------
注：此文章为原创，任何形式的转载都请联系作者获得授权并注明出处！
若您觉得这篇文章还不错，请点击下方的【推荐】，非常感谢！
本文已独家授权给脚本之家（ID:jb51net）公众号发布！
