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

[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 的团队也是我生闷气的导火索之一，几个开发谁都有自己一套做事准则，类似的争端每天都有，各位是怎么排解这种心情的呢

朱朱

[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, 得过且过吧，也算是学会了新用法，严格模式开是不可能开的，之前代码里太多魔法了