其他分享
首页 > 其他分享> > 一个技术总监的忠告:精通那么多技术为何还是做不好一个项目?

一个技术总监的忠告:精通那么多技术为何还是做不好一个项目?

作者:互联网

编写高质量可维护的代码既是程序员的基本修养,也是能决定项目成败的关键因素,本文试图总结出问题项目普遍存在的共性问题并给出相应的解决方案。

1. 程序员的宿命?

程序员的职业生涯中难免遇到烂项目,有些项目是你加入时已经烂了,有些是自己从头开始亲手做成了烂项目,有些是从里到外的烂,有些是表面光鲜等你深入进去发现是个“焦油坑”,有些是此时还没烂但是已经出现问题征兆走在了腐烂的路上。

国内基本上是这样,国外情况我了解不多,不过从英文社区和技术媒体上老外同行的抱怨程度看,应该是差不多的,虽然整体素质可能更高,但是也因更久的信息化而积累了更多问题。毕竟“焦油坑、Shit_Mountain 屎山”这些舶来的术语不是无缘无故被发明出来的。

Any way,这大概就是我们这个行业的宿命——要么改行,要么就是与烂项目烂代码长相伴。就像宇宙的“熵增加定律”一样:

孤立系统的一切自发过程均向着令其状态更无序的方向发展,如果要使系统恢复到原先的有序状态是不可能的,除非外界对它做功。

面对这宿命的阴影,有些人认命了麻木了,逐渐对这个行业失去热情。

那些不认命的选择与之抗争,但是地上并没有路,当年软件危机的阴云也从未真正散去,人月神话仍然是神话,于是人们做出了各自不同的判断和尝试:

很多人把项目做烂的原因归咎于项目前期的基础没打好、需求不稳定一路打补丁、前面的架构师和程序员留下的烂摊子难以收拾。他们要么没有信心去收拾烂摊子,要么觉得这是费力不讨好,于是要放弃掉项目,寄希望于出现一个机会能重头再来。但是他们对于如何避免重蹈覆辙、做出另一个烂项目是没有把握也没有深入思考的,只是盲目乐观的认为自己比前任更高明。

这个派别把原因归结于烂项目当初没有采用正确的编程语言、最新最强大的技术栈或工具。他们中一部分人也想着有机会另起炉灶,用上时下最流行最热门的技术栈(spring boot、springcloud、redis、nosql、docker、vue)。或者即便不另起炉灶,也认为现有技术栈太过时无法容忍了(其实可能并不算过时),不用微服务不用分布式就不能接受,于是激进的引入新技术栈,鲁莽的对项目做大手术。这种对刚刚流行还不成熟技术的盲目跟风、技术选型不慎重的情况非常普遍,今天在他们眼中落伍的技术栈,其实也不过是几年前另一批人赶的时髦。我不反对技术上的追新,但是同样的,这里的问题是:他们对于大手术的风险和副作用,对如何避免重蹈覆辙用新技术架构做出另一个烂项目,没有把握也没有深入思考的,只是盲目乐观的认为新技术能带来成功。也没人能阻止这种简历驱动的技术选型浮躁风气,毕竟花的是公司的资源,用新东西显得自己很有追求,失败了也不影响简历美化,简历上只会增加一段项目履历和几种精通技能,不会提到又做烂了一个项目,名利双收稳赚不赔

还有一类人他们不愿轻易放弃这个有问题但仍在创造效益的项目,因为他们看到了项目仍然有维护的价值,也看到了另起炉灶的难度(万事开头难,其实项目的冷启动存在很多外部制约因素)、大手术对业务造成影响的代价、系统迁移的难度和风险。同时他们尝试用温和渐进的方式逐步改善项目质量,采用一系列工程实践(主要包括重构热点代码、补自动化测试、补文档)来清理“技术债”,消除制约项目开发效率和交付质量的瓶颈。

如果把一个问题项目比作病入膏肓的病人,那么这三种做法分别相当于是放弃治疗、截肢手术、保守治疗。

2. 一个 35+ 程序员的反思

年轻时候我也是掀桌子派和激进派的,新工程新框架大开大合,一路走来经验值技能树蹭蹭的涨,跳槽加薪好不快活。

但是近几年随着年龄增长,一方面新东西学不动了,另一方面对经历过的项目反思的多了观念逐渐改变了。

对我触动最大的一件事是那个我在 2016 年初开始从零搭建起的项目,在我 2018 年底离开的时候(仅从代码质量角度)已经让我很不满意了。只是,这一次没有任何借口了:

