关于架构、架构师和技术团队的一些事情

在架构搭建和技术研发上，除了正常的行内人的有益争论，相信大家往往也会受到一些行外人的质疑和其他目的干扰（说实话，经常遇到一些半吊子或啥也不懂的高大上的人拿着一些看似高大上的名词咋呼咋呼，比如架构、重构、敏捷之类的，对于TA们，我有看马戏的心情，也有深深的惆怅，当然有时也会得到好建议），作为一名现在还写代码和搭建架构的老程序员，我觉得有必要写一些东西，提出一些问题，说说我的思考，期望看到大家更多的反馈，看看这些问题是否很普遍（可能在一些非技术公司、没有工程师文化的工程师团队中尤其）？大家是怎么解决的？

先给出我要列出的问题和我的思考的一个目录，方便大家可跳跃的查看（按照后面行文的先后顺序）：

• 世界上真的有行外人所说的高大上的架构吗？
• 何为重构？何为可控性和可用性？
• 使用第三方架构还是自己量身打造架构？
• 如何打造一个执行力高、被外界干扰最少的技术团队？（这部分特别建议行外人员也看看）
• 怎样成为一名架构师，并建立架构？
• 架构和编码质量的关系？

世界上真的有非内行人所说的高大上的架构吗？

=========

我用过那么多第三方架构，到目前为止也没有见过所谓高大上的架构，也没有听到行内人说过（倒是经常听到行外人说）有这样的架构；即使是我自己每年都会创建的新架构，不管自己多满意，也会在必要的前提下不断的保持完善性迭代重构。

不管是以前称霸桌面平台开发10多年的MFC（现在用的人很少）、发展到现在的各种J2EE架构（EJB，Spring，Struts等）、还是Hadoop栈，OpenStack栈、Docker等，所有架构都有一个很朴素的起点，就是解决当前一个团队、一个公司的实际问题，然后逐步在适应团队节奏、适应需求上重构（技术和架构重构），逐步完善和叠加，加上很多科技公司都认同开源（什么原因以后有机会再分享，有很深的历史原因），当重构到一定阶段，这些科技公司处于各种考量便会正式开源，给全球使用（我们团队现在使用的很多第三方工具和框架就是这样来的，包括我现在给团队建议的简单易用的PHP、Linux、Nginx、Redis、MySQL、XunSearch/Xapian、Angular.js、Node.js等）。即使现在，Hadoop的应用Stack也已经重构到了2.0，各个大公司的内部各种架构也都在进行不断重构，谁能告诉我什么架构不再重构了吗？对，已经死了的架构！重构之于技术架构，就如心态调整之于前行的人——因为这个世界不存在能洞悉一切、预知一切并提前做好一切的人。

所以架构本质都是朴素的，即使是用了很优美的方式解决问题的框架，我们也只会谨慎的鼓掌欢呼，不会过度吹嘘。只不过在架构的过程中，一些为了沟通简便而起的名词和缩写，让行外人觉得不明觉厉，或别有目的自我吹嘘，把这些视作一些不可控的副产品吧。我这十几年的体会是，所谓的高大上和牛B，不管描述什么，都是有点不靠谱的，都是外行人或者恭维的评价，是一种表态，没有多少实质。这个世界上没有静止的、可以一劳永逸的架构，只有静止的、想一劳永逸的外行人；没有高大上和牛B的吹嘘物事，只有因无知而产生的恐惧或敬畏，只有朴素的用实践来解决的一个个具体问题。

何为重构？何为可控性和可用性？

=========

首先，这个重构非外行人理解的对架构的完全推翻重来，绝大多数情况都不是这样！！！要真的这样，外行人早就屁滚尿流了。有时候修改一些架构底层的Bug或微调一些代码配置也算是重构。

我说的这个重构（Refactor）是技术架构重构，不包括业务架构重构（这个我外行）。我们行业，对技术和架构的重构是普遍的。一个是为了满足不断更新的需求，还有就是为了满足团队更高的效率、实现新发现的更好方法、让架构更适合团队节奏、修复一些大小问题等。不管是依赖于第三方架构、还是主要使用自己的架构。 有些重构可能只需要一个技术人员的一个小时就完成了，有些需要整个团队几个礼拜或更长。但我觉得要避免对非行外人员说重构，因为这会吓坏他们，他们在把这不熟悉的问题放大，情况就变为非技术化的甚至是政治化的，那么就真正恶化为难以控制了。

