V2EX = way to explore
V2EX 是一个关于分享和探索的地方
现在注册
已注册用户请  登录
charlesliu
V2EX  ›  前端开发

一个合格、负责的小公司前端负责人应该做哪些事情,把精力放在什么地方

  •  
  •   charlesliu · 2022-10-08 16:58:05 +08:00 · 1828 次点击
    这是一个创建于 778 天前的主题,其中的信息可能已经有所发展或是发生改变。

    我们公司是做 ToB 的项目,目前前端是 5-10 人的规模,技术要求并不算复杂,以 react 栈为主,基本上都是在使用开源的库和框架,业务发展节奏比较慢,大家基本都是下班就走。我基本上也不太管大家,只要没有耽误上线,生产环境不报错就行。但这样的问题就是,

    1. 项目质量越来越差,有很多不好的代码,例如违反了 DRY 原则,滥用 any 类型,缺少单元测试 /集成测试
    2. 大家的水平停步不前,因为大家的心态都是只要能通过测试就行
    3. 留不下好的员工,有些人是希望在工作中有所收获的,长此以往,他们就会离开

    诚然换一个平台是可以的,但是我现在还在这里,还是想做一些事情,因此问下大家,你觉得一个合格、负责的小公司前端负责人应该做哪些事情,把精力放在什么地方?视角不限。

    11 条回复    2022-10-10 12:22:38 +08:00
    cxe2v
        1
    cxe2v  
       2022-10-08 17:42:21 +08:00
    作为一个曾经干过这个岗位的人来说一下,
    1 跟 2 从招人开始筛选,一定要筛选平时写代码就有良好习惯的人,你需要拟定一份你认为需要遵守的代码规范,并且同时配合各种代码工具对代码进行检查,不符合要求无法进行提交,同时也需要时不时 review 防止有逻辑上的问题

    至于留不下人,这不是你能决定的,有些热血上进的人,迟早会从你这里飞走,不过是早于晚的问题,而且,你不觉得这条跟你说的第二条冲突?又要别人有进步,又不希望别人进步后离开,那你能同步提供待遇上的进步吗?
    wu67
        2
    wu67  
       2022-10-08 20:07:21 +08:00
    核心代码要你掌控住, 然后把业务捋顺, 能做到突然跑路几个人你能在短时间内扛住、持续到招到新人维持业务代码就行.

    如果要管代码质量, 建议是整整技术分享, 你自己先带个头. 如果队友经常写 any script 、前端应该也不怎么写测试(/🐶), 那还不如不要 ts, 毫无存在感的, 反而是阅读代码时多了一堆东西, 眼花缭乱

    非要较真的话, 那就整代码 review, 写得太烂的直接不让提交, 不过会直接拉低开发速度(我是说速度, 不是效率), 甚至混乱佛系队友可能会选择跑路...

    如果有别的就是职场通用技能了, 我也不会, 20 几岁一个人, 我也吹不出来啥
    Torpedo
        3
    Torpedo  
       2022-10-08 20:18:01 +08:00
    组织一下 cr 会。在会上轮流 cr 某个人的代码

    其实业务的 cr 不一定可取,只能通过这种会大致轮流看下每个人的代码

    另外技术分享要定期做,也是传播正确的代码风格和写法
    GP1
        4
    GP1  
       2022-10-08 20:54:06 +08:00
    加钱
    kkeep
        5
    kkeep  
       2022-10-09 01:20:19 +08:00 via Android
    规范
    xiaojie668329
        6
    xiaojie668329  
       2022-10-09 02:41:20 +08:00 via iPhone
    code review 很重要。
    codeDreamfy
        7
    codeDreamfy  
       2022-10-09 08:28:17 +08:00 via iPhone
    统一规范,UI 组件等还是有很多事情可以做起来
    charlesliu
        8
    charlesliu  
    OP
       2022-10-09 10:49:27 +08:00
    确实有我表达不准确的问题,团队水平参差不齐,有优秀的,有普通的,还有那种非常一般的,对于那些优秀的人,对自己的要求都比较高,但还是有一部分人是不太关心代码质量,只要需求验收能通过就好,人员素质有些也不是我能控制的 T_T 。

    不过我突然又觉得,既然现在工作流程比较稳定,那又何必再调想这想那,大家有时间愿意看书的就看书,愿意摸鱼就摸鱼,好像也没什么问题,写的代码不出问题就行,莫非无为而治才是答案...
    charlesliu
        9
    charlesliu  
    OP
       2022-10-09 11:11:23 +08:00
    code review 有用,但不完全有用,因为有时会受上线压力影响,无法保证所有提出问题的地方都改掉,只能说找时间优化一下,但是就很可能放在那里再也没动过了。

    不过代码质量还是要有一条底线的,同意 2 楼所言,核心代码自己来掌控放心,这里的代码是不能妥协的。
    br_wang
        10
    br_wang  
       2022-10-09 18:57:39 +08:00
    重要的是团队有个对代码质量的共识:怎么写是 90 分,怎么写是不合格。

    周期性的 code review 和维护、更新规范都是践行此共识的持续性团队行为。

    团队成员除了技术能力,协作能力和对共识的认知和践行都应该是考核的因素。

    「因为有时会受上线压力影响,无法保证所有提出问题的地方都改掉,只能说找时间优化一下,但是就很可能放在那里再也没动过了。」那就周会上花十分钟来追踪这个问题,责任到人,为什么没有修改,给出修改完成时间点,完成与否有奖惩,追两个月试试看。
    kamilic
        11
    kamilic  
       2022-10-10 12:22:38 +08:00
    理解你,我干了一年多,然后把自己干走了,也跟你遇到的情况差不多。T _ T
    1/2. 只能加强规范还有多做 code review 了,简单来说就是多管理质量,多抓质量,让成员感受到你关注这方面。这个就是吃力不讨好了,和多费嘴皮子。看你现在描述的情况,肯定团队里面有着一些「又不是不能用」的观点。
    赞同上面说的,找到一些负责任和有追求的人是更好的,他们不需要花费那么多口水来说明规范和质量标准的重要性。
    3. 这个很难,好的员工都是有追求的,我的理解就是给予成员一个角色,让他感受到自己在团队的意义。我也是当了这段时间才明白,要画一个好的饼子也是有技术水平的。
    关于   ·   帮助文档   ·   博客   ·   API   ·   FAQ   ·   实用小工具   ·   870 人在线   最高记录 6679   ·     Select Language
    创意工作者们的社区
    World is powered by solitude
    VERSION: 3.9.8.5 · 29ms · UTC 20:59 · PVG 04:59 · LAX 12:59 · JFK 15:59
    Developed with CodeLauncher
    ♥ Do have faith in what you're doing.