于是我意识到一个非常浅显的道理:拥有一张空白的画卷、一支最高级的画笔、一间专业的画室,无法保证你可以画出美丽的画卷。如果你不善于画画,那么一切都是空想和意淫。

然后我变成了一个“保守改良派”,因为我意识到掀桌子和激进的改革都是不负责任的,说不好听的那样其实是掩耳盗铃、逃避困难,人不可能逃避一辈子,你总要面对。

即便掀了桌子另起炉灶了,你还是需要找到一种办法把这个新的炉灶烧好,因为随着项目发展之前的老问题还是会一个一个冒出来,还是需要面对现实、不逃避、找办法。

面对问题不仅有助于你把当前项目做好,也同样有助于将来有新的项目时更好的把握住机会。

无论是职业生涯还是自然年龄,人到了这个阶段都开始喜欢回顾和总结,也变得比过去更在乎项目、产品乃至公司的商业成败。

软件开发作为一种商业活动,判断其成败的依据应该是:能否以可接受的成本、可预期的时间节奏、稳定的质量水平、持续交付满足业务需要的功能市场需要的产品。

其实就是项目管理四要素——成本、进度、范围、质量,传统项目管理理论认为这四要素彼此制约难以兼得,项目管理的艺术在于四要素的平衡取舍。

640?wx_fmt=png&tp=webp&wxfrom=5&wx_lazy=1&wx_co=1uploading.4e448015.gif转存失败重新上传取消

关于软件工程和项目管理的理论和著作已经很多很成熟,这里我从程序员的视角提出一个新的观点——质量不可妥协

3. 项目走向衰败的最常见诱因——代码质量不佳

一个项目的衰败一如一个人健康状况的恶化,当然可能有多种多样的原因——比如需求失控、业务调整、人员变动流失。但是作为我们技术人,如果能做好自己分内的工作——编写出可维护的代码、减少技术债利息成本、交付一个健壮灵活的应用架构,那也绝对是功德无量的。

虽然很难估算出这究竟能挽救多少项目,但是在我十多年职业生涯中,经历的和近距离观察的几十个项目,确实看到了大量的项目正是由于代码质量不佳导致的失败和遗憾,同时我也发现其实失败项目的很多问题、症结也确确实实都可以归因到项目代码的混乱和质量低下,比如一个常见的项目腐烂恶性循环:代码乱》bug 多》排查问题耗时》复用度低》加班 996》士气低落……

所谓“千里之堤,毁于蚁穴”,代码问题就是蚁穴。

接下来,让我们从项目管理聚焦到项目代码质量这个相对小的领域来深入剖析。编写高质量可维护的代码是程序员的基本修养,本文试图在代码层面找到一些失败项目中普遍存在的症结问题,同时基于个人十几年开发经验总结出的一些设计模式作为药方分享出来。

关于代码质量的话题其实很难通过一篇文章阐述明白,甚至需要一本书的篇幅,里面涉及到的很多概念关注点之间存在复杂微妙关系。

推荐《设计模式之美》的第二章节《从哪些维度评判代码质量的好坏?如何具备写出高质量代码的能力?》,这是我看到的关于代码质量主题最精彩深刻的论述。

4. 一个失败项目复盘

先贴几张代码截图,看一下这个重病缠身的项目的病灶和症状:

640?wx_fmt=png&tp=webp&wxfrom=5&wx_lazy=1&wx_co=1uploading.4e448015.gif转存失败重新上传取消

640?wx_fmt=png&tp=webp&wxfrom=5&wx_lazy=1&wx_co=1uploading.4e448015.gif转存失败重新上传取消

640?wx_fmt=png&tp=webp&wxfrom=5&wx_lazy=1&wx_co=1uploading.4e448015.gif转存失败重新上传取消

这里先不去分析这个类的问题,只是初步展示一下病情严重程度。

我相信这应该不算是特别糟糕的情况,比这个严重的项目俯拾皆是,但是这也应该足够拿来暴露问题、剖析成因了。

4.1 症结 1:组件粒度过大、API 泛滥

分层的理念早已深入人心,尤其是业务逻辑层的独立,彻底杜绝了之前(不分层的年代)业务逻辑与展现逻辑、持久化逻辑等混杂的问题。