一般而言，现在大多数公司的平台开发都同时依赖于第三方架构和自己的架构，无非谁主谁次的问题，这里有个平衡点，主要就是要根据技术团队的实际情况考虑可控性和可用性。

比如一把宝刀，如果让一个不会舞刀的人来拿，就会很危险，就没有可控性，可用性也不会好（还会砍到自己），我会建议这个人拿菜刀，而不是宝刀，菜刀也许更适合TA，如果菜刀不适合就需要给TA量身打造一把刀了（可能是木头刀）；如果砍的目标是高手，我们就要当机立断的把TA换成高手再根据实际情况找合适的刀。放到到一些我们程序员遇到的实际例子中，相信大多数每个月都会有这样大大小小的可控性和可用性考量。

我最近遇到的就是XunSearch使用问题。我7月份就根据现在技术团队的实际情况（技术能力和时间紧迫）放弃了使用更底层的搜索引擎架构和MQ粘合，而是选了这个我发现最简单的架构XunSearch（和PHP无缝对接，初级程序员一天就能上手，等先实现功能有时间后，技术人员进步一点后，再结合MQ重构成Xapian或其他全文检索体系）。但是最近。技术团队遇到了不支持一个字段不同范围同时查询、以及更快建立索引的问题，在我看来这是个小问题。所以最近我抽出时间来看，发现更快的建立索引在XunSearch的公开的中文API文档上就用，叫SIndex.flushIndex()接口，仔细看文档再动手测试一下就好，为什么他们没去看呢？对于同一字段多个不同范围，我看了底层代码（Xapian）和对应文档（这个技术团队普遍英文不好，不管会不会看，也没法看，所以只能我去看），典型的通用搜索语句："age: 15..30 or age: 45..60"，在确认后我还和负责Xapian开源的邮件群进行了沟通（还被老外鄙视问这种傻B问题，给了我-1，我也觉得自己很傻）。这说明什么？在可控性和可用性的考量上，也需要我们部分研发工程师的学习和研究得跟的上，而非只是被动的接受和使用，技术团队的成长作为很重要的因素必要被考虑进来。但是这个问题最后却被非行外人员获知，被当成严重问题处理，放大成对整个技术架构（PHP、Linux、Nginx、Redis、MySQL、XunSearch/Xapian、Node.js、自定义协议等）的质疑，我只能说我能理解无知，但也很无奈。最后在征询了部分技术人员建议，以及部分管理人员的意见（不要问我为什么还要征询管理人员）后，后续会提前结合ElasticSearch/Lucene/MQ给团队搭建一套新的后台数据全文检索平台，而且接口一定要简单好用。好吧，看来这个问题只能我来解决了;)

最后说句公道话，一直知道XunSearch开源接口设计和开源团队的支持还不够好，但好用，可以快速使用，而且在一定程度上够用。XunSearch我在github上就看到基本就hightman一个人在维护，还得养家糊口，没有多少赞助（统计他们的官网，捐助加起来还不到5000）……我不认识hightman，但我愿意给hightman做个宣传：中、小型应用和团队如果用PHP，都可以考虑把XunSearch来做搜索引擎，以后可以平滑替换成其底层的大名鼎鼎的Xapian（Xapian虽然C++写的，支持各种语言接口，包括但不限于Java、Python、PHP等，接口和Lucene类似），从2013年开始，我在时间和规模紧张的项目上都用的XunSearch，让我们在满足应用的基础上，积极支持国内的开源人吧。

使用第三方架构还是自己量身打造架构？

=========

我在第三方架构和自主架构的考量上，一直秉持这么一个原则：如果需求变化不大、使用范围不大、扩展不要灵活，那么就直接在第三方架构上开发，先实现需求是第一目的，还要求资深的研发人员能对第三方架构底层要有一定程度的了解，提高对第三方架构的可控性；如果需求变化大、使用范围大、扩展灵活，那么就必须自己建立架构，然后融合其他第三方架构和自己的代码，根据团队的人员实际情况、需求的明确度和变化性，保持正常范围和频度的技术重构。

