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

最近写代码感觉像是憋着一口闷气在写

  •  
  •   Zhuzhuchenyan · 247 天前 · 3925 次点击
    这是一个创建于 247 天前的主题,其中的信息可能已经有所发展或是发生改变。

    不知道各位有没有类似的感受,

    给大家一个复现的情境:

    一个任务拆分成了十几个子任务按顺序慢慢完成,在写这些子任务的时候就感觉憋着一口闷气,感觉要快点把事情做完又感觉看不到头。

    重点是看不到任务完成希望的绝望感和任务要快点做完的紧迫感两者融合产生的以我的文学水平无法描述的心态,其外在表现就是写代码就像和自己生闷气一样,久而久之真的有一种喘不上气的感觉,就比如我现在就感觉必须要大口呼吸


    以下是一些最近的碎碎念,今天偶尔看同事写的代码有点难受,背景是 Angular 和 TS,

    _isMultiple: boolean;
    
    get multiple(): boolean {
        return this._isMultiple;
    }
    @Input() set multiple(value: boolean) {
        this._isMultiple = (value != null && String(value)!=='false')
    }
    

    以上代码是为一个组件服务的,这个组件他大概希望被这么调用

    <component multiple> </component>
    

    他的理由是这个组件看起来是一个可以支持多选的下拉列表选择组件,所以选择使用 html5 标准里 multiple 属性来让这个组件的调用方式看起来和原生 input type=file 一致

    我为什么觉得难受呢,因为感觉他@Input那行的写法赤裸裸的把booleanany来用了,所以我建议他将组件的调用方式改为

    <component multiple=“true”> </component>
    

    这样就没必要做额外的工作了

    他跟我说我现在做的是一个 select 组件,让他和原生的调用方式一致是一个正常需求吧?

    Fine,我的想法很简单,不求他改其他东西,把boolean改成any就行,我也在其他库里见过类似用法,就不提改成string | boolean | undefined了,就是不愿意动,说实在不行我加个注释好啦。

    我也不选择和他犟,工作而已,我们组也没有一个拍板的 tech lead,吵来吵去谁都无法说服对方。


    感觉有点流水账了,感觉没有 tech lead 的团队也是我生闷气的导火索之一,几个开发谁都有自己一套做事准则,类似的争端每天都有,各位是怎么排解这种心情的呢

    朱朱

    31 条回复    2021-02-19 19:01:32 +08:00
    thedrwu
        1
    thedrwu   247 天前 via Android   ❤️ 2
    或许楼主需要去度个假,海边、沙滩、5 星酒店,什么都不用想的那种。
    然而转眼一看,一年最大的假期才刚刚过去
    meepo3927
        2
    meepo3927   247 天前
    啊 , 年过完了
    l00t
        3
    l00t   247 天前
    心态问题,你焦虑了。调整下心态就好,要记住活是公司的,做事情不要急,就算耽误了也是公司的时间。

    第二个事,真有 tech leader 也未必有用,要是 tech leader 每次都支持你的同事不支持你的话,你估计更郁闷。要尊重别人的做事准则,这种细枝末节上的东西说穿了就是个审美问题,偶尔提意见可以,但是不要过多干涉别人。
    gdtdpt
        4
    gdtdpt   247 天前
    不太明白一个 any 不 any 的为啥这么纠结,如果真要当成 boolean 来用,那调用方式应该是
    <component [multiple]=“true”> </component>
    不加中括号是 string

    前端环境下 ts 在我看来就是把 js 包装了一层语法糖而已,很多情况下没法不 any,真要所有类型确定那写起来要累死。
    aw2350
        5
    aw2350   247 天前
    没必要钻牛角尖较真,打个工而已
    towry
        6
    towry   247 天前
    我觉得人家写法没啥问题,内部封装的好一点,外部调用轻松一点。

    或者做一个类似 vue 的 prop type 检查。
    niucility
        7
    niucility   247 天前 via iPhone
    开发规范还是要尽量统一的.
    猜测你生闷气和认为沟通成本太高有关?
    wangkun025
        8
    wangkun025   247 天前
    管理和技术应该分离。
    让管理者承担这部分的压力。

    技术就专心处理技术问题。
    wxw752
        9
    wxw752   247 天前
    你看我写的代码你能气死
    Yano
        10
    Yano   247 天前
    其实有 tech lead 也不一定好,你认为 tech leader 是完美的,但是可能问题更多。亲身经验……
    pancl
        11
    pancl   247 天前 via Android
    胸闷可不是小事,不一写代码还会,得注意下
    SmiteChow
        12
    SmiteChow   247 天前
    你不是 leader,你可以向上反馈但不能做决定。
    如果你是被指定的 Reviewer,你可以拒绝给出 RTM 的指令。

    风格没统一对你个体来讲不是问题,对组织来讲才是问题,所以你有点皇上不急太监急的管闲事了。
    Kasumi20
        13
    Kasumi20   247 天前   ❤️ 1
    把 boolean 当 any 来用,你却要把 boolean 改成 string
    newtype0092
        14
    newtype0092   247 天前
    @wxw752 看着你的头像就好像你在对 LZ 说:“想让我改?吔屎啦你!”
    12tall
        15
    12tall   247 天前
    曾经有一段时间只能在后半夜才能平复心情写项目。感觉稍微强势一些、要么就干脆放羊。楼上说的好好休息一下是非常必须的!!!我当时是项目匆匆结束就换了坑。
    (忽然在键盘上发现了一根白头发,心疼自己一分钟)
    wangtian2020
        16
    wangtian2020   247 天前
    我是公司唯一的前端,心情不好的时候变量命名喜欢以 fk 开头

    anyscript 动态类型万岁
    Zhuzhuchenyan
        17
    Zhuzhuchenyan   247 天前 via iPhone
    感谢各位,哎这件事情上可能和节后焦虑也有关系,让我当时有点钻牛角尖了,在没有一个既定规范的时候,还是要尊重他们写代码的方式

    毕竟公司的重心还是在做游戏上,对我们这种边缘支持部门的技术投入不是很重视,哎习惯了就好

    可能是我太憧憬上头有一个管事的了,我理解这可能会带来更多矛盾,不过我总是以为望而不得的东西是好的
    hxndg
        18
    hxndg   247 天前
    @Zhuzhuchenyan

    这种属于代码风格了吧,如果你们没有代码规范那么这个东西实际上也不是那么严重。
    这种时候,你们已经存在的代码是什么标准可以成为争论的参考
    wutiantong
        19
    wutiantong   247 天前
    看别人的代码不要指手画脚,就问能不能跑通,能?牛 b !
    deadlock
        20
    deadlock   247 天前 via iPhone
    @wxw752 哈哈哈哈哈哈哈哈哈
    sonxzjw
        21
    sonxzjw   247 天前   ❤️ 1
    就算又 lead 也可能是和稀泥的

    之前就遇到一个差不多的情景,让楼主看到别人的悲伤能开心起来

    svn 操作问题,我要求每次更新最起码是 检查更新 /合并,更新,提交。结果有个同事偏不,就只强制更新提交上去,覆盖别人的更新。结果我两就在群里吵起来了,lead 过来说这是小事,让我”让让“那同事别吵了。emm...我感觉挺好笑的。fine,我不说了。

    之后发生了 3 次事件吧,2 次是那同事把别人代码覆盖了导致生产问题排查了 n 久。1 次就是那同事误删生产数据库。然后那同事拿到了当年年度最佳员工表现奖。

    好离奇吧?哈哈哈
    yamedie
        22
    yamedie   247 天前
    朱朱? po 主是 A 岛岛民?
    jaxer
        23
    jaxer   247 天前
    @sonxzjw 何止离奇,简直就是关系户
    iikebug
        24
    iikebug   247 天前
    @sonxzjw 是由够离谱的,就基本的代码合并操作都不规范,这其他的还得了?
    siteshen
        25
    siteshen   247 天前
    在一个需要排解心情的帖子下面,我这回复可能引起不适。



    字符串是个框,啥都能往里面装。我一般是能不用字符串,就不用字符串,而 any 比字符串更糟糕,完美抹杀 typescript 引入的类型系统。

    从设计角度来看,multiple 作为 boolean 是个不错的选择。
    从实现角度来看,既然输入的类型为 boolean,那么就不需要考虑用户传入字符串的情况。

    所以你难受可能是因为设计和实现理念不一致,或者说「实现」兼容了用户传入非 boolean 的情况。

    如果是我来处理,我会保留现有的设计,修改实现。
    Austaras
        26
    Austaras   247 天前
    any 也是错的, 这里应该用 unknown
    moka20477
        27
    moka20477   247 天前
    其实就是工作压力大,可以学学 timeboxing,把任务目标拆分,不用去考虑大目标,按部就班完成小目标就行
    Zhuzhuchenyan
        28
    Zhuzhuchenyan   247 天前
    @siteshen 没事,只要是中肯的讨论我觉得没必要去顾虑合适不合适。

    心情需要排解,问题也需要去面对。

    再次感谢各位的建议
    iugo
        29
    iugo   247 天前
    在 React 中, `<component multiple> </component>` = `<component multiple={true}> </component>`.

    还真没考虑过属性名称与用法与 html 一致.

    没写过 ng, 但在 TS 中, 这样写 unknown 的确更好:

    ```ts
    @Input() set multiple(value: unknown) {
    this._isMultiple = (value != null && String(value)!=='false')
    }
    ```
    iugo
        30
    iugo   247 天前
    @Zhuzhuchenyan 我说一种解释, 或许可以理解一下.

    因为 TS 的类型限制仅仅限制编译, 而不限制运行时, 所以有人既想让尊重类型的尽量传入布尔, 又想让代码兼容非预期的参数传入, 所以才一边限制了类型, 一边又做兼容.

    我不知道 ng 是否支持 JS, 如果也支持 JS, 那么上面的想法也就有一定道理.
    Zhuzhuchenyan
        31
    Zhuzhuchenyan   247 天前
    @iugo 嗯是的,`unknown`的确是一个在未知的情况下更好地选择

    刚才打开了 https://angular.io/guide/template-typecheck#strict-mode, 一个 Angular 9 才引入的严格模板类型检查,同事那样的代码无法通过编译,会提示 Type 'string' is not assignable to type 'boolean'.ngtsc(2322)

    Fine, 得过且过吧,也算是学会了新用法,严格模式开是不可能开的,之前代码里太多魔法了
    关于   ·   帮助文档   ·   FAQ   ·   API   ·   我们的愿景   ·   广告投放   ·   感谢   ·   实用小工具   ·   977 人在线   最高记录 5497   ·     Select Language
    创意工作者们的社区
    World is powered by solitude
    VERSION: 3.9.8.5 · 23ms · UTC 19:25 · PVG 03:25 · LAX 12:25 · JFK 15:25
    ♥ Do have faith in what you're doing.