但是好景不长,随着业务的复杂和变更,在业务逻辑层的复杂性也急剧增加,成为了新的开发效率瓶颈, 问题就出在了业务逻辑组件的划分方式——按领域模型划分业务逻辑组件:

  1. 组件臃肿:Service 组件的个数跟领域实体对象个数基本相当,必然造成个别 Service 组件变得非常臃肿——API 非常多,代码行数达到几千行;
  2. 职责模糊:业务逻辑往往跨多个领域实体,无论放在哪个 Service 都不合适,同样的,要找一个功能的实现逻辑也无法确定在哪个 Service 中;
  3. 代码重复 or 逻辑纠缠的两难选择:当遇到一个业务逻辑,其中的某个环节在另一个业务逻辑 API 中已经实现,这时如果不想忍受重复实现和代码,就只能去调用那个 API。但这样就造成了业务逻辑组件之间的耦合与依赖,这种耦合与依赖很快会扩散——新的 API 又会被其它业务逻辑依赖,最终形成蜘蛛网一样的复杂依赖甚至循环依赖;
  4. 复用代码、减少重复虽然是好的,但是复杂耦合依赖的害处也很大——赶走一只狼引来了一只虎。两杯毒酒给你选!

前面截图的那个问题组件 ContractService 就是一个典型案例,这样的组件往往是热点代码以及整个项目的开发效率的瓶颈。

4.2 药方 1:倒金字塔结构——业务逻辑组件职责单一、禁止层内依赖

问题根源的反面其实就藏着解决方案,只是需要我们有意识的去改变习惯、遵循新的设计风格,而不是凭直觉去设计:

 

4.3 症结 2:低内聚、高耦合

经典面向对象理论告诉我们,好的代码结构应该是“高内聚、低耦合”的:

其实这两者就是一体两面,做到了高内聚基本也就做到了低耦合,相反如果内聚度很低,势必存在大量高耦合的组件。

我观察发现,很多项目都存在低内聚、高耦合的问题。根本原因在于很多程序员,甚至是很多经验丰富的程序员也缺少这方面的意识——对“内聚性”概念不甚清楚,对内聚性被破坏的危害没有意识,对如何避免更是无从谈起。

很多人从一开始就凭直觉写程序,有了一定经验以后一般能认识到重复代码的危害,对复用性有很强的认识,于是就会掉进一个陷阱——盲目追求复用,结果破坏了内聚性。

业界关于“复用性”的认识存在一个误区——认为包括业务逻辑组件在内的任何层面的组件都应该追求最大限度的可复用性;复用当然是好的,但那应该有个前提条件:不增加系统复杂度的情况下的复用,才是好的。

什么样的复用会增加系统复杂性、是不好的呢?前面提到的,一个业务逻辑 API 被另一个业务逻辑 API 复用——就是不好的:

  1. 损害了稳定性:因为业务逻辑本身是跟现实世界的业务挂钩的,而业务会发生变化;当你复用一个会发生变化的 API,相当于在沙子上建高楼——地基是松动的;
  2. 增加了复杂性:这样的依赖还造成代码可读性降低——在一个本就复杂的业务逻辑代码中,包含了对另一个复杂业务逻辑的调用,复杂度会急剧增加,而且会不断泛滥和传递;
  3. 内聚性被破坏:由于业务逻辑被打散在了多个组件的方法内,变得支离破碎,无法在一个地方看清整体逻辑脉络和实现步骤——内聚性被破坏,同时也意味着,这个调用链条上涉及的所有组件之间存在高耦合。

4.4 药方 2:复用的两种正确姿势——打造自己的 lib 和 framework

软件架构中有两种东西来实现复用——lib 和 framework,

lib 库是供你(应用程序)调用的,它帮你实现特定的能力(比如日志、数据库驱动、json 序列化、日期计算、http 请求)。

framework 框架是供你扩展的,它本身就是半个应用程序,定义好了组件划分和交互机制,你需要按照其规则扩展出特定的实现并绑定集成到其中,来完成一个应用程序。

lib 就是组合方式的复用,framework 则是继承式的复用,继承的 Java 关键字是 extends,所以本质上是扩展。

过去有个说法:“组合优于继承,能用组合解决的问题尽量不要继承”。我不同意这个说法,这容易误导初学者以为组合优于继承,其实继承才是面向对象最强大的地方,当然任何东西都不能乱用。

典型的继承乱用就是为了获得父类的某个 API 而去继承,继承一定是为了扩展,而不是为了直接获得一个能力,获得能力应该调用 lib,父类不应该去实现具体功能,那是 lib 该做的事。

也不应该为了使用 lib 而去继承 lib 中的 Class。lib 就是用来被组合被调用的,framework 就是用来被继承、扩展的。

再展开一下:lib 既可以是第三方的(log4j、httpclient、fastjson),也可是你自己工程的(比如你的持久层 Dao、你的 utils);

