屎山公理：重构屎山与造轮子感想一二

屎山公理：重构屎山与造轮子感想一二

前些日子看了 V2EX 一张帖子，内容如下：真想给自己一耳光，几年前居然是这么烂的水平，目前修改得快要怀疑人生了，把一堆屎山不仅要啃完还要耐心品尝、细嚼慢咽的茫然感觉谁懂。

###类《三体》的基层程序员维护复杂项目的两条公理

• 跑起来是开发的第一要义
• 需求和功能常常变动，但工期与计划学习周期几乎不变

你看，屎山不就出来了吗。

###关于屎山

抛开理论不谈，代码写的烂，维护困难，就会想重构，这是猿之常情。

在我刚接手公司的核心项目时，最直观的感受便是：看不懂。我是写前端的，我们的项目是 Vue 写的，Vue 在设计之初不适合用来写大型项目，我想原因之一是项目变重以后，状态管理单靠组件通信会十分困难。这个项目大改是 17 年启动的，那时候可没有什么 Vuex。

当然还有很多代码写着写着变得很迷，经常出现一个页面近千行代码，本该可复用的组件却有奇奇怪怪的依赖，想把他们拆分开来的念头在一次次报错中打消了，心里油然而生一种想法：刚才我在吃屎，现在我是在切开吃屎。

###接手代码后

一个敏捷开发程序员经常会接手别人的代码，维护，next。这就要求代码必须像积木一样灵活，换言之，你维护的那一块哪怕就此回滚或者删去，也不会对代码整体造成影响。

道理谁不懂呢，但事实上现在几乎国内的项目都是由一坨坨黏糊糊的屎构成的屎山。有时候我是掏粪男孩，有时候我是拉屎的，这种气急败坏的感想真的是在一次次维护祖传项目时得出的。

###关于用轮子与造轮子

有个场景如下：你是员工小明，某天 leader 突然给了一个任务：为当前的项目加入 foo 功能，要求是 bar，限期多长时间完成。同时，leader 温馨提示：Github 上有个项目能嫖来改一改就能用哦。

但是，当你把那个嫖来改一改就能用的项目拉下来，可能会出现以下几种情况：

1. 它真的嫖来改改就能用，遂嫖之
2. 它能跑，但是有很多部分需要改动，且使用的技术栈与你项目一致
3. 它能跑，但是有很多部分需要改动，且与你使用的技术栈不一致
4. 它是屎山，你都不知道怎么让它跑

我们知道，由于工期设限，要想在简短的时间里达成任务，复用轮子是一个屡试不爽的方法（适用于情况 1，2 ）。但如果这个备胎是破的，或者跟你的项目完全不适配，或者因为自己技术力不足无法驾驭（适用于情况 3，4 ），比较之下，是不是造个轮子会更方便呢？

我认为是这样，因为：

1. 你的新轮子可能不是屎山了，因为一个项目之处，谁都不想把它写成屎的
2. 你的新轮子可能会写成屎，但是是自己的屎闻着更香

无论是想法 1 或 2，要是下定决心了，你很可能会去造一个轮子，至少我会。

但是，参考屎山公理，倘若需求是不断变更的（这也是程序员工作时常常碰到的情况），而设计稿 / 项目计划没有提及，又该怎么办？

###如何少写屎山

耦合性与内聚性是模块独立性的两个定性标准，将软件系统划分模块时，尽量做到高内聚低耦合，提高模块的独立性，为设计高质量的软件结构奠定基础。

对外低耦合，对内高内聚

有个例子很容易明白：

一个程序有 50 个函数，这个程序执行得非常好；然而一旦你修改其中一个函数，其他 49 个函数都需要做修改，这就是高耦合的后果。一旦你理解了它，你编写概要设计的时候设计类或者模块自然会考虑到“高内聚，低耦合”。

• 耦合、内聚的评估标准是强度，耦合越弱越好，内聚越强越好；
• 所谓过度指的是由于错误理解导致的效果相反的设计；
• 耦合指的模块之间的关系，最弱的耦合设计是通过一个主控模块来协调 n 个模块之间的运作。还是举一个我举过的例子：客户要求在界面上增加一个字段，你的项目要修改几个地方呢？如果你只要修改项目文档，那么你的开发构架就是最低强度的耦合，而这种设计 成熟的开发团队都已经做到了，他们使用开发工具通过项目模型驱动数据库和各层次的代码，而不是直接修改那些代码； 内聚指的是模块内部的功能，最强的内聚就是功能单一到不能拆分，也就是原子化；
• 所以强内聚和弱耦合是相辅相成的，一个良好的设计是由若干个强内聚模块以弱耦合的方式组装起来的。

引用自： https://leader.js.cool/#/experience/design/architecture

这位大佬的书非常精辟，如果你是一个渴望提升自己或者改善生活的底层程序员，建议可以看一下，不要钱。

（声明：不是广告！不是广告！不是广告！）

##总结

此文是我在一次重构屎山时有感而发，几乎都是抱怨，亦或者是无能怒气。希望大家在今后能够少写屎山，为下一个维护代码的人多着想一下。 如果有啥有用的建议，欢迎分享 QAQ。

-EOF-