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

[Zhuzhuchenyan]

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

给大家一个复现的情境：

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

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

---

以下是一些最近的碎碎念，今天偶尔看同事写的代码有点难受，背景是 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那行的写法赤裸裸的把boolean当any来用了，所以我建议他将组件的调用方式改为

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

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

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

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

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

---

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

朱朱

[thedrwu]

或许楼主需要去度个假，海边、沙滩、5 星酒店，什么都不用想的那种。
然而转眼一看，一年最大的假期才刚刚过去

[meepo3927]

啊 ， 年过完了

[l00t]

心态问题，你焦虑了。调整下心态就好，要记住活是公司的，做事情不要急，就算耽误了也是公司的时间。

第二个事，真有 tech leader 也未必有用，要是 tech leader 每次都支持你的同事不支持你的话，你估计更郁闷。要尊重别人的做事准则，这种细枝末节上的东西说穿了就是个审美问题，偶尔提意见可以，但是不要过多干涉别人。

[gdtdpt]

不太明白一个 any 不 any 的为啥这么纠结，如果真要当成 boolean 来用，那调用方式应该是
<component [multiple]=“true”> </component>
不加中括号是 string

前端环境下 ts 在我看来就是把 js 包装了一层语法糖而已，很多情况下没法不 any，真要所有类型确定那写起来要累死。

[aw2350]

没必要钻牛角尖较真，打个工而已

[towry]

我觉得人家写法没啥问题，内部封装的好一点，外部调用轻松一点。

或者做一个类似 vue 的 prop type 检查。

[niucility]

开发规范还是要尽量统一的.
猜测你生闷气和认为沟通成本太高有关？

[wangkun025]

管理和技术应该分离。
让管理者承担这部分的压力。

技术就专心处理技术问题。

[wxw752]

你看我写的代码你能气死

[Yano]

其实有 tech lead 也不一定好，你认为 tech leader 是完美的，但是可能问题更多。亲身经验……

[pancl]

胸闷可不是小事，不一写代码还会，得注意下

[SmiteChow]

你不是 leader，你可以向上反馈但不能做决定。
如果你是被指定的 Reviewer，你可以拒绝给出 RTM 的指令。

风格没统一对你个体来讲不是问题，对组织来讲才是问题，所以你有点皇上不急太监急的管闲事了。

[Kasumi20]

把 boolean 当 any 来用，你却要把 boolean 改成 string

[newtype0092]

@wxw752 看着你的头像就好像你在对 LZ 说：“想让我改？吔屎啦你！”

[12tall]

曾经有一段时间只能在后半夜才能平复心情写项目。感觉稍微强势一些、要么就干脆放羊。楼上说的好好休息一下是非常必须的！！！我当时是项目匆匆结束就换了坑。
（忽然在键盘上发现了一根白头发，心疼自己一分钟）

[wangtian2020]

我是公司唯一的前端，心情不好的时候变量命名喜欢以 fk 开头

anyscript 动态类型万岁

[Zhuzhuchenyan]

感谢各位，哎这件事情上可能和节后焦虑也有关系，让我当时有点钻牛角尖了，在没有一个既定规范的时候，还是要尊重他们写代码的方式

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

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

[hxndg]

@Zhuzhuchenyan

这种属于代码风格了吧，如果你们没有代码规范那么这个东西实际上也不是那么严重。
这种时候，你们已经存在的代码是什么标准可以成为争论的参考

[wutiantong]

看别人的代码不要指手画脚，就问能不能跑通，能？牛 b ！

[deadlock]

@wxw752 哈哈哈哈哈哈哈哈哈

[sonxzjw]

就算又 lead 也可能是和稀泥的

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

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

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

好离奇吧？哈哈哈

[yamedie]

朱朱? po 主是 A 岛岛民?

[jaxer]

@sonxzjw 何止离奇，简直就是关系户

[iikebug]

@sonxzjw 是由够离谱的，就基本的代码合并操作都不规范，这其他的还得了？

[siteshen]

在一个需要排解心情的帖子下面，我这回复可能引起不适。



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

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

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

如果是我来处理，我会保留现有的设计，修改实现。

[Austaras]

any 也是错的, 这里应该用 unknown

[moka20477]

其实就是工作压力大，可以学学 timeboxing，把任务目标拆分，不用去考虑大目标，按部就班完成小目标就行

[Zhuzhuchenyan]

@siteshen 没事，只要是中肯的讨论我觉得没必要去顾虑合适不合适。

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

再次感谢各位的建议

[iugo]

在 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]

@Zhuzhuchenyan 我说一种解释, 或许可以理解一下.

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

我不知道 ng 是否支持 JS, 如果也支持 JS, 那么上面的想法也就有一定道理.

[Zhuzhuchenyan]

@iugo 嗯是的，`unknown`的确是一个在未知的情况下更好地选择

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

Fine, 得过且过吧，也算是学会了新用法，严格模式开是不可能开的，之前代码里太多魔法了