蛋式编程(Egg-Style Programming)与业务内设计与组件式编程(Component-Style Programming)（下篇）

@

目录

§1 前言

参考资料
本文承接以前的帖子梳理，相关内容如下

前言概述
本帖上篇中提出了一个比较普遍的现象
成长-健康困境：是指强制业务需要发展的前提下，项目的业务一定程度上的增加导致项目可维护性更大程度的降低，并且这种现象只能削弱不能根治的困境。

基于这个现象，出现了一种比较普遍的研发模式
蛋式编程(Egg-Style Programming)：即成长-健康困境（下文简称为 GHD）中研发人员的不完备研发的编程(研发)模式。同时若项目暂时未陷入困境，但随时间推移有能力导致出现的也可以定义为蛋式编程（下文简称为 ESP）。

§22 我们希望避免 ESP

§2.1 ESP 的成因

ESP 的成因，几乎可以归结为 持续性的不完备开发。不完备开发会造成不宜修复的坑，在填坑的过程中持续不完备开发导致坑的积累，最终两遍引起质变，导致团队不得不持续进行不完备开发，循环反复。

不完备开发 的成因有很多

  • 时间紧任务重
  • code review 形同虚设或压根不存在
  • 需求本身就有问题
  • 人员流动频繁，所以谁都不知道项目里的完整内容
  • 项目过于久远，迭代过于混乱，神代码迭出

但即使将上述问题全部扫平，光大研发人员也不得不承认：我们几乎还是不能避免不完备开发
这是因为不完备开发的根本成因可以概括为——设计缺失

设计缺失又可以概略的分为两种场景

  • 设计忽略：完全没有设计，研发过程直接跳过设计这个阶段
  • 设计寸止：有设计，但设计得将将好满足当前业务，完全没有前瞻性或前瞻性不足而导致不能容纳业务迭代
  • 设计过期：有设计且设计质量很高，但实在太久远或业务重大突破重构以致于“寿终正寝”式的不能满足当前业务

上面罗列的不完备开发众多成因，几乎都是因为促发了设计缺失导致不完备开发，进而腐化项目的

§2.2 避免 ESP 的思路

整体思路
既然造成 ESP 的根本成因是 设计缺失，那避免 ESP 的大思路肯定就是 落实设计
但这个问题既然还是问题，那一定没有这么简单

首先，以充分设计为前提的假设
下面的蓝图是努力的方向，但一定不能寄希望于存在这样的乌托邦

  • 经过一段时间的学习或熟悉，我们大约知道项目中几乎所有类和接口的脉络
  • 标识符命名良好，我们可以见文知意
  • 逻辑具有明显的套路，我们看懂了一个点，就能顺带看懂一片
  • 具有足够稳定的接口，所以功能总是方便扩展和迭代的
  • 没有神代码，我们总是可以比较轻松的理解目之所及的一切
  • 我们总是可以通过少量的工作，通过统一修改的方式完成看似复杂的功能点
  • 业务线之间不耦合，只要有时间和精力，本项目没有我们不能改的地方

我们不难发现，如果上述情况真的达成，那么之前总结的问题或者不会出现，或者即使出现了也不会造成什么问题

  • 我们可以很轻松的看懂项目，并沿用原有设计进行快速高质量迭代（这才是真正的敏捷开发）所以无所谓时间紧任务重
  • 人员流动再频繁、项目历史再悠久，只要项目质量不受影响，就都与当前研发人员无关
  • 良好的设计会引导研发和产品从更上层（宏观）的层面分析问题，需求会更健壮，也更容易发现与补正本就降低了出现概率的问题需求
  • 实现落地会更简单，在研发人员水平及格的前提下，code review 可以降级成设计评审

其次，==

为什么会有设计寸止
设计寸止的出现无外乎两种原因

  • 设计力度不够，没有前瞻到一定的程度导致设计没有达到应有的效果
  • 害怕出现过度设计，因此对设计进行了收束，收的劲大了
posted @ 2025-05-20 15:09  问仙长何方蓬莱  阅读(10)  评论(0)    收藏  举报