不管使用第三方架构还是自己量身打造的架构，都会面临技术团队部分成员对这些架构的考量点理解不到位，原因主要是每个人的技术经验和领悟程度有差别，很正常。我解决这些问题的方法就是尽量引导其理解，实在理解不了的，就不要花时间解释，让他们先集中在当前的开发和实现上，后面不理解的会水到渠成的理解。

无论如何，只要涉及架构，或多或少都会对技术团队的深度有要求。之前遇到一个.NET团队，用.NET MVC开发了几年的解决方案，却对使用EF要注意分布式限制不了解、以及对IIS和数据库的连接池、消息队列、并发等一无所知！！！好吧，只单机版没有问题，绝大多数二线城市的技术团队都如此，但分布式有并发需求的应用呢？有人说，用LD，Docker——说实话，连前面那些基本的你都不清楚，你真的能理解并且能用好这些第三方系统吗？

如何打造一个有执行力、被外界干扰最少的技术团队？（这部分特别建议行外人员也看看）

=========

看过很多公司，他们计划着很大的目标，资源，但是每每年底，他们都不能真正达到目标，为什么，因为执行力。真正能达到目标的，都是有执行力的公司，比如华为这样的，他们都已经或正在奔着伟大而去，而他们身后的模仿者却还在苦苦思索，为什么？这是个真正Big Question，我不敢也没资格说我的认识，怕误导了大家，我只敢说说技术团队的执行力。

说到执行力，现在很多公司都有技术研发团队，这个技术研发团队对执行力的决定性往往是及其重要的，甚至还是至关重要的，很多上层目标往往都会对应底层的某个技术实现。我从06年开始用敏捷带团队（那位仁兄拿着字典和教科书以及认证又冒出来了，你看字典，敏捷是这个意思……你又赢了），到现在，我有成熟的关于技术团队的一些体系认识，也有我理想的技术团队组成情况。下面我就描述一下，并且说明理由。

我总结的有执行力的技术团队：

• 技术不会说谎，但人会，人会根据不同方向，说不同的鬼话，所以要让技术团队的人，尽量说实事求是的话，贴合实际技术的话，这样才能让团队的精力和时间集中在最重要的执行上，执行力就会高，所以技术团队绝大多数要由实事求是、敢于直言的人组成，通俗来说让高智商、低情商的人来组成，效果最好，最符合技术的本质，执行率当然会高。
• 尽量减少高情商人士在技术团队的比例，但一定要有高情商人员作为manager（这个manager最好也是技术出身，至少也得是半吊子），因为他们有对人说人话，对鬼说鬼话的强大能力，可以作为整个技术团队的防火墙，对内协调和激励团队，对外不让政治、分歧进入从而保护团队，让技术人员不会成为政治斗争的棋子，并组织各种资源支撑团队，让团队集中精力在执行上（Google创始人刚开始把所有manager开了也太极端了，manager在技术团队还是必要的，而且有时当老大也比较合适）。
• 如果产品人员不在技术团队内，由manager负责具体的需求对接，决定实现那些，不实现那些——对manager要求就高了，当然，产品人员如果有能力，也可以担当这个manager，这样最好。
• 单个技术战斗队伍的人数不能多，5人为佳，建立人员的层次，比如有资深程序员，也有初级程序员等；建立技术的层次，有高深的技术，有浅的技术。这样既保持人员的成长性，也能保证技术的成长性，也增加了战斗队伍的灵活性和竞争性。
• 要有足够的技术中间层人员（一般是一些技术Leader、资深程序员等），没有就要努力培养或者招聘，真正的执行力往往就决定于这些技术中间层人员。
• 要理解对于技术人员来说，除了工资，他们的成就感是什么，特别是对于一些销售型公司，只满足的销售人员的成就感，技术人员往往被压制在底层，怎么会有战斗力和执行力？一个非技术出身的manager又如何真正明白技术人员的成就感是啥？
• 太多的非直接执行人，比如太多的manager，不仅不会促进执行力，反而还会因为过多的沟通和管理层次阻碍执行力。我一直记得我以前的领导Hunter说的话“一个人在团队，不是促进就是阻碍，绝对没有不影响这一说法”。太多的说话的manager往往会为了自己的利益、业绩、权利等相互争斗，让团队无所适从，从而大大降低执行力。