framework 同理,既可以是第三方的(springmvc、jpa、springsecurity),也可以是你项目内封装的面向具体业务领域的(比如 report、excel 导出、paging 或任何可复用的算法、流程)。

从这个意义上说,一个项目中的代码其实只有 3 种:自定义的 lib class、自定义的 framework 相关 class、扩展第三方或自定义 framework 的组件 class。

再扩展一下:相对于过去,现在我们已经有了足够多的第三方 lib 和 framework 来复用,来帮助项目节省大量代码,开发工作似乎变成了索然无味、没技术含量的 CRUD。但是对于业务非常复杂的项目,则需要有经验、有抽象思维、懂设计模式的人,去设计面向业务的 framework 和面向业务的 lib,只有这样才能交付可维护、可扩展、可复用的软件架构——高质量架构,帮助项目或产品取得成功。

4.5 症结 3:抽象不够、逻辑纠缠——High Level 业务逻辑和 Low Level 实现逻辑纠缠

当我们说“代码中包含的业务逻辑”的时候,我们到底在说什么?业界并没有一个标准,大家经常讲的 CRUD 增删改查其实属于更底层的数据访问逻辑。

我的观点是:所谓代码中的业务逻辑,是指这段代码所表现出的所有输入输出规则、算法和行为,通常可以分为以下 5 类:

  1. 输入合法性校验;
  2. 业务规则校验:典型的如检查交易记录状态、金额、时限、权限等,通常包含数据库或外部接口的查询作为参考;
  3. 据持久化行为:数据库、缓存、文件、日志等任何形式的数据写入行为;
  4. 外部接口调用行为;
  5. 输出/返回值准备。

当然具体到某一个组件实例,可能不会包括上述全部 5 类业务逻辑,但是也可能每一类业务逻辑存在多个。

单这样看你可能觉得并不是特别复杂,但是现实中上述 5 类业务逻辑中的每一个通常还包含着一到多个底层实现逻辑,如 CRUD 数据访问逻辑或第三方 API 的调用。

例如输入合法性校验,通常需要查询对应记录是否存在,外部接口调用前通常需要查询相关记录以获得调用接口需要的参数,调用接口后还需要根据结果更新相关记录状态。

显然这里存在两个 Level 的逻辑——High Level 的与业务需求对应且关联紧密的逻辑、Low Level 的实现逻辑。

如果对两个 Level 的逻辑不加以区分、混为一谈,代码质量立刻就会遭到严重损害:

  1. 可读性变差:两个维度的复杂性——业务复杂性和底层实现的技术复杂性——被掺杂在了一起,复杂度 1+1>2 剧增,给其他人阅读代码增加很大负担;
  2. 可维护性差:可维护性通常指排查和解决问题所需花费的代价高低,当两个 level 的逻辑纠缠在一起,会使排查问题变的更困难,修复问题时也更容易出错;
  3. 可扩展性无从谈起:扩展性通常指为系统增加一个特性所需花费的代价高低,代价越高扩展性越差;与排查修复问题类似,逻辑纠缠显然也会使添加新特性变得困难、一不小心就破坏了已有功能。

下面这段代码就是一个典型案例——High Level 的逻辑流程(参数获取、反序列化、参数校验、缓存写入、数据库持久化、更新相关交易记录)完全淹没在了 Low Level 的实现逻辑(字符串比较、Json 反序列化、redis 操作、dao 操作以及前后各种琐碎的参数准备和返回值处理)。下一节我会针对这段问题代码给出重构方案。

 

