按照团队的流程来，虽然不规范，但是也长久的运行下来了。
对于一个新人来说是不好去推动的。除非你领导也有意思，然后拿你当枪使去推进团队规范，然后锅你全背，好处他全拿。

我的想法是即使没有开发规范，你也是可以自己心里有一个规范，按照你自己的“好”标准去开发，但也不要去要求别人，会被认为是多管闲事。
如果觉得在这样的团队待久了会因为环境问题影响自己的水平和能力发展，那么就早点跳槽去一下家你觉得更好的公司。

---
题外话，就算是大的研发团队，没有良好的开发流程和开发规范也是屡见不鲜的事情。不是所有的公司都是以技术为主导的，更多的还是以业务为主导，技术只是业务的配套和支持。

@ygtq #270, [Wayback Machine]( https://web.archive.org/)

60 也太猛了。

最近加班多，已经从 54 掉到 50.4 了，估计再继续加班下去要下 50 了。

带个充电器不就好了嘛，现在候机的地方不都有插座可以充电么…

@hwdq0012 #79 ，那也不是不行动的理由啊。多和直属领导和人事搞搞关系，把你放进裁员名单。早晚会轮到的。不如早点想办法。

https://i.imgur.com/krir4IG.png 实习生不是学生还能是其他途径来的吗？正经中专以上学历都是需要实习经历才能毕业的吧……

感觉是 OP 觉得裁正式员工&招实习生干正式工的活，降低人力成本的行为感到不满吧。
但是不满有啥用，不是应该想办法让自己早点上裁员名单早点提桶跑路吗…… https://i.imgur.com/duWRpIu.png 这都已经很明显的信号了还想着老板良心发现？

很简单，所有承诺都当做没有。想要利益最大化只要看工资能给多少就好了。

老板想着要给你 股权、分红，说直接点就是“我现在开的工资不会很多，但是如果公司盈利了我再给你分红 or 赎回”，这不就是想空手套白狼？

换句话说，你觉得凭什么老板会让渡利益给到你，因为你技术很🐂🍺吗？没有你换成其他人公司就开不起来了吗？
如果回答不是确定的“是，没有我公司就开不起来”那么就是在框你。

这是老板焦虑的体现。

他在焦虑什么只有你们清楚了。

@yinzhenyu 仓库文档中的预览截图丢了，应该是编译之后清空了 dist 目录？

@yinzhenyu #7 ，不是 OP 你的问题。https://i.imgur.com/NIvxivj.png 是提交的人每次都打的是 “1” 这个 commit message 。

终于不用自己写脚本汇总了，但是为什么我输出的汇总是一堆的 1 /dog

@pakholeung372 #56 ，并不是说完全按照这个标准去实施，按照容器和展示组件的理念在大组件的场景下作为拆分组件的指导。复杂的业务逻辑依旧可以把他们提取成单独的 TS 函数或者 Hooks 。
但是作为渲染的叶子节点组件，我觉得不要业务太多强相关逻辑是正确的，在容器组件把数据处理好传递下来就行了，我们需要确定数据会在哪些部分做哪些修改。如果是视图层的交互逻辑，没有必要区分的太清楚，我觉得主要是数据的组装和接口交互。

过度拆分和封装的问题，不一定是容器和展示组件导致的。这个是经验问题，在职业生涯的起步阶段必定会经历的过程。需要开发者自己知道为什么拆分会带来什么好处，而不是按部就班。

@drymonfidelia #4 ，OP 你是怎么安装的，我怎么安装完默认还都是 VSC ，还得一个一个去改成 Cursor……

@yesterdaysun #27 ，我贴的是 Admin 框架，并不是 UI 库。里面有一些基础的通用页面，比如说用户管理、角色管理、菜单管理这种的，对于管理后台来说已经足够参考了。
如果要复杂的具体业务逻辑那么多半不会开源出来，如果是非管理后台的需求，可以直接在 Github 中用关键词 + Vue 的组合去检索，按照 star 数量来排序慢慢找就好了。

学好 JavaScript ，以及更基础的计算机科学与技术 /dog

不要局限于某一个框架，和某一个语言上面。

@yesterdaysun #20 ，面条代码之间可以用空行或者注释行来区分。但是如果是很复杂了的情况， 可以继续拆组件（比如说我在 #10 中提到的容器、展示组件的思想），或者单纯只是把业务逻辑提取出来，然后通过函数返回值的形式来调用就可以了，并不一定要改成 useXXX 这样的形式。
就是简单的函数返回：
```js
async fcuntion fnA (X) {
const valueB = fnB(XX)
const fetchData = await fetchXXX()
}

function fnB(XXX) {
....
return XXX
}
```

按照指责单一、关注点分离的思想去拆就可以了。至于是要在一个文件里面，还是拆分成多个文件就是看你自己的喜好。


-----



一些需要改造成 useXXX 的，常用的其实基本上都可以在 [VueUse]( https://vueuse.org/) 这个库里面找到。
一些业务逻辑相关的，比如说 CURD 的管理页面就会抽象一个 useTable() 的 hooks 来使用。但是返回出来的变量也不一定都要使用，具体用到哪些就解构出来哪些就好了。如果按照你说的需要同时解出来 8 、9 个变量了。是不是应该考虑一下逻辑再拆分。

不确定是否是最优解的场景，我的想法是找比较大的开源项目是怎么设计的，比如说我提到的 useTable ，社区的解决方案中就是再组装之后返回的，把相关的一些属性用一个属性包起来

```js
export const useTable = (config: UseTableConfig) => {
....
return {
tableRegister: register,
tableMethods: methods,
tableState: {
currentPage,
pageSize,
total,
dataList,
loading
}
}
}
```
[vue-element-plus-admin/src/hooks/web/useTable.ts at v2.10.0 · kailong321200875/vue-element-plus-admin]( https://github.com/kailong321200875/vue-element-plus-admin/blob/v2.10.0/src/hooks/web/useTable.ts#L184)