1、我们做项目的时候,时间、成本、质量是考量的三个维度。用到架构里,我们就要考虑所选择的语言是不是在成本承受范围里。另外,这个成本的考量要综合,要考虑到人员培养的周期、学习的周期、团队配合的周期,以及人员流失带来的人力成本。控制对选择语言的控制力,包括团队领导对这种语言是否有理解和控制力,对其他成员学习这种语言的成本控制的力度,这些也都影响语言的选择。项目特点根据不同的项目需求,最终选择最适合这个项目的语言。在初期尽量保证语言的统一性,因为人员可调配,建议初期不用过多考虑语言在处理某方面的优势。技术健壮性技术健壮性包括文档安全、技术安全、文档的健全程度、活跃度、成熟度、是不是能一直持续更新等。这些
2、也都是我们选择某一种语言技术的关键因素。所以要选择某个语言,我们通常要考虑到今后是否持续更新,否则就和现在很多开源项目一样逐渐销声匿迹。未来你再遇见问题的时候,可能只有自己去维护,可自己能维护这个开源框架的话,错认为还不如自己写一套。技术多样性语言的选择的时候一定要考虑多样性 首先,语言多样性有利于团队持续发展和稳定,团队持续发展稳定了,公司才能持续发展和稳定; 其次,语言多样性能带来更多的选择,利于实现产品合作; 最后,语言多样性也是人才培养的一种方式,对整个行业有利。当然,这不是一成不变的,如果有可能的话,我们应该保证语言的统一,这样的话在初期的时候,我们的人员是可以标配的,当有小项目的时
3、候,分出小组,可灵活组合。关键还是可控的。CTO要有这个意识:通过团队去控制语言,而不是通过语言去控制团队。学习成本出于人员培养的周期、学习的周期、团队配合的周期、人才流失的周期等成本考虑,我觉得在团队的日常建设中最好能做到平稳过渡,人员建设有梯度 低层输送学习进取型人才 中层输送高输出进阶型人才 高层输送管理业务骨干型人才这样每个人发挥强项,互相依赖、互相配合,而且可以逐级引导。在培养团队的时候,CTO要注意高端输出型人才培养,这决定了团队在关键项目是否给力。对于 150 人到 200 人的团队,理想状态是中高端有大批的后备军,而且有几个人能够带领团队前行(一到两个人就足够了),这个团队就很
4、稳。容器选型我个人认为,容器的选择其实比语言的选择要容易一些,主要是当你选择一个很好的容器,性能就会有一种很大的提升。这种选择的背后其实就是成本、时间、质量这三个纬度的PK。例如,公司发展到一定规范的时候,质量要求越来越高,然后对于时间的要求也越来越高,时间固定,质量固定,唯一能做的是增加成本。你想想怎么加成本能搞定这个事,可以加班、加人手、也可以增加硬件成本。未来某一天我们能否做到这一点:投了很少的时间和成本、质量却挺高,这其实就是技术创新了,这时候我们就能解决发展的痛点。通过创新方式去创造奇迹,比马跑得快的一定不是马车,所以要换角度去重新思考痛点。笔者认为长远地看,好的架构是改出来,短期地
5、看,架构是设计出来的。中长期来看架构是边设计边改出来的。架构更多的是解决我们现有的痛点,就跟创业一样,我觉得做架构就是在做技术创业,架构设计的非常好,我们真正的能用多少东西呢?用的东西并不是特别多,所以往往设计出来的东西属于过度设计,从而导致过度开发,所以架构上,设计的成分固然重要,但长远看,其实架构是改出来的。企业的发展是从无到有、从小到大的过程,而企业产品演化的方向同样也是变化的,而且有时间和成本的限制,因此架构在前期、中期、后期需要考虑的点都不一样,前期要的是快和节约成本,尽快面市;中期用户数长上来了,就要考虑安全性、扩展性、稳定性了。所以一个合格的架构师,在我看来,应当因地制宜地选择语
6、言,选择合适的容器和合适的架构,如果能够把团队里的人员、技术、规划、时间、成本、效率,还有幸福度等资源统一协调好,以实现工作目标,我觉得这才是一个合格的架构师。这也是我为什么固执地认为架构是一种文化,而不是单纯的技术。庞大的系统进行解耦解耦主要用的逆向思维,这一点和写游戏外挂非常相似。那么,庞大的系统是如何进行解耦的,解耦是否有规律可循,我个人的理解是要具体情况具体分析,但肯定是有规律可循的。 第一步,“抽象分层”是对解决方案(代理模式)的整体把握,按照业务拆。举例,有一个老系统,它的软件不开源,是什么我不知道,好在这个数据库我能看得见,为了实现扩展,我们做新系统要实现二者的交互,就要加一个抽
7、象的代理层,相当于在这个系统之外再做一个系统,相当于外挂。 第二步,在模块内,熟悉系统,研究数据流。用逆向工程模拟交互接口,一步步拆分。就像我们做一个项目,应该是把一个项目需求全部细分成可持续的共同点,对于这个共同点进行技术评估,评估完以后进行排期。同样的原理,我们对原有的一个系统进行分析,分析完以后,你能逆向出数据表结构最好,好在成型的系统如果文档不全,命名至少是拼音加英文。 第三步,按照功能和数据流向逐一替代,前期设计与数据同步,数据问题需要写外挂去处理。思路和游戏外挂一样的,就是要用大量的逆向工程把系统全部拆出来。 第四步,对数据进行收集,用数学归纳法,要注意的是切分过程一定会有脏数据。
8、针对脏数据,收集bug。数学归纳法穷举问题,分析在每一个流向的时候呈现什么问题,然后有什么样的问题导致这样的情况,然后对它进行修复。 第五步,最后打破现在方案,根据对现有业务的需求,重新设计(按照业务需要设计,并非技术架构)。接下来,我们用电商业务流程和架构举例。主流电商业务流程在主流电商平台中,若需精细化管理各个业务流程,一般会涉及上百个子系统,系统之间的交互接口更是不计其数。任何系统环节出现问题,都会对业务带来或多或少的影响。这里几个大的模块,有基础数据的建档,包括采购入库、退货供应商、电商退换货、电商出库这些东西都是以前软件里的,把它拆分出来,拆出来以后再进行统一布局和升级。发现有的部分
9、拆出来了,还有一部分系统还没有拆出来,但我们都绘制出来,就是说,如果要想对一个系统拆分的话,必须得把这个系统所有的业务模型全部都绘制出来,数据流向全部要摸清楚,你才可以一步一步地去替换。企业的系统流程从上图中可以看出,在实际的应用中,会规划出所有的模块,包括具体的功能,最后就和玩卡牌游戏一样,一个一个的重构,替换,或者重新开发。最终把整个系统编织出来。设计的理念假定给我一个命题,在半个小时内教会一些实习生采用 JavaScript 语言进行目前的一些项目的开发,他们的能力只限于一些常规的基础知识,没有真正做过项目。如果按照常规的方式,我只能说我没有办法,因为受限他们的理解,还有我对质量的要求,
10、还有就是他们很多人根本没办法上手,如果一点点教,时间半个小时肯定不够。但是命题就是如此,我应该怎么才能做到呢?这里除了用创新的方式,别无它法。这里我想引出一种技术框架,这种叫约定式开发。我们怎么能够让不太会写 JavaScript 的人,会写 JavaScript,并且写的好呢?这时我们要有个理念,配置优于编码,也就是让一个不太会写代码的人,通过这种配置的方式可以让引擎自动去生成代码。试想编写完整规范的模块,并且书写风格优良简单,问题是我们如何把它传给别人,并且保持一致?如果我编写一个公用模块给大家用,编写规则引擎,别人只需要按照规则引擎的要求去写一些简单的配置,具体的实现代码是引擎自动生成的。这个时候,我们可以认为代码是自己生成的,我们只负责配置。但是问题来了,配置文件越来越多,要让不太会写的人也能写出来,虽然降低了编码学习成本,但是至少还要学习写配置文件。这里笔者认为,少写代码可以减少复杂度,约定式开发就是一种很好的方式,配置优于编码,但是比配置更极致的方式是约定。这样我们就可以大量减少配置文件。
copyright@ 2008-2022 冰豆网网站版权所有
经营许可证编号:鄂ICP备2022015515号-1