@Overridepublic void updateFromMQ(String compress) {    try {        JSONObject object = JSON.parseObject(compress);        if (StringUtils.isBlank(object.getString("type")) || StringUtils.isBlank(object.getString("mobile")) || StringUtils.isBlank(object.getString("data"))){            throw new AppException("MQ返回参数异常");        }        logger.info(object.getString("mobile")+"<<<<<<<<<获取来自MQ的授权数据>>>>>>>>>"+object.getString("type"));        Map map = new HashMap();        map.put("type",CrawlingTaskType.get(object.getInteger("type")));        map.put("mobile", object.getString("mobile"));        List<CrawlingTask> list = baseDAO.find("from crt c where c.phoneNumber=:mobile and c.taskType=:type", map);        redisClientTemplate.set(object.getString("mobile") + "_" + object.getString("type"),CompressUtil.compress( object.getString("data")));        redisClientTemplate.expire(object.getString("mobile") + "_" + object.getString("type"), 2*24*60*60);        //保存成功 存入redis 保存48小时        CrawlingTask crawlingTask = null;        // providType:(0:新颜,1XX支付宝,2:ZZ淘宝,3:TT淘宝)        if (CollectionUtils.isNotEmpty(list)){            crawlingTask = list.get(0);            crawlingTask.setJsonStr(object.getString("data"));        }else{            //新增            crawlingTask = new CrawlingTask(UUID.randomUUID().toString(), object.getString("data"),                    object.getString("mobile"), CrawlingTaskType.get(object.getInteger("type")));            crawlingTask.setNeedUpdate(true);        }        baseDAO.saveOrUpdate(crawlingTask);        //保存芝麻分到xyz        if ("3".equals(object.getString("type"))){            String data = object.getString("data");            Integer zmf = JSON.parseObject(data).getJSONObject("taobao_user_info").getInteger("zm_score");            Map param = new HashMap();            param.put("phoneNumber", object.getString("mobile"));            List<Dperson> list1 = personBaseDaoI.find("from xyz where phoneNumber=:phoneNumber", param);            if (list1 !=null){                for (Dperson dperson:list1){                    dperson.setZmScore(zmf);                    personBaseDaoI.saveOrUpdate(dperson);                    AppFlowUtil.updateAppUserInfo(dperson.getToken(),null,null,zmf);//查询多租户表  身份认证、淘宝认证 为0 置为1                }            }        }    } catch (Exception e) {        logger.error("更新my MQ授权信息失败", e);        throw new AppException(e.getMessage(),e);    }}

4.6 药方 3:控制逻辑分离——业务模板 Pattern of NestedBusinessTemplate

解决“逻辑纠缠”最关键是要找到一种隔离机制,把两个 Level 的逻辑分开——控制逻辑分离,分离的好处很多:

根据经验,当我们着手维护一段代码时,一定是想先弄清楚它的整体流程、算法和行为,而不是一上来就去研究它的细枝末节;

控制逻辑分离后,只需要去看 High Level 部分就能了解到上述内容,阅读代码的负担大幅度降低,代码可读性显著增强;

读懂代码是后续一切维护、重构工作的前提,而且一份代码被读的次数远远高于被修改的次数(高一个数量级),因此代码对人的可读性再怎么强调都不为过,可读性增强可以大幅度提高系统可维护性,也是重构的最主要目标。

同时,根据我的经验,High Level 业务逻辑的变更往往比 Low Level 实现逻辑变更要来的频繁,毕竟前者跟业务直接对应。当然不同类型项目情况不一样,另外它们发生变更的时间点往往也不同;

在这样的背景下,控制逻辑分离的好处就更明显了:每次维护、扩充系统功能只需改动一个 Levle 的代码,另一个 Level 不受影响或影响很小,这会大幅降低修改成本和风险。

我在总结过去多个项目中的教训和经验后,总结出了一项最佳实践或者说是设计模式——业务模板 Pattern of NestedBusinessTemplat,可以非常简单、有效的分离两类逻辑,先看代码:

 

public class XyzService {
abstract class AbsUpdateFromMQ {	public final void doProcess(String jsonStr) {		try {				JSONObject json = doParseAndValidate(jsonStr);				cache2Redis(json);				saveJsonStr2CrawingTask(json);				updateZmScore4Dperson(json);		} catch (Exception e) {				logger.error("更新my MQ授权信息失败", e);				throw new AppException(e.getMessage(), e);		}	}	protected abstract void updateZmScore4Dperson(JSONObject json);	protected abstract void saveJsonStr2CrawingTask(JSONObject json);	protected abstract void cache2Redis(JSONObject json);	protected abstract JSONObject doParseAndValidate(String json) throws AppException;}

 

@SuppressWarnings({ "unchecked", "rawtypes" })public void processAuthResultDataCallback(String compress) {    new AbsUpdateFromMQ() {@Overrideprotected void updateZmScore4Dperson(JSONObject json) {                //保存芝麻分到xyz	            if ("3".equals(json.getString("type"))){	                String data = json.getString("data");	                Integer zmf = JSON.parseObject(data).getJSONObject("taobao_user_info").getInteger("zm_score");	                Map param = new HashMap();	                param.put("phoneNumber", json.getString("mobile"));	                List<Dperson> list1 = personBaseDaoI.find("from xyz where phoneNumber=:phoneNumber", param);	                if (list1 !=null){	                    for (Dperson dperson:list1){	                        dperson.setZmScore(zmf);	                        personBaseDaoI.saveOrUpdate(dperson);	                        AppFlowUtil.updateAppUserInfo(dperson.getToken(),null,null,zmf);	                    }	                }	            }}	@Overrideprotected void saveJsonStr2CrawingTask(JSONObject json) {                   Map map = new HashMap();    	            map.put("type",CrawlingTaskType.get(json.getInteger("type")));    	            map.put("mobile", json.getString("mobile"));    	            List<CrawlingTask> list = baseDAO.find("from crt c where c.phoneNumber=:mobile and c.taskType=:type", map);    	            CrawlingTask crawlingTask = null;    	            // providType:(0:xx,1yy支付宝,2:zz淘宝,3:tt淘宝)    	            if (CollectionUtils.isNotEmpty(list)){    	                crawlingTask = list.get(0);    	                crawlingTask.setJsonStr(json.getString("data"));    	            }else{    	                //新增    	                crawlingTask = new CrawlingTask(UUID.randomUUID().toString(), json.getString("data"),    	                		json.getString("mobile"), CrawlingTaskType.get(json.getInteger("type")));    	                crawlingTask.setNeedUpdate(true);    	            }    	            baseDAO.saveOrUpdate(crawlingTask);}
@Overrideprotected void cache2Redis(JSONObject json) {                   redisClientTemplate.set(json.getString("mobile") + "_" + json.getString("type"),CompressUtil.compress( json.getString("data")));    	            redisClientTemplate.expire(json.getString("mobile") + "_" + json.getString("type"), 2*24*60*60);}
@Overrideprotected JSONObject doParseAndValidate(String json) throws AppException {                   JSONObject object = JSON.parseObject(json);    	            if (StringUtils.isBlank(object.getString("type")) || StringUtils.isBlank(object.getString("mobile")) || StringUtils.isBlank(object.getString("data"))){    	                throw new AppException("MQ返回参数异常");    	            }    	            logger.info(object.getString("mobile")+"<<<<<<<<<获取来自MQ的授权数据>>>>>>>>>"+object.getString("type"));                    return object;	}	}.doProcess(compress);}

如果你熟悉经典的 GOF23 种设计模式,很容易发现上面的代码示例其实就是 Template Method 设计模式的运用,没什么新鲜的。

没错,我这个方案没有提出和创造任何新东西,我只是在实践中偶然发现 Template Method 设计模式真的非常适合解决广泛存在的逻辑纠缠问题,而且也发现很少有程序员能主动运用这个设计模式;一部分原因可能是意识到“逻辑纠缠”问题的人本就不多,同时熟悉这个设计模式并能自如运用的人也不算多,两者的交集自然就是少得可怜;不管是什么原因,结果就是这个问题广泛存在成了通病。

我看到一部分对代码质量有追求的程序员 他们的解决办法是通过"结构化编程"和“模块化编程”:

把 Low Level 逻辑提取成 private function,被 High Level 代码所在的 function 直接调用;

下面介绍一下 Template Method 设计模式的运用,简单归纳就是:

High Level逻辑封装在抽象父类AbsUpdateFromMQ的一个final function中,形成一个业务逻辑的模板;

final function保证了其中逻辑不会被子类有意或无意的篡改破坏,因此其中封装的一定是业务逻辑中那些相对固定不变的东西。至于那些可变的部分以及暂时不确定的部分,以abstract protected function形式预留扩展点;

子类(一个匿名内部类)像“做填空题”一样,填充模板实现Low Level逻辑——实现那些protected function扩展点;由于扩展点在父类中是abstract的,因此编译器会提醒子类的程序员该扩展什么。

那么它是如何避免上面两个方案的 4 个局限性的:

Low Level 需要修改或替换时,只需从父类扩展出一个新的子类,父类全然不知无需任何改动;

无论是父类还是子类,其中的 function 对外层的 XyzService 组件都是不可见的,即便是父类中的 public function 也不可见,因为只有持有类的实例对象才能访问到其中的 function;

无论是父类还是子类,它们都是作为 XyzService 的内部类存在的,不会增加新的 java 类文件更不会增加大量无意义的 API(API 只有在被项目内复用或发布出去供外部使用才有意义,只有唯一的调用者的 API 是没有必要的);

组件依赖失控的问题当然也就不存在了。

SpringFramework 等框架型的开源项目中,其实早已大量使用 Template Method 设计模式,这本该给我们这些应用开发程序员带来启发和示范,但是很可惜业界没有注意到和充分发挥它的价值。

NestedBusinessTemplat 模式就是对其充分和积极的应用,前面一节提到过的复用的两种正确姿势——打造自己的 lib 和 framework,其实 NestedBusinessTemplat 就是项目自身的 framework。

4.7 症结 4:无处不在的 if else 牛皮癣

640?wx_fmt=png&tp=webp&wxfrom=5&wx_lazy=1&wx_co=1uploading.4e448015.gif转存失败重新上传取消

无论你的编程启蒙语言是什么,最早学会的逻辑控制语句一定是 if else,但是不幸的是它在你开始真正的编程工作以后,会变成一个损害项目质量的坏习惯。

几乎所有的项目都存在 if else 泛滥的问题,但是却没有引起足够重视警惕,甚至被很多程序员认为是正常现象。

首先我来解释一下为什么 if else 这个看上去人畜无害的东西是有害的、是需要严格管控的

if else if ...else 以及类似的 switch 控制语句,本质上是一种 hard coding 硬编码行为,如果你同意“magic number 魔法数字”是一种错误的编程习惯,那么同理,if else 也是错误的 hard coding 编程风格;

hard coding 的问题在于当需求发生改变时,需要到处去修改,很容易遗漏和出错;

以一段代码为例来具体分析:

if ("3".equals(object.getString("type"))){          String data = object.getString("data");          Integer zmf = JSON.parseObject(data).getJSONObject("taobao_user_info").getInteger("zm_score");          Map param = new HashMap();          param.put("phoneNumber", object.getString("mobile"));          List<Dperson> list1 = personBaseDaoI.find("from xyz where phoneNumber=:phoneNumber", param);          if (list1 !=null){              for (Dperson dperson:list1){                  dperson.setZmScore(zmf);                  personBaseDaoI.saveOrUpdate(dperson);                  AppFlowUtil.updateAppUserInfo(dperson.getToken(),null,null,zmf);              }          }}

if ("3".equals(object.getString("type")))

显然这里的"3"是一个 magic number,没人知道 3 是什么含义,只能推测;但是仅仅将“3”重构成常量 ABC_XYZ 并不会改善多少,因为 if (ABC_XYZ.equals(object.getString("type"))) 仍然是面向过程的编程风格,无法扩展;到处被引用的常量 ABC_XYZ 并没有比到处被 hard coding 的 magic number 好多少,只不过有了含义而已;把常量升级成 Enum 枚举类型呢,也没有好多少,当需要判断的类型增加了或判断的规则改变了,还是需要到处修改——Shotgun Surgery(霰弹式

并非所有的 if else 都有害,比如上面示例中的 if (list1 !=null) { 就是无害的,没有必要去消除,也没有消除它的可行性。判断是否有害的依据:

如果 if 判断的变量状态只有两种可能性(比如 boolean、比如 null 判断)时,是无伤大雅的;反之,如果 if 判断的变量存在多种状态,而且将来可能会增加新的状态,那么这就是个问题;switch 判断语句无疑是有害的,因为使用 switch 的地方往往存在很多种状态。

4.8 药方 4:充血枚举类型——Rich Enum Type

正如前面分析呈现的那样,对于代码中广泛存在的状态、类型 if 条件判断,仅仅把被比较的值重构成常量或 enum 枚举类型并没有太大改善——使用者仍然直接依赖具体的枚举值或常量,而不是依赖一个抽象。

于是解决方案就自然浮出水面了:在 enum 枚举类型基础上进一步抽象封装,得到一个所谓的“充血”的枚举类型,代码说话:

实现多种系统通知机制,传统做法:

 

enum NOTIFY_TYPE {    email,sms,wechat;  }  //先定义一个enum——一个只定义了值不包含任何行为的“贫血”的枚举类型
if(type==NOTIFY_TYPE.email){ //if判断类型 调用不同通知机制的实现     。。。}else if (type=NOTIFY_TYPE.sms){    。。。}else{    。。。}

实现多种系统通知方式,充血枚举类型——Rich Enum Type 模式:

enum NOTIFY_TYPE {    //1、定义一个包含通知实现机制的“充血”的枚举类型  email("邮件",NotifyMechanismInterface.byEmail()),  sms("短信",NotifyMechanismInterface.bySms()),  wechat("微信",NotifyMechanismInterface.byWechat());      String memo;  NotifyMechanismInterface notifyMechanism;    private NOTIFY_TYPE(String memo,NotifyMechanismInterface notifyMechanism){//2、私有构造函数,用于初始化枚举值      this.memo=memo;      this.notifyMechanism=notifyMechanism;  }  //getters ...}
public interface  NotifyMechanismInterface{ //3、定义通知机制的接口或抽象父类    public boolean doNotify(String msg);     public static NotifyMechanismInterface byEmail(){//3.1 返回一个定义了邮件通知机制的策的实现——一个匿名内部类实例        return new NotifyMechanismInterface(){            public boolean doNotify(String msg){                .......            }        };    }    public static NotifyMechanismInterface bySms(){//3.2 定义短信通知机制的实现策略        return new NotifyMechanismInterface(){            public boolean doNotify(String msg){                .......            }        };    }     public static NotifyMechanismInterface byWechat(){//3.3 定义微信通知机制的实现策略        return new NotifyMechanismInterface(){            public boolean doNotify(String msg){                .......            }        };    }}
//4、使用场景NOTIFY_TYPE.valueof(type).getNotifyMechanism().doNotify(msg)

不难发现,这其实就是 enum 枚举类型和 Strategy Pattern 策略模式的巧妙结合运用;当需要增加新的通知方式时,只需在枚举类 NOTIFY_TYPE 增加一个值,同时在策略接口 NotifyMechanismInterface 中增加一个 by 方法返回对应的策略实现;当需要修改某个通知机制的实现细节,只需修改 NotifyMechanismInterface 中对应的策略实现;无论新增还是修改通知机制,调用方完全不受影响,仍然是 NOTIFY_TYPE.valueof(type).getNotifyMechanism().doNotify(msg);

与传统 Strategy Pattern 策略模式的比较优势:常见的策略模式也能消灭 if else 判断,但是实现起来比较麻烦,需要开发更多的 class 和代码量:

每个策略实现需单独定义成一个 class;还需要一个 Context 类来做初始化——用 Map 把类型与对应的策略实现做映射;使用时从 Context 获取具体的策略;

5. 重构前的火力侦察:为你的项目编制一套代码库目录/索引——CODEX

以上就是我总结出的最常见也最影响代码质量的 4 个问题及其解决方案:

接下来就是如何动手去针对这 4 个方面进行重构了,但是事情还没有那么简单。

上面所有的内容虽然来自实践经验,但是要应用到你的具体项目,还需要一个步骤——火力侦察——弄清楚你要重构的那个模块的逻辑脉络、算法以致实现细节,否则贸然动手,很容易遗漏关键细节造成风险,重构的效率更难以保证,陷入进退两难的尴尬境地。

我 2019 年一整年经历了 3 个代码十分混乱的项目,最大的收获就是摸索出了一个梳理烂代码的最佳实践——CODEX:

640?wx_fmt=png&tp=webp&wxfrom=5&wx_lazy=1&wx_co=1uploading.4e448015.gif转存失败重新上传取消

640?wx_fmt=png&tp=webp&wxfrom=5&wx_lazy=1&wx_co=1uploading.4e448015.gif转存失败重新上传取消

6. 总结陈词——不要辜负这个程序员最好的时代

毫无疑问这是程序员最好的时代,互联网浪潮已经席卷了世界每个角落,各行各业正在越来越多的依赖 IT。过去只有软件公司、互联网公司和银行业会雇佣程序员,随着云计算的普及、产业互联网和互联网+兴起,已经有越来越多的传统企业开始雇佣程序员搭建 IT 系统来支撑业务运营。

资本的推动 IT 需求的旺盛,使得程序员成了稀缺人才,各大招聘平台上,程序员的岗位数量和薪资水平长期名列前茅。

但是我们这个群体的整体表现怎么样呢,扪心自问,我觉得很难令人满意,我所经历过的以及近距离观察到的项目,鲜有能够称得上成功的。这里的成功不是商业上的成功,仅限于作为一个软件项目和工程是否能够以可接受的成本和质量长期稳定的交付。

商业的短期成功与否,很多时候与项目工程的成功与否没有必然联系,一个商业上很成功的项目可能在工程上做的并不好,只是通过巨量的资金资源投入换来的暂时成功而已。

归根结底,我们程序员群体需要为自己的声誉负责,长期来看也终究会为自己的声誉获益或受损。

我认为程序员最大的声誉、最重要的职业素养,就是通过写出高质量的代码做好一个个项目、产品,来帮助团队、帮助公司、帮助组织创造价值、增加成功的机会。

希望本文分享的经验和方法能够对此有所帮助!

zxcodestudy 发布了72 篇原创文章 · 获赞 184 · 访问量 28万+ 私信 关注

标签:精通,getString,项目,忠告,代码,object,技术,逻辑,组件
来源: https://blog.csdn.net/qq_16681169/article/details/104582397