这是一个创建于 1100 天前的主题，其中的信息可能已经有所发展或是发生改变。
我们公司是做 ToB 的项目，目前前端是 5-10 人的规模，技术要求并不算复杂，以 react 栈为主，基本上都是在使用开源的库和框架，业务发展节奏比较慢，大家基本都是下班就走。我基本上也不太管大家，只要没有耽误上线，生产环境不报错就行。但这样的问题就是，
- 项目质量越来越差，有很多不好的代码，如违反了 DRY 原则，滥用 any 类型，缺少单元测试 /集成测试
- 大家的水平停步不前，因为大家的心态都是只要能通过测试就行
- 留不下好的员工，有些人是希望在工作中有所收获的，长此以往，他们就会离开
诚然换一个平台是可以的，但是我现在还在这里，还是想做一些事情，因此问下大家，你觉得一个合格、负责的小公司前端负责人应该做哪些事情，把精力放在什么地方？视角不限。
 | 1 cxe2v 2022-10-08 17:42:21 +08:00 作为一个曾经干过这个岗位的人来说一下， 1 跟 2 从招人开始筛选，一定要筛选平时写代码就有良好习惯的人，你需要拟定一份你认为需要遵守的代码规范，并且同时配合各种代码工具对代码进行检查，不符合要求无法进行提交，同时也需要时不时 review 防止有逻辑上的问题 至于留不下人，这不是你能决定的，有些热血上进的人，迟早会从你这里飞走，不过是早于晚的问题，而且，你不觉得这条跟你说的第二条冲突？又要别人有进步，又不希望别人进步后离开，那你能同步提供待遇上的进步吗？ |
 | 2 wu67 2022-10-08 20:07:21 +08:00 核心代码要你掌控住, 然后把业务捋顺, 能做到突然跑路几个人你能在短时间内扛住、持续到招到新人维持业务代码就行. 如果要管代码质量, 建议是整整技术分享, 你自己先带个头. 如果队友经常写 any script 、前端应该也不怎么写测试(/), 那还不如不要 ts, 毫无存在感的, 反而是阅读代码时多了一堆东西, 眼花缭乱 非要较真的话, 那就整代码 review, 写得太烂的直接不让提交, 不过会直接拉低开发速度(我是说速度, 不是效率), 甚至混乱佛系队友可能会选择跑路... 如果有别的就是职场通用技能了, 我也不会, 20 几岁一个人, 我也吹不出来啥 |
 | 3 Torpedo 2022-10-08 20:18:01 +08:00 组织一下 cr 会。在会上轮流 cr 某个人的代码 其实业务的 cr 不一定可取，只能通过这种会大致轮流看下每个人的代码 另外技术分享要定期做，也是传播正确的代码风格和写法 |
 | 4 GP1 2022-10-08 20:54:06 +08:00 加钱 |
 | 5 kkeep 2022-10-09 01:20:19 +08:00 via Android 规范 |
 | 6 xiaojie668329 2022-10-09 02:41:20 +08:00 via iPhone code review 很重要。 |
 | 7 codeDreamfy 2022-10-09 08:28:17 +08:00 via iPhone 统一规范，UI 组件等还是有很多事情可以做起来 |
 | 8 charlesliu OP 确实有我表达不准确的问题，团队水平参差不齐，有优秀的，有普通的，还有那种非常一般的，对于那些优秀的人，对自己的要求都比较高，但还是有一部分人是不太关心代码质量，只要需求验收能通过就好，人员素质有些也不是我能控制的 T_T 。 不过我突然又觉得，既然现在工作流程比较稳定，那又何必再调想这想那，大家有时间愿意看书的就看书，愿意摸鱼就摸鱼，好像也没什么问题，写的代码不出问题就行，莫非无为而治才是答案... |
| 9 charlesliu OP code review 有用，但不完全有用，因为有时会受上线压力影响，无法保证所有提出问题的地方都改掉，只能说找时间优化一下，但是就很可能放在那里再也没动过了。 不过代码质量还是要有一条底线的，同意 2 楼所言，核心代码自己来掌控放心，这里的代码是不能妥协的。 |
 | 10 br_wang 2022-10-09 18:57:39 +08:00 重要的是团队有个对代码质量的共识：怎么写是 90 分，怎么写是不合格。 周期性的 code review 和维护、更新规范都是践行此共识的持续性团队行为。 团队成员除了技术能力，协作能力和对共识的认知和践行都应该是考核的因素。 「因为有时会受上线压力影响，无法保证所有提出问题的地方都改掉，只能说找时间优化一下，但是就很可能放在那里再也没动过了。」那就周会上花十分钟来追踪这个问题，责任到人，为什么没有修改，给出修改完成时间点，完成与否有奖惩，追两个月试试看。 |
 | 11 kamilic 2022-10-10 12:22:38 +08:00 理解你，我干了一年多，然后把自己干走了，也跟你遇到的情况差不多。T _ T 1/2. 只能加强规范还有多做 code review 了，简单来说就是多管理质量，多抓质量，让成员感受到你关注这方面。这个就是吃力不讨好了，和多费嘴皮子。看你现在描述的情况，肯定团队里面有着一些「又不是不能用」的观点。 赞同上面说的，找到一些负责任和有追求的人是更好的，他们不需要花费那么多口水来说明规范和质量标准的重要性。 3. 这个很难，好的员工都是有追求的，我的理解就是给予成员一个角色，让他感受到自己在团队的意义。我也是当了这段时间才明白，要画一个好的饼子也是有技术水平的。 |
Select Language