八叉说内容提炼记录

原创
01/25 00:42
阅读数 9.2K

统一语言的坏味道:

dao对于ddd来说是坏味道,因为它是纯技术层面数据访问内容。使用它,说明程序员放弃了对于业务逻辑领域归属的考量——不应该让业务去找技术归属。repository比dao好一些,它应该存在于聚合根上,如果确实考虑了业务对于数据的操作的封装,它就是好的。如果仍然对于数据库对象各产生一个操作对象,还是仅仅对dao一个重命名,没有意义。

业务的数据逻辑可以拆分为对象的逻辑和集合的逻辑,引入集合逻辑对象,有助于明确业务逻辑,减少坏味道。

低代码是行业毒瘤:

形式逻辑和历史事实证明,让不懂代码的人写代码的想法是错的。图灵邱奇定律:没有一个模型可以跨越另一个模型提供额外的能力。图灵完备意味着提供完整能力,非程序员无法跨越编程知识而掌握,非图灵完备意味着功能缺失。非程序员不能借助一种新语言跨越编码细节,实现程序编写。最终还是会落在程序员头上。

民主化编程:

企业中有一些员工的工作可以被数字化规范起来,但是如果投入开发团队没有商业收益,对于这一部分情况,低代码平台是有效的,这一部分员工可以开发低代码功能给自己用,把自己工作内容自动化。当前企业发展中,产生了许多可复用的能力,包装成了微服务,而对微服务能力的整合,又能做一些全新的事情,这一部分有些就会被低代码平台的开发利用起来,给员工自己使用。所以低代码平台可以作为企业应用需求的孵化器,通用性强的需求,可以派发开发资源统一的整合。为了节约成本直接用低代码平台招烂开发,或者用它直接开发出产品化内容,都是畸形的、不应出现的。

围绕现金日记账和KPI是业务建模最有效的方法:

传统的快速了解一家企业的业务的通用方法就是通过看它的账目,放在今天也是存在有效性的办法。对企业业务建模需要把握住两点,一个是价值流,一个是组织架构,而现金日记账是还原现金流最基础的技术,它就体现价值流。现金流就会反映收入支出,追溯这些内容可以得到领域事件。收入一笔钱一定是企业提供了某些服务给客户,它体现了企业的合约义务和履约行为。收入一笔钱一定是获得某些服务,同样可以追溯出合约权利和履约行为。这是一个公司业务合法合规的底线,所以一定存在。有些业务内容存在,但是无法直接关联到现金日记账,这样的业务要看与KPI的关联。KPI反映的是企业对员工的管理目标,相当于企业与员工的合约。

测试金字塔和测试策略:

系统需要两类测试:发现问题的测试和定位问题的测试。功能测试覆盖代码量大,主要用于发现问题,单元测试、组件测试和集成测试覆盖代码量小,用于定位问题。单元测试本身一般已经不能验证功能是否正确,需要构造等效测试,把功能测试等效为一系列单元测试,使得它能帮你定位问题。所以测试金字塔只是一种实现策略的结论,本质上,你要思考你的测试策略能不能帮你达到上述目的,怎样帮你达到目的,怎么实现效率最高,来具体设计测试策略。

六边形架构还值得选择么:

六边形架构核心价值是通过适配器桥接,定义边界输入输出,把业务和技术的内容分离,来保持技术架构改变时,业务可以不变。但实际上需求变化比技术架构变化要快的多。六边形架构本身是基于单体架构假设的一种设计,当时认为是变化,需要隔离的部分,今天已经不再是变化的了。考虑架构时,应当先从部署结构和物理形态考虑:今天的部署和当时非常不同,所以六边形架构基于过时设计,不能适应今天的情况。只有从最基本的原理思考,怎样隔离和适应变化,才是有效的架构设计的思路。

面向对象仍然是默认的选项么:

面向对象的前提是数据完备于内存中,这种情况下,把数据模型和数据处理的逻辑放在一起是合适的实现。后来出现数据库之后,数据不再是完备的,完整的面向对象就不存在,自然而然的出现贫血模型。seviceless的架构完全把逻辑和数据剥离,而hadoop则倒置为代码迁移给数据源去执行。这些新兴事物提示我们,面向对象不应该被看作一种默认的实现。从restful接口外部看,无论是否是面向对象的设计,都是无关的。

TDD和瀑布没什么区别:

瀑布需要完备的文档,在纸面预演开发过程,完备的思考和解决可能遇到的问题。TDD将需求拆分成任务,每个任务大约15min左右,都是用测试用例表达的。在这一过程中澄清需求和发现技术能力缺失,去尝试补充能力。殊途同归,都是软件开发的良好实践。

好的showcase:

好的showcase就是没有惊喜,也没有意外的。你可以先通过与showcase各方私下沟通,趟平问题。可能有人挑战,但要保证基本盘。最好的是让一部分业务方回答其他业务方的问题。showcase在敏捷中非常重要,没有通过的情况客户可以不付钱。showcase可以弥补客户对敏捷项目的当前状态把握的缺失。showcase不需要开发人员发光,可以把舞台给客户和领导,让他们多表现。

为什么说《领域驱动设计》已经过时了:

领域驱动设计通过领域建模解决业务复杂度问题。根本复杂度来自业务,进一步看,来自运维模式和业务模式变化的时候,it如何去跟随。而领域驱动设计没有这方面内容,它没有对变化点建模和描述的内容。对于一个企业来说,用户渠道变化最快,运维模式次之,业务模式最次。在不同的速率上,系统稳定的程度不同,适用于ddd的程度就不同。对于相对稳定的系统,ddd的建模是有效的,对于变化速率高的部分,ddd建模会额外的增加成本和复杂程度,而它本身在付出高成本后旋即被抛弃,适用ddd的策略会十分荒唐。

中台三问:

中台与平台不同在于,平台是对业务流程的封装,抽象的是个别能力和技术能力。中台试图抽象业务模式或业务流程,在不同前台需求中抽象公共服务模块,避免成为大后台。它需要开发者思考和抽象企业依靠什么做业务,什么样的业务在驱动各个模块运转。

1.如何避免中台成为一个单点,以至于中台瘫痪导致系统瘫痪

中台没有必要按单点部署,也不需要所有前台访问相同实例。完全可以是相同的逻辑,分离的部署。复用的只是抽象的能力。

2.中台实现前台的定制需求与中台实现通用需求的矛盾如何解决

中台开发者思维的出发点是我是什么,而非你是什么,你有什么需求需要我满足。观察前台业务的目的是给自己找到主体性。

3.中台在企业结构中,会给it与业务的合作带来怎样的冲击和影响

康威定律:线型系统和线型组织架构间有潜在的异质同态特性。成立服务中台的组织架构会带来中台和前台的张力,但这不是问题,会帮助中台服务找到边界,达到平衡。

微服务拆分粒度:

对于单体应用,业务高峰到来时,各个业务部分有不同的弹性需要,单体的扩展不能支持这一点。以部署需要为微服务边界拆分,符合微服务设计的最初目的。微服务架构是在云原生时代,把弹性放在核心地位的架构。有时也基于发布周期解耦的考量,会拆分微服务。

对于通常被认为的微服务能提供服务重用功能来说,实际上不存在计算的重用的瓶颈,往往带有数据和逻辑的内容是需要重用的。所以无服务并不是微服务的趋势,它们是不同的。复用是一个潜在的收益,而非明确的收益,不应该以复用作为拆分微服务的原因。

基于细胞特化的架构思想,也可以制造相同的单体部署,通过其所处位置的不同,发挥不同的功能,并且通过定制网关解决弹性的问题。这样做方便功能的延续和复用,解决一部分cap和代码架构层面遇到的困难。也侧面说明了,微服务不是越微越好。

领域逻辑与运维逻辑:

业务逻辑分为领域逻辑和运维逻辑,领域逻辑是通用的,与具体公司的运作无关的,与所处行业地区等有关。企业谈业务需求一般没有领域概念,而是提软件的运维逻辑。所以市场上软件定制也有两个思路,一个是要求企业适应软件的运维逻辑,做对应组织调整;一个是软件存在通用功能,定制运维逻辑,也会要求企业适应,但程度会低。今天的环境下,无法抛开运维逻辑谈领域逻辑,设计软件的时候要多做相关思考。

DDD遇到业务系统,还是最佳实践么:

领域的复杂度和业务的复杂度不是同一维度的问题,DDD提出时,系统多是在领域的维度复杂,目前的多数系统主要复杂度在业务方面。对业务的抽象会体现在中台,而不是领域中。所以当遇到业务复杂度高的系统,不应当首选DDD,直接开发会更好。

软件开发管理为什么这么难:

主要是因为惯性的才用了软件行业发展之前的管理实践和方法,没有认识到软件管理的实质。

1.团队中存在角色和分工的原因:

出现社会分工会产生职业角色,在充分商业交换的社会,职业角色之间的比较优势天然的提高整个社会的效率。本质上是一个资源重新配置的问题,但前提是存在对产出结果物的交换。

2.软件开发和交付的过程实质:

实质是知识生产、消费和传递。从业务方,到需求分析者,到开发者,实际这样看待问题比当做生产产品的过程更接近实质。生产产品的分工要求知识壁垒越高,效率越高;而开发之间知识壁垒越高,效率越低。比如DDD就是在用统一语言降低知识壁垒。

划分知识边界提高团队效率:

基于上一个问题的回答,分工产生了专业性,想要提高团队的效率,需要能产出物能够黑盒复用——不需要了解内部细节,这样提高知识壁垒增加效率。所以管理者要思考能不能在团队内找到黑盒复用的知识背景。比如DDD中限界上下文拆分,而不是横向分层——展示层,服务层,持久层然后团队内分配。因为分层后各层次间仍然是白盒的,知识不但要学习,还要沟通同步。只有在知识边界的划分团队职责,才能带来效率提升。这也同样适用于微服务划分时候的思考,虽然按照业务划分是可以的,但划分后有没有获得微服务划分的好处,有没有促进黑盒复用。而在一个知识边界之内,消除知识壁垒有利于提高效率。需求分析者写需求,如果没有开发者消费,他的效率是0。在知识边界内,应当通过知识传递的效率来衡量团队的效率。

云计算是一个远远被低估的技术:

云计算兴起深刻改变了软件,但仍然是一个远远被低估的技术,因为它挑战了我们的概念和想法。不同团队有不同的研发流程,很难统一成一致的,根本原因是资源不易获得。软件团队会为了适应环境而改变交付节奏,流程差异本质是环境差异。云计算兴起后,资源变得易获得,我们可以用变化的环境统一流程。首先受到挑战的是devops流水线,它的核心思想是代码在交付流程之间流动,它的前提是环境不变,代码迁移。原因在于环境不易获得,代码便宜。目前来看,流水线是否还是最佳实践,还需要时间检验。与它对应的一种环境提升的机制也已经走进了大家的视野,它对于dev环境的制品直接提升为uat来完成开发流程的流转。

无法被996管理的知识工作者:

根据泰勒的观点,传统的管理关注的是对产出物和工作时间的管理。软件开发中,宏观产出有效性是上层制定计划时决定的,而微观产出的有效性都是由消费侧决定,管理者想实现有效管理比较困难,验证工作产出的效果的反馈周期太长。管理工作内容对于知识工作者不适用,因为大部分工作是在头脑中,开始动手的部分是小部分的工作。所以管理工作时间是管理者唯一可行的管理手段。本质上,996蔚然成风的原因在于没有好的方法论管理知识工作者。

有一种现存的实践是通过缩短产出物验证的时间周期,来通过管理产出物。往往要求代码更快速上线,和更快速的处理线上问题。这就是所谓互联网研发模式。由于无法管理工作内容,企业往往采取胜任力培养的方法,让员工更有效率。这样,管理产出变为缩短开发周期,管理内容变为胜任力、能力、学习力培养,管理实践转化为996,形成了新的管理三角。这样管理者有更多的管理空间,而不是只能通过996解决问题。

