图片来自抱图网。结果研发负责人解释不清楚，或者技术人员太老实了，不知道怎么表达。最后他们还叫我过来骂我。我不怪老板，她的想法是可以理解的。从投入和产品的角度来看，不重新造轮子没有错；我不能完全责怪我的部下。就像PPT一样简单。双方都对，那么问题出在哪里呢？我把这个问题发到了技术交流群，大家讨论的很热烈。看来这个问题确实是大家的通病。有人抱怨老板不懂技术，需要上课；有人提出需要沟通，需要不断地磨他、骗他；也有人建议老板多参加几个典型的项目，多体会；最后我们把问题归结为“信”字，意思就是所有的问题都可以通过“信”来解决。的确，信任可以解决任何问题。如果老板什么都不懂，他可以相信他的CTO能很好地解决问题；如果老板理解得很好，他会自己解决问题。今天我们不讨论老大的问题。他的需求没有问题。如果我是老板，我会要求不重复投资。在这篇文章中，我将尝试从技术负责人的角度来分析这个问题，并寻求一定的解决方案。为什么系统复用困难？让我们从一个例子开始。我们是医疗行业的一个应用系统，健康档案的管理是一个很常见的功能。我们在某个系统开发了稍微完善一点的模块，所以其他应用只要需要开发健康记录的功能，老板就会说我们做了这个，用着就好了。为什么我们需要重新开发它？我试着回答一下为什么难以复用：由于历史原因，本系统是.net开发的，而我们团队的主流技术栈是Java，开发语言不同，所以无法复用并且只能作为参考。虽然都叫健康管理，但是不同的应用系统还是有很大区别的。慢病管理与专病管理有区别，基层医疗与分级医疗也有区别。即使是同构系统也不能直接重用，需要二次变换。这个模块如果不以公共组件的形式抽象设计，实际上是和当前系统紧耦合的，数据层的耦合，业务逻辑层的耦合，视图层的耦合，尤其是代码层面，如果在其他系统复用，首先要去掉这个耦合，然后做自适应改造。有时再利用的成本并不低于重新开发。①Reuse有个代价DRY原则（Don'tRepeatYourself）相信每个程序员都应该知道。是指我们在写程序的时候，不要一遍又一遍地写类似的代码。当出现一些功能相似的代码时，我们应该把代码的通用部分和具体部分分开，以达到复用通用代码，降低整体复杂度的目的。复用的原理我们都明白，在实际的开发过程中也实际践行过，但是复用其实是有代价的。这就是为什么我们知道重复造轮子不好，但我们还是不停地造轮子，因为很多时候造一个新轮子可能比重新造一个轮子更快更便宜。那么重用的成本是多少？发现可重用组件的代价：很多时候，我们不想重用，但我们不知道是否有我们需要的轮子，以及我们在哪里可以找到它。就像本文开头的研发负责人，他可能真的不知道哪个团队有他的可重复使用的轮子，而老板看到的范围更广，所以她更清楚。这与组织管理和知识管理有关。学习可重用组件的成本：有时候很难理解别人造的轮子的内部结构和逻辑，所以需要学习别人造的轮子的设计和逻辑。这本身就有学习成本。如果对方的设计和实现与自己的想法有出入，那就很尴尬了。可重复使用的组件成本膨胀：以前的人造轮子在他当时的场景或业务中使用。当这个轮子切换到一个新的场景和业务时，你会发现100%的复用性基本是没有的。这时候就涉及到这个轮子的扩容，以适应新的业务。且不说扩容改造是所有者还是使用者（组织逻辑有专门的章节），扩容总是有成本的。修改可复用组件的代价：有时组件的抽象能力不够扩展，或者扩展的时间成本太高，或者组件的拥有者不愿意支持，复用者可能直接用于修改。修改的成本是一个等级，但如果长期来看，修改后的组件会与原来的组件产生差异化，双方的新功能将无法相互复用。未来。②复用是有层次的一般情况。由于复用的组件内容不同，组织关系密切，复用的成本也会不同。例如，重用一个程序很简单，但重用一个系统功能就很难了；重用同一团队的组件非常简单，但跨团队和组织重用就变得困难了。因此，存在复用级别。为了更好的理解，我将复用分为五个层次：层次越低，粒度越小，复用的范围越广，但价值越低；级别越高，粒度越小。值越大，复用的价值就越高，但是复用的范围也是有限的。因此，从业务和价值的角度，首先要从最高层进行复用。只有当上层无法实现复用时，我们才会逐步寻找下层。但是有时候从技术角度来说，我们习惯于在低层复用，因为这是最贴近我们自己的工作，粒度越小，技术越可控。回到本节开头的问题，系统B的功能需要复用系统A的功能，这种复用程度是最高的。如果能够复用的话，会大大减少工作量，降低成本，但是这个层面的复用难度也是最大的，尤其是异构系统，几乎是不可能的。③复用是颗粒状的。影响实现重用时间的因素有很多，这些因素的总和可能会导致更多的重用时间。所以，对于一些时间特别紧迫、生死攸关的业务，在可复用组件不成熟或者可复用组件支持团队不够强大的情况下，可能不会考虑复用。不重复使用的情况就是我们平时说的烟囱系统。现在大环境的说法是烟囱系统不好，在业务成熟的公司确实不好。但是在业务前期chimney系统变化很大，快速野蛮生长的时候，因为不需要考虑复用，没有太多的限制，提供了高效的开发支持，为后来的发展做出了重要贡献。企业的生存。Gartner在研究报告中提出了宏服务、小服务、微服务的粒度划分：宏服务：一种传统的Web服务，支持在单个应用程序中封装功能。宏服务不支持独立部署或扩展，它们只能作为整体应用程序的一部分进行部署，并且不需要微服务基础设施。小服务：从服务粒度上来说，小服务是一个粗粒度的、松耦合的、支持独立部署的应用组件。小型服务需要微服务基础设施。微服务：在粒度范围的远端，微服务是可独立部署的组件，支持实现单个应用程序功能。微服务可以直接部署到微服务运行时环境中，并且通常有专用的数据存储。微服务需要微服务基础设施。如果我们想复用现有系统的能力，可以使用宏服务模型，适合系统集成和治理。对于新的业务和项目，我们最初建议以小服务的形式拆分业务域。不建议分割得太细。这个小服务可以满足需求的基本抽象。从适度的粒度开始，服务的粒度必须在业务推进的过程中不断演进。创新业务促进服务粒度向细粒度方向裂变，业务成熟稳定后，促进服务向粗粒度方向聚合。从复用的角度来看，优先级是宏服务>小服务>微服务，当然难度也大，反之亦然。所以，复用要根据自己团队的发展，业务的实际需求要灵活，也要根据公司的发展阶段逐步实现复用。一般来说，重用的优先级是技术层面的重用优先于业务层面的重用，团队内部的重用优先于团队之间的重用，项目层面的重用优先于产品层面的重用。如何更好的重用老板要求重用是不是错了？没有任何错误！员工说复用太难是真的吗？是真的！作为技术负责人，我们的职责是解决团队的困难，实现老板的目标。具体如何更好的复用，老谭根据自己的工作经验和对这个问题的深入思考，提供了一定的思路，仅供参考。①不要忽视技术栈的管理从复用的角度来看，不同开发语言之间很难复用，虽然对于互联网或者自营信息化来说，也可以通过服务共享来实现复用。对于我们更多在本地交付的软件产品开发，不一致的技术体系是重用和协作兼职的噩梦。在我负责公司研发之前，整个公司并没有统一的技术栈。几乎每个部门都有自己的技术堆栈。当时有.net、Java、PHP等多种语言开发的系统。主流的Java语言还是有Jfinal、SpringBoot、Dubbo等不同的框架。对于技术团队来说，最简单的代码程序层面的复用，由于技术体系的不一致导致无法复用，团队资源无法流动和平衡。这对我们中小型研发团队来说是一场灾难。去中心化的组织必然会带来不统一的技术架构，这就是著名的康威定律（后面会详细介绍）。结合自己的工作经验，我提供以下技术栈管理思路供参考：确定团队主流语言，主流开发框架，主流数据库等：我们确定Java语言是主流语言；SpringBoot是主要的开发框架；服务架构体系；数据库首选MySQL，所有新建项目统一到MySQL。减少非主流技术系统的资源投入，新业务逐渐用主流技术开展：我之前的团队用的是比较小众的JFinal，也转用了主流框架SpringBoot；缩小了Dubbo的使用范围；严格控制非Java系统的资源投入，新业务可采用Java开发的混合系统。逐步改变前后端分离的开发方式，实现大后端后大前端：我们都知道后端稳定，前端多变，前端复用的优先级远弱于后端。但是对于boss来说就不一样了。他们看不到后面的数据库和服务接口。最直观的就是前端，所以不能忽略。我们首先确定了前端开发框架VUE，以防止前端技术的分化。传统的前端开发是准备根据实际需要实现架构的改造。事实上，这种转型需要在前期加大投入。毕竟两个系统前期是要并行的。老板问为什么前后端分离。当然，她不知道的是，如果我们不改变，我们连人（前后）都没有。招不到。中间件不能滥用，新技术的引入需要技术审核：技术人员对各种中间件的使用比较热衷，对新技术的渴求。追求新技术没有错，也需要鼓励创新。但这些都是需要管理的，因为作为技术负责人，我们必须站在团队整体的角度来平衡成本、效率、收益之间的关系。因此，通过技术评审，我们不仅可以引入新技术，还可以管理技术引入带来的学习成本，大规模推广的时机和条件。通过这一系列的举措，我们至少在技术底层做到了适度的统一，不同团队之间的技术交流消除了障碍，大家也很容易一起积累，促进共享。②统一架构，构建统一的平台级应用技术栈，只能让我们实现LV1、LV2级的复用能力，再往上涉及到功能级和业务级，更贴近老板的视角.因此，实现更高层次的复用是每一位技术负责人的追求，也是施展专业能力的舞台。但是在这个环节，我们往往会出现很大的问题，就是不能根据实际情况因地制宜。架构体系非常灵活，没有严格的标准。只能根据实际情况进行权衡。平衡是考验技术领导者的架构艺术。不要小看它。这种能力。很多大厂的人才到小公司做架构。失败案例太多，不是因为架构不好，而是没有用在正确的地方。(1)对于小团队来说，统一的架构体系就像单体应用一样漂亮。我们的常识是，越独立，没有太多耦合关系的组件越容易被复用。过去，烟囱式的单体系统难以重用，意味着模块和系统本身耦合太深，导致重用和改造成本高。这个理论是正确的，但我认为它并不全面。完全去除耦合是不现实的，但需要管理耦合的深度和范围。如果被复用的组件的用户也耦合在同一个环境中，其实是可以复用的。使用。这就好比系统A其实很难复用系统B的模块，因为耦合环境不同，依赖的基础不同；但是A系统很容易复用自己系统的一个模块，因为依赖环境是一样的。因此，如果一个小团队能够在代码层面统一成一个应用，然后通过插件化和代码层面组件化的方式对业务模块进行抽象和管理，单体系统还是很漂亮的。七八年前我带领一个互联网小团队，花了两三个月的时间写了一套基于JFinal（当时刚推出的小众框架，现在很火）的插件式脚手架系统作为我们团队的框架。所有业务发展的工具。这么多年过去了，系统还在健壮的运行着，业务也在不断的发展。我们实现的最新一代的OA系统，这么庞大的系统，从部署结构上来说，其实是一个很大的单体应用。所以，并不是说单一系统不好，只是当它变得太大时我们没有能力管理好它。(2)具有一定规模的技术组织，组织规模扩大后，尤其是分化后，建立统一平台基础复用的成本和难度往往会迅速增加。在多组织中复用组件需要建立统一的标准，不要完全去掉依赖，尽可能依赖单一的东西。每个人都依赖这个单一的东西，这种依赖对复用的影响会降低。因此，具有一定规模的技术组织需要构建统一的平台基础，并在平台基础上存放共享组件，让不同的业务可以依赖相同的底层环境。通过平台库的共享能力，实现垂直业务之间的横向沟通。和协同作用。这种模式特别适合软件产品开发公司。建立在坚实平台上的产品开发是高效的，善于结合和扩展。产品的边界不会因为系统隔离而变得僵化。而且，构建平台基础既适用于单体架构应用，也适用于分布式微服务架构。平台基地实际上是一个有组织、有计划的复用体系建设。下图为笔者团队搭建的平台系统。架构团队主要负责后台引擎的搭建，业务组件（属于中台类）由各研发团队根据业务领域构建，供参考。企业级复用体系：中台架构中的中台广义定义：企业级能力复用平台。虽然我们的集成平台涉及到中台服务部分，但作为研发公司，我们的中台架构和服务是交付给客户的，帮助甲方客户打造中台能力。一般来说，我们所说的中台并不是厂商的中台解决方案，而是互联网公司或者传统企业为满足自身数字化转型需求而搭建的中台系统。是企业运营的中台系统。不是项目交付的中台服务。从广义上讲，中台的范围非常大，涵盖了企业运营的方方面面，而我们更关心的是企业中台的载体，即数字化运营中台。企业首先通过信息化建设，将内部业务从线下转移到线上。在这个阶段，我们一个一个地构建单独的系统。这些系统的集成并不容易，重用几乎是不可能的。最终导致大量的重复开发建设，同时带来更大的系统治理成本。进入数字化甚至智能化时代，面对激烈的市场竞争，企业降本增效的需求越来越迫切。更好的复用、更敏捷的构建是企业的迫切愿望。中台制的提出是这个时代的产物，所以企业关注中台制并尝试去做是对的。至于为什么会失败，我们会在后面的文章中讨论。对于一个具备技术开发能力的公司，比如互联网公司、科技公司等，中台的复用能力不应该是对新建的极端追求。虽然这样比较简单，但是对于企业来说确实是一种浪费。如上图所示，首先是单体应用架构向业务中台架构演进。能用就用。如果可以改造，尽量不要建造。根据康威定律，组织需要支持：当复用的组件需要修改和定制时，我们需要组件维护者的支持，此时需要相应的沟通和协调成本。如果组件提供者与组件用户没有任何利益关系，甚至利益冲突，那么组件提供者就缺乏为用户提供支持的动力，甚至拒绝提供服务。这时候，沟通协调的成本就会特别大。（文中提到的研发负责人，其实很大程度也面临着这个问题，协调修改组件太难，自己修改太难，不如建一个自己动手。）这个问题其实不是软件技术问题。问题，这涉及到组织结构的设计。因此，为了降低沟通和协调的成本，需要更高层次的领导设计来调整组件提供者与用户之间的关系，使其具有相关性和一致性。如下图所示，大家在自己的管辖范围内（颜色对应的横箭头）复用协作相对容易，但一旦超出这个范围，复用协作的难度和成本就会急剧增加。重温康威定律：康威定律：设计系统的组织被迫生产设计，这些设计是这些组织的通信结构的副本。-MelvinConway(1967)设计系统的组织等同于组织通信结构产生的设计.康威定律已经存在了50多年，仍然是指导我们进行系统设计和企业架构的重要定律。它解释了系统架构和组织架构之间的对应关系。其实这个很好理解。一切都由某人执行。人的组织结构决定了系统的架构设计。去中心化的组织很难有高度统一的架构，也注定难以复用。当然，在中心化的组织中，重用和协作的成本是很低的。反之，组织的活跃度就会降低，自主性和创新性就会不足。老板最重要的任务其实就是通过设计组织架构来匹配做事的逻辑，最终达到他想要的效果。希望和愤怒的咆哮是没有用的，这是法律的不可侵犯性。就在阿里巴巴实施中台战略之时，CTO星电（张建峰）亲自掌管中台事业群，负责中台战略的推进。同时，作为当时整个集团的CTO，谁会不配合各业务部门横向实施中台架构体系呢？可见阿里中台战略的执行力有多强，这也是阿里中台能够成为行业标杆的原因。这与其组织的设计密不可分。最后总结一下，复用是老板的合理需求，是技术负责人的核心职责，也是所有技术人员的整体意识。但重用的实现不是老板的执念，不是技术负责人的行政要求，也不是所有技术人的全面抱怨。它需要制度设计、组织支持、相互信任的团队文化和持续改进。的过程。任重而道远，让我们励志前行！作者：老谭简介：人人都是产品经理专栏作家。历任程序员、技术负责人、研发负责人等多个岗位，现任某公司产品研发负责人，擅长企业IT架构和互联网产品架构。编辑：陶家龙来源：转载自公众号菜根老摊（ID：CGLT_TAN）
