V2EX = way to explore
V2EX 是一个关于分享和探索的地方
现在注册
已注册用户请  登录
qinrui
V2EX  ›  程序员

怎么避免自己写的代码变成屎山?

  •  
  •   qinrui · 68 天前 · 9009 次点击
    这是一个创建于 68 天前的主题,其中的信息可能已经有所发展或是发生改变。
    118 条回复    2022-11-30 10:30:32 +08:00
    1  2  
    singerll
        1
    singerll  
       68 天前   ❤️ 8
    不写代码
    salmon5
        2
    salmon5  
       68 天前   ❤️ 1
    不做 KPI ,不领工资
    Kirdoyz
        3
    Kirdoyz  
       68 天前
    避免不了,多适应,习惯就好
    yytbob
        4
    yytbob  
       68 天前
    很难,因为熵总是在增涨。
    god7d
        5
    god7d  
       68 天前   ❤️ 3
    技术层面

    1.架构设计科学,有前瞻性

    2.规范自己的代码习惯,写好注释(但不是滥用注释

    项目层面

    1.有一个不那么心急的老板或者领导
    vevlins
        6
    vevlins  
       68 天前
    1. 做需求硬气些
    2. 在演化完全前撤离
    akakidz
        7
    akakidz  
       68 天前   ❤️ 1
    赞同楼上,好的代码依赖于好的项目,如果你们的产品不断的推翻迭代,并且给的工期不够,发展成屎山是必然的
    fiypig
        8
    fiypig  
       68 天前
    能跑就行,管他的
    raysonx
        9
    raysonx  
       68 天前   ❤️ 3
    coderxy
        10
    coderxy  
       68 天前
    定期重构
    lookStupiToForce
        11
    lookStupiToForce  
       68 天前   ❤️ 7
    没有人可以永远当先知
    所有人都是盲人摸象
    所有人都只有有限理性

    所以唯一的办法就是定期梳理业务,定期总结新方法、新框架,定期重构
    leonshaw
        12
    leonshaw  
       68 天前
    @lookStupiToForce 只开新坑,定期跑路
    thulof
        13
    thulof  
       68 天前
    没办法,只能多写多看,不停的学习
    wu67
        14
    wu67  
       68 天前   ❤️ 1
    我同意重构, 但重构不应该是定期的, 应该是持续性的小范围重构.

    重构本身不产生新功能、不完成新需求、不带来业务产出, 但却耗费开发人员大量精力, 你觉得项目周期允许你这么折腾?
    这玩意只能夹在新功能开发期间不停的小范围进行, 看到有不够好的就及时调整.
    llsquaer
        15
    llsquaer  
       68 天前
    个人觉得 写好注释 就可以避免一大片乱码

    注释需要有 为什么有这段代码,适用范围和可能的意外

    别嫌啰嗦, 回过头几个月看依然知道这个是干嘛的
    virus94
        16
    virus94  
       68 天前
    哈哈,每当我想避免屎山一样的代码时,项目总会加急的.
    LaGeNanRen
        17
    LaGeNanRen  
       68 天前
    让你老板多花高于你两倍工资的钱,再招一个架构进来 :D
    luzemin
        18
    luzemin  
       68 天前
    持续重构,别无他法
    holy_sin
        19
    holy_sin  
       68 天前
    最基本的避免大类 大函数,估计可以消灭 90%的屎山了;而现实是老板觉得这些并没有收益,所以别做了,除非老板觉得有必要。
    kongkx
        20
    kongkx  
       68 天前 via iPhone
    轮回
    fkdog
        21
    fkdog  
       68 天前
    哪怕你代码写的再好,屎山终归是我们最终的去路。
    luhe
        22
    luhe  
       68 天前
    跳槽去做新项目
    ytmsdy
        23
    ytmsdy  
       68 天前
    一个类不要超过 300 行,一个文件不要超过 1000 行,按照功能点来规划具体代码,及时合并重复的功能代码。
    只要一个函数同时在两个地方以上用到,那就把它单独拿出来。
    及时删除不用的代码!
    xuelu520
        24
    xuelu520  
       68 天前
    避免不了,找其他人 review 代码+定期重构。
    itechnology
        25
    itechnology  
       68 天前
    没办法的,因为经常会有工期给的不够或者临时要求改需求(曾经遇到过好几次在上线前一天要改需求的情况,而且有时候你还不能拒绝)的情况,这种情况下就避免不了代码变屎山。
    yfugibr
        26
    yfugibr  
       68 天前
    写完别看,只要你不知道它是屎山,它就不是
    FallenTy
        27
    FallenTy  
       68 天前
    无法避免,除非你的业务在写代码的那一刻就不变了
    abc635073826
        28
    abc635073826  
       68 天前
    不要给别人写代码
    wanguorui123
        29
    wanguorui123  
       68 天前
    架构设计,重构,Review
    JackMi
        30
    JackMi  
       68 天前
    公司的一堆屎山,同一个项目,同样的功能,归属于不同的模块,copy 一份过去,就算完成功能,真是日了狗了
    qiumaoyuan
        31
    qiumaoyuan  
       68 天前
    https://www.zhihu.com/question/31049510/answer/115281860

    一句话就是:防微杜渐。

    然后,你要有防微杜渐的能力。
    mmm159357456
        32
    mmm159357456  
       68 天前
    屎山的最优解是丢给别人
    misttyw
        33
    misttyw  
       68 天前
    开发的复杂度从来不会消失,只能转移,屎山同理
    rrZ2C
        34
    rrZ2C  
       68 天前
    写个 3~4 年 差不多维护不下去的时候 果断跳槽
    lihengyu
        35
    lihengyu  
       68 天前
    持续重构
    xuanbg
        36
    xuanbg  
       68 天前
    归根结底,只有三个办法:
    1 、不写代码🐶
    2 、做好设计,写出优雅的代码,且不再增加功能
    3 、持续重构代码

    其实,对于我这样的普通人,也只有第三个办法是可行的。老话说得好,“勤能补拙”。
    yousabuk
        37
    yousabuk  
       68 天前 via iPhone
    只有天天小重构,两天大重构能解。

    今天看昨天写的是屎;
    明天看今天写的是屎;

    一周后觉得项目本身就是屎得把项目推翻……
    janxin
        38
    janxin  
       68 天前
    不写代码
    qiumaoyuan
        39
    qiumaoyuan  
       68 天前
    把这个问题归咎为业务需求的,能不能有点程序员的担当?
    fakeshadow
        40
    fakeshadow  
       68 天前
    写自己经常用的
    justin2018
        41
    justin2018  
       68 天前
    写屎山好呀 只有你能维护 其他人无法维护
    vazo
        42
    vazo  
       68 天前
    水平不够写好注释
    akira
        43
    akira  
       68 天前
    如何避免自己写的代码变成屎山? 首先你要自己写一大坨屎山
    estk
        44
    estk  
       68 天前 via Android
    老板需求变化大对代码架构的影响也很大
    这是商业规律,很难避免
    推特员工被裁,屎山没人懂,不也又招回来了
    KENNHI
        45
    KENNHI  
       68 天前 via Android
    你今天写得很好,明天写得也不错,大后天一看成 shit 了,没办法的
    Crackers
        46
    Crackers  
       68 天前
    1. checkstyle -> review -> refactor -> checkstyle -> review -> refactor -> ...
    2. 多看优秀的开源代码,做做 issue
    3. 不要“怕”看和改以前的代码
    Go for it! (●'◡'●)
    fate
        47
    fate  
       68 天前
    珍惜每一次 CodeReview 和 Debug
    pkoukk
        48
    pkoukk  
       68 天前
    分层分层还是他娘的分层
    虽然复杂度和新人上手难度随着业务唰唰往上涨
    你可以说他是臃肿啰嗦,但你不能说它是屎山,他是可维护的,逻辑结构是清晰的
    chuanqirenwu
        49
    chuanqirenwu  
       68 天前
    人只能利用规律,不能改变规律。
    kooze
        50
    kooze  
       68 天前
    干掉产品经理
    missdeer
        51
    missdeer  
       68 天前
    经常重构
    Track13
        52
    Track13  
       68 天前 via Android   ❤️ 1
    上午还是完美的,下午产品说这个功能要改,下班就要。
    加班还是堆屎山?
    meetyuan
        53
    meetyuan  
       68 天前 via iPhone
    说重构的人,究竟是有多闲?
    linshenqi
        54
    linshenqi  
       68 天前
    吾日三省吾身
    MMMMMMMMMMMMMMMM
        55
    MMMMMMMMMMMMMMMM  
       68 天前
    看类型

    1 、如果是商业代码,市场和需求永远在变,永远有你想不到的逻辑会从奇怪的地方插进来

    2 、如果是兴趣代码,你能一直写下去说明一定有商业价值,然后 goto 1 、
    blankmiss
        56
    blankmiss  
       68 天前
    能跑就行了 管什么 shit 不是 shit 的
    wanganjun
        57
    wanganjun  
       68 天前
    以我写出两个小屎堆的经验看,除非有人来做整体规划,然后不断重构,不然把代码写成屎是必然的
    GreatAuk
        58
    GreatAuk  
       68 天前
    设计模式多看看
    wherewhale
        59
    wherewhale  
       68 天前
    里的清就行
    tool2d
        60
    tool2d  
       67 天前
    和楼上一样,优先代码分层。

    个人觉得按照调用频率,对逻辑代码分支进行分层,也是一个不错的选择。

    比如你写了一个简单的调用框架代码,然后需要针对 N 个公司添加不同的逻辑代码。那么保证主框架不变的前提下,对每个公司都额外 HOOK 一部分特殊代码,也是不错的选择之一。
    liuidetmks
        61
    liuidetmks  
       67 天前
    3 天开需求会,1 天开发,1 天测试上线
    很难~
    leafre
        62
    leafre  
       67 天前
    不要动其他的史山
    Daniel17
        63
    Daniel17  
       67 天前
    一直重构
    mawenjian
        64
    mawenjian  
       67 天前
    领域驱动设计,面向对象编程,多用设计模式,合理划分类间职责。

    根据个人经验,使用面向过程写的代码,最后变成屎山基本是必然的。
    anonymous2351d00
        65
    anonymous2351d00  
       67 天前
    重构
    yeyu123
        66
    yeyu123  
       67 天前
    一直重构
    lilyok1234
        67
    lilyok1234  
       67 天前
    写这么好干嘛,工作这么多年发现写的好的 bug 少,绩效差。写的烂 bug 多,绩效好。又不是不能用
    eason1874
        68
    eason1874  
       67 天前
    变成屎山是必然的,就像你不断往家里塞东西,东西多到超出原先的承载能力了,原先再整齐的房子也会变得很乱,除非重构,也就是每隔一段时间换一个房子,重新收纳
    yxzblue
        69
    yxzblue  
       67 天前
    为什么有人可以在屎一样混乱的几千行代码里加功能?不重构能驾驭屎山吗?
    https://www.zhihu.com/question/497344549/answer/2215116962
    daokedao
        70
    daokedao  
       67 天前
    高手都是拉完屎就换地方,去开辟新的项目(屎山)
    ruoxie
        71
    ruoxie  
       67 天前
    分层
    xumng123
        72
    xumng123  
       67 天前 via iPhone
    避免不了
    aliveyang
        73
    aliveyang  
       67 天前
    只要不再屎上堆屎,屎永远都不会堆成山
    fournoas
        74
    fournoas  
       67 天前
    只要坑挖得深,山就堆不起来
    1vonzhang
        75
    1vonzhang  
       67 天前   ❤️ 3
    我读书的时候也思考过这个问题,那时候太 naive ,觉得水平够高就可以不写屎山了。现在工作了几年,有了一些新的心得:

    0. 核心是要认识到,你以为的需求,你设想的发展方向,你预先做的架构和设计,都会不可避免的朝着你意想不到的方向发展。特别是会发展好多年的软件。

    1. 高内聚,低耦合是避免屎山的真理。永远把功能最小模块化,并设计出好的 API ,是面对改变得心应手的关键。具体怎么分割、怎么设计 API ,是需要一定功底的。

    2. 像楼上很多朋友说的,重构不可避免,不要害怕重构,也不要为了重构而重构。过度重构和过度设计是一样的,都是在把路提前铺好,导致以后修路只能缝缝补补。我做的最多的重构,是在进行稍微大一点的改动之前,把一个部分拆成好几个模块,然后对每个小部分独立的进行修改。

    3. 模块化的东西不要考虑 context 。某一个部分可能只是为了某一个应用场景写的,但是设计的时候要把模块独立考虑,而不是从外部看这个模块会被怎么用到。这样一来可以保证低耦合,二来可以在之后有不同使用场景时,不需要各种补丁代码。
    zjj19950716
        76
    zjj19950716  
       67 天前
    主动或者被动得吃了太多泻药,不搞屎山难不成大活人还要被屎憋死吗? 所以正视屎山,屎崩的时候没有一坨翔是无辜的。
    BrightLiao
        77
    BrightLiao  
       67 天前
    一旦你看你的代码快要变成山了,就得考虑是不是代码垒得太高了。拆分成两座或更多的土丘是大多数人的选择。

    考虑:
    - 从技术上看,有没有模块是非常复杂的,但是是独立的。如有,拆出去,专门给某个人或团队维护。
    - 从业务上看,有没有两个业务本来就是相关性很低的,考虑拆分为不同的项目,交给不同的人维护。

    现在大家在谈微服务,其实就是谈拆分,如何避免一个项目内的东西过于复杂。
    fatelight
        78
    fatelight  
       67 天前
    周期重构
    nicebird
        79
    nicebird  
       67 天前
    基本做不到。人如果被放到被不能胜任的位置,代码复杂度 hold 不住的话,就走向屎山。
    likunyan
        80
    likunyan  
       67 天前
    我的代码我一直觉得它是 shit ,但是我技术又没办法达到改成别人的样子,所以呢?
    sparkpark
        81
    sparkpark  
       67 天前
    The best way to write secure and reliable applications. Write nothing; deploy nowhere.
    https://github.com/kelseyhightower/nocode
    montaro2017
        82
    montaro2017  
       67 天前
    任何代码的尽头都是屎山,你写得再好只不过能延缓它变成屎山的过程
    所以不写出屎山的方式是,不写代码
    loryyang
        83
    loryyang  
       67 天前
    其实就一点,你需要时间来重构
    说实话,一般公司里面,哪有时间,也只有真的有追求的人,愿意放弃自己的休息时间来实现自己的坚持
    不过真的大项目,重构还有另外一个更大的困难:你不敢改,怕出事,这个基本就很难了
    YVAN7123
        84
    YVAN7123  
       67 天前
    提升自己 换公司
    gdgoldlion
        85
    gdgoldlion  
       67 天前
    换个好公司
    如果公司代码天生就烂,你是改变不了什么的
    顶多屎上雕花
    hxysnail
        86
    hxysnail  
       67 天前
    很意外,看到很多人说代码屎山避免不了;也很高兴看到不少人提到一些不错的建议

    其实,我自己的亲身体会时,合理的组织结构,还是会起到很积极的作用的。只是这需要功底,也需要花多一些时间。但是说实话,很多人达不到这样的功底,包括我自己。
    有时一些简单的组织逻辑第一次写都没有梳理清楚,然后某天突然想明白了,去重构。或者某天发现自己在一个不合理的结构上消耗太多精力,才想方设法去做一些优化。
    但是最可怕的事情就是没有意识到问题,如果不能意识到代码屎山带来的破坏性,不能意识到良好结构带来的好处,那结果就是在错误的路上越走越远。

    还有通常在多人协作的项目,存在三个和尚没水喝的问题。你花精力去思考怎么设计得更合理,更稳定,更能适应未来可能的变化,但其他人都是胡乱堆砌,只刷 KPI 到点下班,那你一定会心里不平衡,可能也跟着堆屎山了。上面提到开新坑,定期跑路的,有一个算一个都是自私的人。如果接盘的人可以选择不接,然后你就跑不了路,我想可能又会有所不同。
    从这个角度看,想要战胜人类与生俱来的自私,团队定期复盘代码设计质量可能也很重要。
    crazyweeds
        87
    crazyweeds  
       67 天前
    说点实在的就是:持续 Code Review 、持续重构,不放过任何一个螺丝钉。还有关键的一点,代码能简单写就绝不绕弯子,保持极高的可读性,可降低后续重构代码的时间和精力成本。
    但是,悲催的是,会导致一个问题,你大概率会变成强伯症,别人代码只要略微不讲究,你就会很难受。
    emma3
        88
    emma3  
       67 天前
    你不建屎山,在你跑路后,你的后继者们同样会建个屎上。
    aaa5838769
        89
    aaa5838769  
       67 天前
    一直重构
    achira
        90
    achira  
       67 天前
    如果做不到降低效率,那就只有如上所述的定期重构了
    当然 至少 还可以 注释写得尽可能详细一点 写出为什么要这样
    MEIerer
        91
    MEIerer  
       67 天前 via Android
    多写纯函数算一个
    Pangurban
        92
    Pangurban  
       67 天前
    1. 根据业务特点做合理的抽象。
    2. 除了了解基本的锁以外,了解一两种并发模型(例如纯函数式编程,Actor 模型)
    并发读写、事务性都不简单,当代码不小心引入它们的时候要引起警觉。
    3. 善用语言的特性,例如 Scala 的类型检查,Option ,Try 和 Pattern Match ,少用 Null 和 AsInstanceOf 。
    争取编译通过即无 Bug 。(业务逻辑上的问题除外)
    4. 强迫症。(会很累)
    tuutoo
        93
    tuutoo  
       67 天前 via Android
    不断提升自己写代码的能力,写出屎山代码的根本原因就是能力不行。
    mowen1992
        94
    mowen1992  
       67 天前
    经常重构呗,谁也不是一下子就能写出好代码的,不断对需求深入了解,学习尝试不同的解决问题的方法,才能写出最好的代码
    myd
        95
    myd  
       67 天前
    持续重构
    xy90321
        96
    xy90321  
       67 天前 via iPhone
    小而美的前提是小… 但是小的一般都不赚钱,除了 infra… 所以… 就是理想和面包二选一的问题
    gdyong
        97
    gdyong  
       67 天前 via Android   ❤️ 1
    凡事都有两面,屎山让你饱受批评,却能让你不怕被炒,长年累月待下去🐶
    honghaoz
        98
    honghaoz  
       67 天前 via iPhone
    别急功近利,给自己写。
    theprimone
        99
    theprimone  
       67 天前
    《代码整洁之道》
    《重构:改善既有代码的设计》
    07ly
        100
    07ly  
       67 天前
    自己的个人项目:做好功能设计,完善代码注释,积极更新文档,持续进行重构
    公司的项目:管他干嘛,能跑就行,没两天就推倒重做了。领导自己都想不明白干嘛,还要快速上线,谁有空给他好好设计
    1  2  
    关于   ·   帮助文档   ·   博客   ·   API   ·   FAQ   ·   我们的愿景   ·   广告投放   ·   实用小工具   ·   1533 人在线   最高记录 5497   ·     Select Language
    创意工作者们的社区
    World is powered by solitude
    VERSION: 3.9.8.5 · 47ms · UTC 05:47 · PVG 13:47 · LAX 21:47 · JFK 00:47
    Developed with CodeLauncher
    ♥ Do have faith in what you're doing.