前端项目如何避免/解决因功能堆积导致的代码越来越烂的问题

重构这本书都多少年了。。。
唯一的办法就是在基础架构设计不太落后的前提下不断重构。
但硬性条件就是组里有个权力足够大可以怼掉不合理需求的技术领导。

通病。祖传代码谁接手谁倒霉

能用就行：）

@workg 头大

@bojackhorseman 这么想确实烦恼少了好多哈哈哈

@Mithril 之前的 leader 也是比较温柔的人，不太会刚需求，现在 leader 走了 我又没话语权技术还一般，难搞哟

@kop1989 的确是 现在都很随意，没有系统的规范 人力也不够

跳槽, 把锅甩给其他人

这才是看能力的地方，软件工程的能力比用什么新技术之类的重要多了，推荐一本 https://book.douban.com/subject/35006892/ ，我挺赞同这里面的挺多想法的，很多自己也实践过。

1. ETC （ Easier to change ），书里强调是一种价值观，我觉得也是，而且是最重要的一条，所有的事情从设计的时候就得考虑，他是否易于变化。做每一个决定也都要考虑，这个决定是否能做到易于变化，这样落实到代码的时候我们就会拆分的更清楚。

2. DRY (Don't repeat yourself)，这个我最初的理解其实是浅见，只是想如果能自动化的就不要手动，这本书里给的了启发，避免重复其实就减少了维护的难度，特别是代码逻辑里面，这会让我们意识到，我们可以把逻辑拆分的更细，更易于变化，然后通过组合来去呈现复杂的逻辑。

3. 正交性，如果能设计成完全不相干的系统就尽量不要有关联，消除不相关的事物之间的联系，这个最近有体会，因为一些原因我们很难做 SSO，所以我们的 portal 提供给各级子项目 token，而这其中还传递了其他的 profile 信息，其结果就导致了其他的系统出了问题，一直找不到原因，结果发现是 profile 信息因为某些权限问题传空了，结果就成了跨系统的问题，所以设计的时候一定要尽量做到正交。

4. 封装，组件化，前端现在已经很容易能做到组件化，特别像 react，组件化是常态，重要的是如何能在多个系统 share，如何能够更方便的提出组件，提取出公用 utils，这个很推荐 monorepo 的方式组织代码，我们可以很方便的在一个项目里很容易的拆分出相应的公共部分，组件，逻辑，工具等等，可以结合 nexus3 这样的私有代码仓库，做到多个项目的 share

5. 领域模型，构建前端的领域模型，只用通过稳定的模型去映射组件才能有更好的维护性，设计好领域模型后我们可以把后端的 api 映射到领域模型，然后前端的领域模型去映射组件，当然最好的办法是直接上 GraphQL.

6. code review，以上所有的东西都需要 code review 去统一和实践以及监督，这是落实这些东西最重要的一部，否则每个人都有不同风格，当然我们做的更多一些，比如通过 Prettier，以及 eslint 去定制一个我们的规则，通过 SonarQube 去看代码质量等等。

解决方案就是招高水平的人。低水平造成低质量代码是应该的，是必然的。因此造成的开发时间越来越长，动不动就得推倒全部重写，是企业应该付出的代价。

@ianva 本人目前的确是缺乏组织架构方面的能力以及工程思维，感谢老哥指导以及推书

@ChefIsAwesome 组里确实缺少技术主心骨，感觉领导招人好难啊，很久了还是没什么动静

跟我这情况差不多 不过我这是没办法 业务逻辑太复杂 各种联动和判断在前端 一个页面 1000 多行 JS

@wyz123723 也算是注入了一年时间的代码，还是想拯救拯救

@yaphets666 我这边是业务越来越复杂，有一些后端不知道什么原因组织不了的数据也要放在前端去组织处理，尽管会对前端质量和性能有很大的影响

6 年之内，前端框架已经被推倒重来了很多遍了。你觉得有人能答好这个问题？

一个字：钱

如果有钱大可以多招人，放宽开发工期，规范代码合并、review 流程

但是资本本质就是最小的成本获得最高的利益

所以这就是个伪命题，我反正已经能完全接收屎山并能面不改色的继续往屎山上堆屎

@revalue 不能完全解决 学习学习怎么优化也是可以的吧

@dilu 哈哈哈哈我继续堆屎了

@sybb 一样的 我这也是 很多数据后端取不了 有关树形统计的什么之类的 我不懂 sql 和 java 所以我也说不上话 哎...

@sybb #20 剩下一些具有共性的东西，做局部优化

SonarQube

成本问题。 要不断的根据业务重写封装 代码，工时紧张的话只能往硬堆了。

跳槽是唯一出路，换一坨新鲜的屎

分明是态度问题，一个代码洁癖程序员在正常情况下绝不可能写出 shit 一样 代码

js 代码没有 namespace 之类的也挺麻烦的，只能把 package 当作 namespace 来用，把代码按照包来分隔整理，不过管不好的话又是依赖地狱了

@kop1989 我的办法是，每次随新功能上一小部分重构。重构不需要大刀阔斧地去改，有时候只是改个变量名或者把代码简化个几行或者提取了新的方法和函数也可以算重构。反复几次的话可以大致达到比较理想的效果。关键在于领到新需求的时候对任务难度的评估，将这次完全不重构的任务量和小批量重构加上以重构后的做法的任务量比较，看看怎么做最合适。
重构的目标是：下次新需求来的时候比较容易完成新的需求。如果新需求来了需要大改，那本身说明结构不好，就是需要重构的

@ChanKc 重构最主要的问题是，可能带来 bug，带来的 bug 的锅由谁来背？

@sighforever 担心背锅就不要改了呗，又不是不能用

想起我司 6000 行的单文件 js 源码,闻者落泪

建议阅读 code complete 和 重构 （ js 版本）

@redbuck 超 300 就应该反省了～

@azcvcza 好的 感谢

@redbuck 我司项目以前有 10000 行的 cpp，后面直接重写了

楼主, 如果你公司是 955, 你可以考虑一下重构, 解决技术债之类的问题. 如果天天 996 的话还是算了. 继续往上堆功能呗, 堆不动了就多招人继续硬怼. 反正都要 996, 不管是屎山还是架构简洁优美在老板那里都是一个样. 而且怕屎山还能营造出你很忙的假象+多招几个人, 增加你们组的话语权.

@littlecreek 大半夜了还帮忙出主意 感谢感谢，我会好好考虑一下是不是要进行重构了