前些日子看了 V2EX 一张帖子,内容如下:真想给自己一耳光,几年前居然是这么烂的水平,目前修改得快要怀疑人生了,把一堆屎山不仅要啃完还要耐心品尝、细嚼慢咽的茫然感觉谁懂。
###类《三体》的基层程序员维护复杂项目的两条公理
你看,屎山不就出来了吗。
###关于屎山
抛开理论不谈,代码写的烂,维护困难,就会想重构,这是猿之常情。
在我刚接手公司的核心项目时,最直观的感受便是:看不懂。我是写前端的,我们的项目是 Vue 写的,Vue 在设计之初不适合用来写大型项目,我想原因之一是项目变重以后,状态管理单靠组件通信会十分困难。这个项目大改是 17 年启动的,那时候可没有什么 Vuex。
当然还有很多代码写着写着变得很迷,经常出现一个页面近千行代码,本该可复用的组件却有奇奇怪怪的依赖,想把他们拆分开来的念头在一次次报错中打消了,心里油然而生一种想法:刚才我在吃屎,现在我是在切开吃屎。
###接手代码后
一个敏捷开发程序员经常会接手别人的代码,维护,next。这就要求代码必须像积木一样灵活,换言之,你维护的那一块哪怕就此回滚或者删去,也不会对代码整体造成影响。
道理谁不懂呢,但事实上现在几乎国内的项目都是由一坨坨黏糊糊的屎构成的屎山。有时候我是掏粪男孩,有时候我是拉屎的,这种气急败坏的感想真的是在一次次维护祖传项目时得出的。
###关于用轮子与造轮子
有个场景如下:你是员工小明,某天 leader 突然给了一个任务:为当前的项目加入 foo 功能,要求是 bar,限期多长时间完成。同时,leader 温馨提示:Github 上有个项目能嫖来改一改就能用哦。
但是,当你把那个嫖来改一改就能用的项目拉下来,可能会出现以下几种情况:
我们知道,由于工期设限,要想在简短的时间里达成任务,复用轮子是一个屡试不爽的方法(适用于情况 1,2 )。但如果这个备胎是破的,或者跟你的项目完全不适配,或者因为自己技术力不足无法驾驭(适用于情况 3,4 ),比较之下,是不是造个轮子会更方便呢?
我认为是这样,因为:
无论是想法 1 或 2,要是下定决心了,你很可能会去造一个轮子,至少我会。
但是,参考屎山公理,倘若需求是不断变更的(这也是程序员工作时常常碰到的情况),而设计稿 / 项目计划没有提及,又该怎么办?
###如何少写屎山
耦合性与内聚性是模块独立性的两个定性标准,将软件系统划分模块时,尽量做到高内聚低耦合,提高模块的独立性,为设计高质量的软件结构奠定基础。
对外低耦合,对内高内聚
有个例子很容易明白:
一个程序有 50 个函数,这个程序执行得非常好;然而一旦你修改其中一个函数,其他 49 个函数都需要做修改,这就是高耦合的后果。一旦你理解了它,你编写概要设计的时候设计类或者模块自然会考虑到“高内聚,低耦合”。
- 耦合、内聚的评估标准是强度,耦合越弱越好,内聚越强越好;
- 所谓过度指的是由于错误理解导致的效果相反的设计;
- 耦合指的模块之间的关系,最弱的耦合设计是通过一个主控模块来协调 n 个模块之间的运作。还是举一个我举过的例子:客户要求在界面上增加一个字段,你的项目要修改几个地方呢?如果你只要修改项目文档,那么你的开发构架就是最低强度的耦合,而这种设计 成熟的开发团队都已经做到了,他们使用开发工具通过项目模型驱动数据库和各层次的代码,而不是直接修改那些代码; 内聚指的是模块内部的功能,最强的内聚就是功能单一到不能拆分,也就是原子化;
- 所以强内聚和弱耦合是相辅相成的,一个良好的设计是由若干个强内聚模块以弱耦合的方式组装起来的。
引用自: https://leader.js.cool/#/experience/design/architecture
这位大佬的书非常精辟,如果你是一个渴望提升自己或者改善生活的底层程序员,建议可以看一下,不要钱。
(声明:不是广告!不是广告!不是广告!)
##总结
此文是我在一次重构屎山时有感而发,几乎都是抱怨,亦或者是无能怒气。希望大家在今后能够少写屎山,为下一个维护代码的人多着想一下。 如果有啥有用的建议,欢迎分享 QAQ。
-EOF-
这是一个专为移动设备优化的页面(即为了让你能够在 Google 搜索结果里秒开这个页面),如果你希望参与 V2EX 社区的讨论,你可以继续到 V2EX 上打开本讨论主题的完整版本。
V2EX 是创意工作者们的社区,是一个分享自己正在做的有趣事物、交流想法,可以遇见新朋友甚至新机会的地方。
V2EX is a community of developers, designers and creative people.