怎样成为一名架构师，并建立架构？

=========

最近遇到一名自称是咨询行业出身的技术架构师的哥们，反正开始我还想认真的和他讨论架构上的事情（我以为是同行，虽然奇怪没有在他身上感到任何技术气息）以实现相互沟通和学习借鉴的目的，但在听到他说没有学习过某3本我从来没听过的教科书就不能成为架构师后，我就淡定了，我觉得就没有必要和他认真讨论了，反正我也听不懂他说的神秘论和他看似伟大的经历到底和技术有啥关系，反正能肯定他的目的和技术一点关系都没有，但保持谦虚的态度还是有必要的，所以我作谦虚状的听着他口若悬河……

何为架构师？我没有资格去做定义。我只说说我所接触的国内的一些现状。相当部分架构师是一种技术职位比较高的级别，所以你就会看到有些人写了本技术书籍，就被某公司升级为架构师；或者某程序员在某公司工作了8年，然后就被升级了架构师；或者是某些咨询公司为了忽悠所需，把一知半解的人的名片印为架构师……即使是这些架构师，真正自己写过架构的有多少呢？据我了解很少。有多少架构师还在不断接触新技术并且动手实践，还在不间断的和团队一起或多或少的写代码呢？更少。只会使用别人架构的架构师本身就是一个很大的缺陷，只会嘴上架构的就是一个大忽悠。这些架构师和那些建立技术架构的人，本身就没有多少关系。

那么如何建立技术架构呢？我觉得，没有大量编码项目实践经验，没有大量的解决技术问题的经验，没有见多识广过很多其他架构，没有自己大量思考积累的，就很难建立真正的技术架构，至多也只建立了一个简单过程而已。如果你还要问怎么建立技术架构，我会说:大量编码项目实践经验+大量的解决技术问题的经验+见多识广过很多其他架构+自己大量思考积累+动手实践动手实践动手实践（最后一点最重要，重要的说三遍）。我这几年建立的架构，我在设计完成后，都会找机会实际进行Coding去完成具体的业务需求，从而实现从下到上的体会和调整，不能只有由上到下。

……写到这里，我脑海里想起那位仁兄可能会拿起一本字典，对我义正言辞的说，你看这个字典对架构师做了明确的定义，不是你说的那样……好吧，兄弟，嗯，我觉得我们说的完全不相干的两码事，但你赢了。

架构和编码质量的关系？

=========

有人说架构和编码质量的关系，就如大楼设计和室内油漆工的关系，油漆工不认真导致油漆刷的不均匀，和大楼设计有啥关系。嗯，这个说法大部分我都同意。但我的经验告诉我，建立一个架构，必须要考虑实现这个架构的技术团队的实际情况，也就是要把人的情况考虑进去，当然有时候还得把政治考虑进去。

最后这点，我就说的简单一些，分享一下我的经验。比如团队里有实习生，有普通程序员，有资深程序员，在设计架构时候，就要考虑分层，不同的层，对技术要求不同，比如需要增删改查的抽象出来作为业务处理层，只要实习生或普通程序员有基本的增删改查编程技能，再熟悉一点业务，就能开发了，再在架构上附上硬性的TDD要求，让这些菜鸟不跑过单元测试，就完成不了任务；而下面的几层，可能涉及交换、MQ实现、复杂算法、驱动、连接池等，就交给资深程序员吧。这样，就满足的团队的实际情况，兼顾了效率和功能实现，还能在资深程序员经常review上层简单业务代码的情况下，提高代码质量，并协助提高初级人员的编码技能。

什么，你不信，那没事，你试试让一个普通程序员走进满是对象和设计模式的Framework里，看看他的编码质量会有多高，看看他会不会迷路……也许等他从迷宫走出来，你竞争对手的产品都已经开发完了。

PS：最后的最后，宣传一下我的理论，35岁前后才是程序员的黄金年龄，因为这个时候的经验、知识、能力、沟通、见识、人脉……的综合达到了最高值，如果我们国内有一大批这个层次的程序员，那么我们国内会开发出很多伟大的产品。到了这个年龄的程序员，请坚持下去，去找一个伟大的方向，去开发一个伟大的产品，不要浪费时间在考虑转管理、转销售、办公室政治之类的鸡毛蒜皮上。