本人程序员一枚,有从0到1做过项目,也有接受其他人的项目继续修补的。但即使是自己从0到1的,到最后都是修补的工作,这样在多人同时修补且日积月累下,软件会越来越臃肿,越往后越乱,好多代码即使最开始是你写的都不好改动,特别痛苦,尤其是修补别人的项目的,我想好多朋友都有这感受吧。
现在我想请教下有此方面经验的大佬,从大到架构框架、人员分责,到小的代码规范等各个方面都可以聊,想知道到底怎么能很好的减轻垒砖的现象,多谢
没人敢无顾及的重构代码,所以只能堆新代码,打工的没必要给自己惹麻烦。
好的架构都是不断演化出来的,好的代码都是不断重构出来的。
但这都是理想状态,如果项目是你独自开发或者你是主导者的话,可以有此追求。
实际工作中,迫于各种原因,维护的基本原则就是“以前的代码就是一坨屎,只要客户没有闻到味,那就让它留着”。
项目的复杂性往往不是技术本身,而是在于由于实现者的水平参差不齐,思想百花齐放,每个人对架构或者设计的理解不同等因素造成的难以理解或者不合理但能用的具体实现。
“大胆”的改动一方面可能会落入之前某个前辈的坑,造成新的未知的问题。另一方面,改动意味着测试,测试意味着时间人力,间接地增加了维护成本和周期。
基本上,随着代码的不断堆积,使用的技术被淘汰,软件维护个十年八年,就需要全盘重写/重构了。
所以,做好在自己维护的窗口期的事情,就问题解决问题,不吐槽不纠结,克服完美主义心理,剩下的交给未来的继任者吧。
DDD
领域驱动设计
领域、子领域、子子领域……
聚合
聚合根类
值对象
……
Istio 服务网格
能否简要说下这几个针对解决的问题啊,大侠
@卡萨丁·周: 这些是方法论,要自己试验下,亲身体验下,,
如果是一个新的项目 你可以规划好 但如果是新项目 我估计你不会又这个问题 你既然来问了 说明你遇到屎山了 所以你的问题是 遇到屎山怎么办吗?
局部重构,大胆假设,小心求证,先多理解这么写的原因,一般的屎山能跑,是很难改的,每次该需求的时候优化几行代码,或者一个方法,这样会渐渐的好看一些,然后对业务了解的多了,可以动作稍微大一点,这样可以延长软件生命周期,不过对于那些根本性的设计问题,很难处理,基本无解
很好的问题!为了减轻代码的复杂度和提高代码的可维护性,我们可以采取以下几个措施:
设计良好的架构和模块化代码
在项目初期,需要花费时间设计好整个系统的架构,分析系统中的各种业务需求,确定系统中的各个模块和组件,并把它们分解成更小的可重用的部分。这样做的好处是可以减少不必要的代码耦合,提高代码的可维护性和扩展性。在模块化的过程中,可以采用一些设计模式,比如工厂模式、单例模式、观察者模式等来达到代码解耦的目的。
代码规范和注释
在编写代码时,应该遵守一定的代码规范,包括变量、函数、类的命名规则、代码缩进、注释规范等。这样可以让其他人更容易理解你的代码,减少出现歧义的情况。在代码中添加注释也是非常重要的,可以让其他人更快地理解你的代码,减少维护的难度。
使用版本控制工具
使用版本控制工具,比如Git,可以帮助我们管理代码的版本。每次对代码的修改都会有一个记录,这样可以方便地回滚代码或者恢复到某个版本,也可以避免不同人修改同一份代码引发的冲突。
代码复审
代码复审可以帮助我们发现代码中的潜在问题,包括代码风格、逻辑错误等,提高代码的质量。可以选择一个固定的时间段进行代码复审,也可以在提交代码之前进行代码复审,这样可以尽早发现问题。
测试驱动开发
测试驱动开发(TDD)是一种先写测试用例,再编写代码的开发模式。这样可以确保代码的正确性,避免引入不必要的代码。
持续集成
持续集成是一种将代码频繁地集成到主干上的方法,每次集成都会触发一系列的自动化测试。这样可以避免不同人编写的代码之间出现冲突,也可以及时发现代码中的错误。
现在很多平台支持插件开发,不同客户挂不同插件,插件可以随时重写替换