端到端交付:

最初对于敏捷开发,前后端分离是反模式,因为没有独立知识边界,产出物不是独立的交付物,会产生额外的知识同步的成本。由于知识结构的发展,后端不再是行业内认识的数据库表,而是发展为微服务,它代表企业的能力。能力相对稳定,而用户体验和业务会变化较快。通过能力构建知识边界,企业可以形成闭合的明确的知识边界,形成端到端交付。通过bff形成对前端的端到端交付。由于行业内出现大量正确划分的前后端的端到端交付,所以这个内容成为正向的良好的开发模式。所以具体的团队的前后端分离做得对不对,主要是看知识边界的现状,产生了怎样的端到端交付。

同样道理,渐进式增强也是在产生独立知识边界基础上,分离用户交互和数据的开发管理实践。

为什么绝大多数组织都是金字塔结构:

泰勒实验的传统观点认为,管理者应该有两种,一种决定什么是对的,一种决定怎么做事情是有效率的。第一种人很少,第二种人较多,最多的是具体工作执行的人。这种结构叫金字塔结构,我们认为这是一种单纯官僚结构。因为它试图通过标准化流程和解决方案解决问题,它擅长在不需要创新力,只有已知问题的企业中搞管理。这种管理模式的假设就是需要处理的问题绝大部分是已经发生过的、有预案的问题。

从单纯官僚组织到技术官僚组织:

单纯性官僚组织起来的企业会存在大企业病,表现的僵化。当行业的当前情况已经被企业理解——企业认知能力较高,单纯性官僚的组织是没有问题的。当行业产生变化,且变化没有被企业掌握时——企业认知能力较低,单纯性关联组织就有问题。这时需要技术官僚组织来管理,管理者本身是技术专家,他能吸取行业内已有技术方案,解决较复杂的问题。这意味着企业定位它要面对的管理问题主要不是已有预案的问题,而是主要面对新的问题,但可以通过对已存在技术方案的了解来解决问题。

组织架构与认知模型:

认知模型中,复杂度:混沌>复合>复杂>明显。不同的时期和情况,企业会面临不同的问题,对企业的提出不同的挑战和要求。一般情况下,企业应建立应对复杂情况的组织架构。回顾可以帮助企业把复合降级为复杂问题。回顾可以帮助组织认识哪些做得对,哪些做得不对。标准化和自动化可以帮助企业把复杂问题转化为明显问题。在维护和消亡期,绝大多数问题都是明显问题,单纯官僚组织可以应对。

估点的正确姿势:

当估点追求准确的时候,会发现要得出某一个结果,需要前置条件一个或多个都满足,而没有满足时,估点就不成立。这样的估点是脆弱的,依据它形成的方案也是脆弱的,所以有可能得到精准而脆弱的计划,也可能得到强壮而不准确的计划,后者显然更有价值。

管理者要求估点准确,实际要求的是两个方面:1.单位时间内最大的输出,即确保员工有效的利用了时间。2.在时间的下限内完成任务,保证功能成本的同时节约了管理成本。所以管理者可以采取这三个方案:1.不估点,以故事的个数作为工作量,这是基于实际工程经验——同一个团队点数和故事数基本是线性的。2.确认下限,算出一个故事需要的平均时间,要求开发者提供可以完成的故事的个数,如果超过风险控制的比例,则拆分故事到更细的程度——平均时间会减小,再次要求开发者估算可以单位完成的比例,直到比例达标,认为风险可控。3.上限管理,关注未在上限时间内完成的故事,进行总结归因,一般只有两种原因,人员能力不足或需求理解错误。再针对这两种情况进行干预和改进。

 

*来自对八叉说栏目内容的笔记

展开阅读全文
打赏
2
15 收藏
分享
加载中
更多评论
打赏
0 评论
15 收藏
2
分享
返回顶部
顶部