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

大家写业务代码有什么心得吗?

  •  
  •   jzyff · 2020-10-15 11:31:58 +08:00 · 9373 次点击
    这是一个创建于 584 天前的主题,其中的信息可能已经有所发展或是发生改变。
    85 条回复    2020-10-17 16:41:25 +08:00
    chimingphang
        1
    chimingphang  
       2020-10-15 11:33:25 +08:00
    +1
    IsaacYoung
        2
    IsaacYoung  
       2020-10-15 11:35:48 +08:00   ❤️ 27
    心得就是老代码能不动就不动
    JaguarJack
        3
    JaguarJack  
       2020-10-15 11:37:12 +08:00   ❤️ 1
    @IsaacYoung 同感!尤其别人写的,尽量别动,重写都别动
    fatigue
        4
    fatigue  
       2020-10-15 11:44:22 +08:00   ❤️ 20
    心得是,有需求可以先不着急写,先等等看,整理下思路,最主要是可能产品经理马上就又修改需求了
    someonedeng
        5
    someonedeng  
       2020-10-15 11:44:59 +08:00   ❤️ 4
    "又不是不能用"
    silenzio
        6
    silenzio  
       2020-10-15 11:46:50 +08:00   ❤️ 5
    不要过度设计
    满足当下以及未来一段时间(比如半年)的需求就可以了
    jzyff
        7
    jzyff  
    OP
       2020-10-15 11:47:48 +08:00
    @fatigue 让需求飞一会?
    dilu
        8
    dilu  
       2020-10-15 11:57:52 +08:00   ❤️ 22
    1. 先理清思路,画好流程图,做好表结构设计,如果多系统画好泳道图或者时序图。然后在动手编码。(前端 /客户端等方向类似,总得来说就是先设计,落实到文档再开发,一来思路清晰,二来产品可能第二天就变需求了)
    2. 不要删以前的老代码,哪怕没有地方调用,因为你永远不知道哪里会有用到的地方。例子:以前有个方法没有调用,后来发现是 n 年前的公众号的接口,差点删了。
    3. 不要用任何的骚操作,用最简单,最直接的方法写。变量名方法名能做到`顾名思义`。
    4. 不要过早优化,不要过度设计。
    5. 技术远远比不上业务重要,延期远远比线上较小事故严重。
    6. 简单代码能复制的就复制,效率比你自己写的高。
    labulaka521
        9
    labulaka521  
       2020-10-15 12:09:21 +08:00 via iPhone
    💩山堆💩
    Kirsk
        10
    Kirsk  
       2020-10-15 12:21:33 +08:00 via Android
    看来重构已经没有市场 直接重写一堆屎山 还有 kpi 真香 从一座屎山到另一座
    opengps
        11
    opengps  
       2020-10-15 12:25:05 +08:00   ❤️ 4
    在业务真的足够强大之前,不要过度去在代码上浪费太多细节时间
    woahishui
        12
    woahishui  
       2020-10-15 12:28:00 +08:00 via Android
    越写越有心得。
    godblessumilk
        13
    godblessumilk  
       2020-10-15 12:47:16 +08:00 via Android
    心得就是我和血汗工厂的工人没差,离职的时候把代码写得只有我自己看懂报复下乱改需求的
    6ugman
        14
    6ugman  
       2020-10-15 13:11:49 +08:00
    现成的框架 /设计不要用,自己随便写,KPI++ 顺便恶心别人
    stephenxiaxy
        15
    stephenxiaxy  
       2020-10-15 13:37:43 +08:00
    这写的是个啥啊
    xuanbg
        16
    xuanbg  
       2020-10-15 13:46:43 +08:00   ❤️ 1
    @dilu 补充一点:代码尽量写成相同的结构,相同的结构复制粘贴才方便。大到项目可以整体复制粘贴,小到代码片段可以复制粘贴。
    chenqh
        17
    chenqh  
       2020-10-15 13:49:54 +08:00 via Android
    @xuanbg 这个什么意思?
    ZSpirytus
        18
    ZSpirytus  
       2020-10-15 13:55:39 +08:00 via Android   ❤️ 7
    1. 高成本低收益的需求能推掉就推掉,或者降低优先级,浪费时间浪费精力;
    2. 拍脑袋需求可以优先级放低,没准哪天产品想清楚了就不做了;
    3. 一切都可以追溯,不要口口相传,哪怕是聊天记录也好;
    4. 写代码要按照代码规范来写;
    5. 代码尽量简单,这样查问题的时候一目了然,而不是还要重新读和理解一遍。
    xuanbg
        19
    xuanbg  
       2020-10-15 13:56:35 +08:00
    @chenqh 八股文知道吧?只不过把写文章变成写代码,你看到的每个方法只是名称和参数不一样,代码都差不多样子。扩大到每个类也是如此,再推广到模块级别甚至服务级别,都是这个套路。具体的看我的代码就知道了。https://github.com/xuanbg/insight_funds_account
    8Cangtou
        20
    8Cangtou  
       2020-10-15 14:12:36 +08:00   ❤️ 1
    代码只能加,不能删~~~
    YAR
        21
    YAR  
       2020-10-15 14:35:47 +08:00
    对业务有疑问, 一定要和产品反复沟通和确认, 不然后面有你改的
    leafre
        22
    leafre  
       2020-10-15 14:53:08 +08:00
    不要过度抽象,越是好的代码越是简单明了,别人一看就明了
    kaiki
        23
    kaiki  
       2020-10-15 15:02:26 +08:00
    想到哪写到哪,宁愿新增也不改旧代码
    charlie21
        24
    charlie21  
       2020-10-15 15:07:48 +08:00   ❤️ 1
    定期做业务系统分析 业务系统全貌分析 业务系统全貌研究,在你的代码查看权限允许的范围之内 把所有代码搞懂
    Justin13
        25
    Justin13  
       2020-10-15 15:30:23 +08:00 via Android
    小车不倒只管推
    dilu
        26
    dilu  
       2020-10-15 15:31:14 +08:00
    @xuanbg wocao 为什么你艾特我我这里都没有消息的,还是点进来才有,最近这种情况特别多
    xuanbg
        27
    xuanbg  
       2020-10-15 16:03:14 +08:00
    @dilu 据说是因为我被降权的缘故。。。我也不知道为什么就被降权了。。。
    Rimifon
        28
    Rimifon  
       2020-10-15 16:22:39 +08:00   ❤️ 1
    尽量不要在 if 中套 if,及时 return,使逻辑越来越清晰。
    lifesimple
        29
    lifesimple  
       2020-10-15 16:25:33 +08:00   ❤️ 2
    能跑就行,等我有空再优化
    Aaron55
        30
    Aaron55  
       2020-10-15 16:25:35 +08:00
    收藏一下,刚工作一个半月的菜鸟,学习学习前辈们的心得。
    jones2000
        31
    jones2000  
       2020-10-15 16:27:18 +08:00
    快速实现功能就可以, 反正产品那边经常变动,大概率之前写的业务代码都用不了的。
    Yotako
        32
    Yotako  
       2020-10-15 16:31:52 +08:00
    @IsaacYoung 要动就删了重做
    beidounanxizi
        33
    beidounanxizi  
       2020-10-15 16:57:36 +08:00
    别动别人的代码 可以复制黏贴在此技术上修改。。。但是就是不能改别人的代码
    beidounanxizi
        34
    beidounanxizi  
       2020-10-15 16:58:41 +08:00   ❤️ 1
    方法不要写得太长 提倡组合大于继承,别秀无畏的操作
    clear is more wisdom than clever
    dddd1919
        35
    dddd1919  
       2020-10-15 17:34:38 +08:00
    学会起名,效率翻翻
    Jooooooooo
        36
    Jooooooooo  
       2020-10-15 17:38:15 +08:00   ❤️ 2
    不要过度设计

    遵守三板斧规范

    可监控
    可降级
    可回滚
    MagnifierSun
        37
    MagnifierSun  
       2020-10-15 17:59:50 +08:00   ❤️ 1
    保证函数功能的单一性,
    尽量写无副作用的函数.
    不要在看起来是纯函数里改变类成员变量!
    yang137162692
        38
    yang137162692  
       2020-10-15 18:22:12 +08:00
    马克 一波
    ruoxie
        39
    ruoxie  
       2020-10-15 20:05:16 +08:00
    宁愿多复制粘贴几次,也不要写难以维护的“复用”代码。最近临时帮别的项目组赶需求,5 种场景、增改查的弹窗代码全部怼一起,1600 多行代码,真是一坨屎山。
    s5s5
        40
    s5s5  
       2020-10-15 20:15:32 +08:00
    项目内配置好统一代码自动格式化工具
    Jackeriss
        41
    Jackeriss  
       2020-10-15 20:21:02 +08:00 via iPhone
    @IsaacYoung 不完全赞同,该动的时候还得动(如果这块业务你要长期负责的话),但是要找到一个契机,继续往上堆总有一天会发现难以维护,或者有性能问题,趁你还能 hold 住的时候干掉它,省的之后改个需求还得考古一样的阅读别人写的代码,很多 bug 都是因为你没搞清楚别人的逻辑,自己写问题就少很多,效率也高很多。
    iwh718
        42
    iwh718  
       2020-10-15 21:23:04 +08:00 via iPhone
    心得就是:注释很重要 。是把部分代码注释了 以后又继续用下去 🧐
    PainAndLove
        43
    PainAndLove  
       2020-10-15 21:57:26 +08:00
    楼上都是大佬啊。。
    icyalala
        44
    icyalala  
       2020-10-15 21:59:50 +08:00
    心得就是努力不要写业务代码,业务代码都是屎堆。
    再一个心得就是,如果不得不写业务代码,那就不要去捅陈年屎堆。。
    wangyzj
        45
    wangyzj  
       2020-10-15 22:11:32 +08:00   ❤️ 1
    三种情况
    一种是“写完了完全不知道是个啥”
    第二种是“业务人员最后都得听我的,他们开始设计的就是错误的”
    第三种是“业务人员自己设计的东西自己不记得,然后我成为业务”
    iannil
        46
    iannil  
       2020-10-15 22:23:22 +08:00
    一切操作都要有记录,给我省了不知道多少事
    insert000
        47
    insert000  
       2020-10-15 22:46:42 +08:00
    存不存什么复用不复用,客户的想法一天一个变,就算组件化,最后改着改着就成屎山了。架构的再好也抵不过天马星空的需求
    dotw2x
        48
    dotw2x  
       2020-10-15 22:49:04 +08:00 via Android   ❤️ 2
    无数次的血泪得出的教训:千万不要相信产品写死,一定要考虑加开关配置!!!
    Saszr
        49
    Saszr  
       2020-10-16 00:56:41 +08:00
    不要过度封装
    DoctorCat
        50
    DoctorCat  
       2020-10-16 03:13:28 +08:00
    如果是一个很复杂的逻辑 /组件,为了保证休假后回来 /长时间再回头迭代时自己不犯浑,一定要写一份设计文档 /笔记给自己…
    hambman
        51
    hambman  
       2020-10-16 04:27:42 +08:00
    大家说的业务代码是相对什么而言?如果不是业务代码,是核心组件代码,比如数据库,会有哪些不同?
    pecopeco
        52
    pecopeco  
       2020-10-16 08:12:10 +08:00 via Android
    已经把公司项目代码重构两次了。。就个人来说是有意义的,成功把屎山变成青山绿水
    exceldream
        53
    exceldream  
       2020-10-16 08:35:01 +08:00 via Android
    没人提可测试性,以及单测覆盖吗?
    exceldream
        54
    exceldream  
       2020-10-16 08:36:07 +08:00 via Android
    没人提可测试性,以及单元测试覆盖吗?
    sugars
        55
    sugars  
       2020-10-16 09:03:21 +08:00
    要有预测未来加新功能的能力,不要求写得多漂亮,但写的代码未来方便继续拓展就好
    wanacry
        56
    wanacry  
       2020-10-16 09:12:18 +08:00 via iPhone
    @xuanbg 没看明白,看了你的代码后没有什么特别的感觉啊,现在的业务代码不都是这么写的吗?
    oma1989
        57
    oma1989  
       2020-10-16 09:17:07 +08:00
    很多没用的代码并不是开发的原因,而是需求变更太频繁。。。。
    oma1989
        58
    oma1989  
       2020-10-16 09:18:58 +08:00
    @pecopeco 也许换个人再来看也不是青山绿水。。。。(只要是跟自己风格不一致都不是青山绿水)
    pigfly123
        59
    pigfly123  
       2020-10-16 09:21:37 +08:00
    1. 产品提的需求如果实现起来很麻烦或者觉得很鸡肋的功能,尽量协商做减法
    2. 代码多写注释
    3. 不要求有多牛逼的设计模式,但最少不要写成一大坨
    Nicoco
        60
    Nicoco  
       2020-10-16 09:41:51 +08:00
    @dilu 老哥稳的很
    Nicoco
        61
    Nicoco  
       2020-10-16 09:43:00 +08:00
    @ZSpirytus 看来是老工程师了!
    m1ch3ng
        62
    m1ch3ng  
       2020-10-16 09:47:26 +08:00
    牛逼,学习了
    EmotionV
        63
    EmotionV  
       2020-10-16 09:57:56 +08:00
    即使两个界面布局类似也要分开写,不要复用,你永远不知道产品经理的脑子里在想什么

    当然小组件可以抽离出来
    VintageZ
        64
    VintageZ  
       2020-10-16 10:15:03 +08:00
    写业务代码最难得点是:如何在无设计与过度设计之间取得平衡
    leafShimple
        65
    leafShimple  
       2020-10-16 10:15:18 +08:00
    别怂 系统是自己负责项目所有代码都走读过后,业务已经清楚的业务场景.如果历史包袱太重影响到后续迭代,直接冲冲冲,改就完了.然后申请测试资源充分测试.不重要的就写点注释或者包一层不看见就不烦了.改完代码一定不要盲目自信不经过测试,即使有单元测试,多测试,多测试.但是也不要追求场景 100%覆盖(因为这做不到)
    找准系统的核心.财务系统还是尽量少变动,不要相信跑了很久就没有问题.日志和代码才不会骗人.财务系统多加操作记录.
    业务系统是在不同的背景下开发的,有点什么坑也别喷.鬼知道这个项目是不是每天晚上 1 点开发出来的.
    dilu
        66
    dilu  
       2020-10-16 10:59:39 +08:00
    @Nicoco 奇怪 最近很多人艾特我,我都收不到消息,难道我被降权了?
    MrWhite
        67
    MrWhite  
       2020-10-16 11:00:49 +08:00
    @dilu 5 老哥意思是例如一个新功能。尽快把功能先做完。然后又 bug 可以先不修复么。。等被发现在修复? 可以理解为:做没做完是一回事,做完了有 bug 又是一回事吧。。
    dilu
        68
    dilu  
       2020-10-16 11:08:27 +08:00
    @MrWhite 意思是,不要觉得技术可以凌驾业务之上。技术就是工具,产品怎么说就怎么做,不要觉得`这样做出来更优雅,扩展性更强`。一定要严格按照需求文档进行开发。同时,如果线上有个小问题,例如原本 info 日志打成了 error 造成的报警,同时手上有个需求快要提测,一定要先忙后者。尤其是在微服务团队内,一个人延期就会造成整个项目的延期。
    taowen
        69
    taowen  
       2020-10-16 11:13:55 +08:00
    securityCoding
        70
    securityCoding  
       2020-10-16 11:15:47 +08:00
    不要瞎几把抽象及时抽出公共代码 , 不要瞎几把过度设计 ,做好业务领域建模 ,写好业务流程注释和文档

    233 有个天天奇思妙想的技术老大真的很烦
    shellic
        71
    shellic  
       2020-10-16 11:22:14 +08:00
    接到需求先不要动手写代码,先把流程理清,表结构规划好,等你做完这些需求就又变了
    wisunny
        72
    wisunny  
       2020-10-16 11:23:35 +08:00 via Android
    完全是语法糖和体力活,真是用到算法的少之又少。。。
    glfpes
        73
    glfpes  
       2020-10-16 11:32:01 +08:00
    日志一定要精心设计,尽可能少打。
    matrix67
        74
    matrix67  
       2020-10-16 12:10:32 +08:00
    @glfpes #73 为啥是少打
    AsunaQAQ
        75
    AsunaQAQ  
       2020-10-16 14:28:14 +08:00
    做东西不求快 但求稳
    SunFarrell
        76
    SunFarrell  
       2020-10-16 15:01:57 +08:00
    这个话题,相见恨晚,坑都经历过了
    watzds
        77
    watzds  
       2020-10-16 15:14:21 +08:00 via Android
    老代码能不动就不动,该动还是要动,怎么动不出故障也是门学问
    a719031256
        78
    a719031256  
       2020-10-16 15:23:44 +08:00
    有现成的代码绝对不要去写新的代码,费时费力不说,效果可能还没现有的好
    sweat89
        79
    sweat89  
       2020-10-16 15:41:27 +08:00
    好贴
    CoderGeek
        80
    CoderGeek  
       2020-10-16 15:44:47 +08:00
    大部分是如何不趟坑 ,还有在一堆复杂代码里提出来的东西
    比如一个复杂业务扩展和工具集之类的: https://github.com/codeyung/service-support 没啥人看
    gengzi
        81
    gengzi  
       2020-10-16 16:56:13 +08:00
    入参出参影响业务流程的日志写好,防止因为业务问题出错,都不好找问题。
    jimliang
        82
    jimliang  
       2020-10-16 16:58:02 +08:00
    要学会控制自己的情绪
    MrWhite
        83
    MrWhite  
       2020-10-17 12:32:50 +08:00
    @dilu 感谢老哥详细解答~~受教了
    raaaaaar
        84
    raaaaaar  
       2020-10-17 15:18:17 +08:00
    有些坑不得不踩,比如过度设计和完全不设计这两个极端,还是要踩的,不然不可能找得到平衡点,还是要经验堆出来。但是有这个念头比较重要,当你什么都想设计的时候,要想想自己是不是有点过度了,这样有必要吗?

    但是有些坑就最好别踩,比如业务和技术的平衡问题,一踩就是大问题。。
    vone
        85
    vone  
       2020-10-17 16:41:25 +08:00
    写业务代码容易抑郁。
    关于   ·   帮助文档   ·   API   ·   FAQ   ·   我们的愿景   ·   广告投放   ·   感谢   ·   实用小工具   ·   2419 人在线   最高记录 5497   ·     Select Language
    创意工作者们的社区
    World is powered by solitude
    VERSION: 3.9.8.5 · 31ms · UTC 05:16 · PVG 13:16 · LAX 22:16 · JFK 01:16
    Developed with CodeLauncher
    ♥ Do have faith in what you're doing.