"屎山代码"是怎么炼成的
屎山代码一直都是被软件行业的大多数人诟病。它是指堆积在一起没有规律的都不想去看的一堆代码。这些代码能运行，却不能迭代，效率不高，却又不能舍弃，所以形成了你不得不关注的内容。本人是一名有着代码洁癖的开发人员，从入行第一天只要看见任何不好的代码都会想去优化掉。同时我也尽量去读懂前人的想法，总结出屎山代码形成的几个关键原因：
- 项目初期没有架构规划，缺乏架构设计，包括业务架构和技术架构(不考虑业务架构的技术架构设计最终都会演变成扯淡)
- 项目中期形成业务规模后，只考虑业务迭代，不考虑技术的扩展性，导致最后技术不更新，业务开发繁杂
- 技术团队的建设不体系化，很多团队在初期和中期的时候没有优秀的技术人员，团队技术氛围落后，核心技术人设计能力短缺，导致系统的能力也比较匮乏
- 产品技术认知不完整，不统一，就是对于自己要做的系统和体系产品很多产品技术测试人员都没有清楚的认知，导致在开发过程中上线的项目的好坏都没有概念
- 团队核心人员缺乏架构思维，架构思维可以帮助我们认识事物本来的样子，如果没有这种思维去工作的话，那么在面对已经堆积如山的代码时候，会是一脸懵。
从以上原因，其实大多数是团队和团队核心成员的问题较多。屎山代码的形成不是某一个人导致的，是团队长期无规则开发形成的。要避免的话就需要团队的建设和核心人员的培养。
优化代码的关键步骤
屎山代码大都是有价值的。对于没有价值的，要么不用更新，要么可以直接废弃掉。不用废心。对于各种各样的系统，各种各样的代码所面临的问题也是不一样的。本人根据自己的多年重构项目和优化项目的经验总结以下步骤：
一、深入了解业务价值
很多人都会吐槽别人的代码烂，但是当你问他这个代码应该怎么优化？很多人都说不出所以然。只是觉得代码不易读懂，不好维护，就是差。如果只是这样的程度，那么可以想象在几年之后你的代码几年之后同样也会被别人给出这样的评价。导致这些的关键症结点之一就是没有深入了解业务价值(除此之外个人技术能力也是重要的)。
业务价值决定了你在对应的业务模块投入的心力，写的代码行数。还有所需要保留哪些可扩展等等。对于一些没有关键业务价值的代码，也没必要做过多优化，只要完成了功能。
业务价值是我们做软件项目的终极目标。了解业务价值，才能确定最终的方向，去往哪个方向优化。如果没有目标，只是为了技术优化代码那么很多时间花费没必要，因为最终没有足够的价值输出。
二、分析原业务架构和技术架构
在深入了解业务的过程中，重点去分析原来的业务架构和技术架构也是很重要的。在这个过程中要对原有的业务场景，业务功能，业务能力，业务元素等内容进行一个全局的抽象化理解。并勾勒出原有的业务架构，同时也要弄清楚原来的技术架构。
随着技术的迭代，各种系统的实现也会有很多选择，针对同样的功能，用不同的技术实现，难度和业务应用能力都会有差别。比如消息事件，数据库，缓存等，这些实现有很多。实现方式不一样，所面对的问题也不一样。这个在做技术架构代码优化的时候也在考虑范围之内。
三、设计新业务架构和技术架构
在了解已有的业务体系和业务架构技术架构之后，要做代码优化，那么我们就需要重新对这个业务架构和技术架构基于未来的业务价值体系进行设计优化。新的业务架构有助于我们对原来代码进行重新规划，进行业务模块划分，业务逻辑分层。新的技术架构能帮助我们在尽量不该代码逻辑的情况下去引入新的技术框架体系，从而系统支持的能力更强。
四、代码进行功能分块分级
在进行代码改造规划中我们仍然需要对代码进行功能分块分级。分块主要是基于新的业务架构。分级就主要是基于业务的价值。针对不同情况改造建议优先级如下：
- 业务价值高，业务模块复用率高
- 业务价值高，逻辑可扩展性差，复用性高，可考虑重构
- 业务价值高，逻辑可扩展性差，复用性低，可考虑重构
- 业务价值一般，业务模块复用性高
- 无价值，业务模块复用性高
总的来说优先考虑优化业务模块，同时对于复用高的优先优化。对于复用性差，没什么价值的基本不需要处理。复用性高的代码应及时优化重构。
五、推进优化屎山代码
之前四个步骤都是理论级别的。如果要进行实际优化，在改造代码过程中需要具备的一些能力都是基本必须的。我个人觉得必不可缺的是以下几个方面：
- 读懂代码，需要对各种设计范式和模式代码以及项目源码能读懂分析，调试
- 能对之前的历史代码进行分块，在优化过程中不要急于改逻辑，分块就是把代码拆分成一个个小模块，可以让更多的人一起做优化，拆分过程中主要是提炼结构化的代码风格
- 协同改造，优化过程中如果资源允许下切记闭门造车，需要同其他配合，同时一起优化，自己去主导代码分块，然后大家一起优化协同效率才能提升
完全清楚屎山代码
怎么样才算完全优化屎山代码呢？理论上没有谁能说自己的代码是绝对完美的。大部分代码从技术理论上，从未来扩展能力上都会有提升优化空间，那么什么样的代码可以觉得是可以已经完成系统重构优化完全清楚屎山代码？觉得以下几个标准是必要的:
- 业务扩展点清晰，业务价值已经可以持续提升，
- 可扩展性高，较长时间可快速迭代
- 可维护性高，不易出现故障
- 代码可规范化，可管理