• 外包信息请发到 /go/outsourcing 节点。
• 不要把相同的信息发到不同的节点
这是一个创建于 702 天前的主题，其中的信息可能已经有所发展或是发生改变。
行业：半导体集成行业
代码管理：公司服务器搭建的 gogs （完全是存储代码）
项目概况：一人一个项目 从 0 到 1 开发上位机软件
OP 概况：组长，负责项目售前，交付开发，以及组内人员工作分配
目前问题：
-
没有项目交付的时候（项目交付大部分时间都在客户现场出差写软件），组内人基本都在划水（一共 3 个人），工作效率太差。（当然有的时候不划水也没活儿干，可能有的时候看周报一周就做几百行代码的简单事情）
-
代码 review 根本弄不起来，以及项目复盘。想 teamwork 好几年都 work 不起来（行业性质的原因，基本上一人一项目除非有相关项目经验，否则几乎参与不进来）
-
代码迭代难，几乎项目全是根据客户定制的。很难积累到东西复用（脱离硬件代码基本上跑不起来。设备大部分在公司里面都没有）
这些问题苦恼我好久了，想提高部门工作效率感觉好难。望各位大佬赐教！
 |
1
xixibb 2023-01-03 08:51:38 +08:00  25
《当然有的时候不划水也没活儿干，可能有的时候看周报一周就做几百行代码的简单事情》
大家工作的好好的，劳逸结合，偏偏你要多事，要提高什么工作效率，你是股东吗 ？公司是你家开的 ？？？ |
 |
2
3032 2023-01-03 08:54:36 +08:00
别提高那么高得效率 ，给同行一些活路谢谢
|
 |
3
jie170601 2023-01-03 08:57:51 +08:00
（脱离硬件代码基本上跑不起来。设备大部分在公司里面都没有）
有事干了，可以写那些硬件协议的模拟软件😂。 |
 |
4
ligiggy 2023-01-03 09:03:09 +08:00
换个行业吧。
|
 |
5
vruzo 2023-01-03 09:05:52 +08:00 via iPhone 2
现在影响项目交付时间吗？还是说你只是单纯看不惯组员闲呢
|
 |
6
yogogo 2023-01-03 09:09:26 +08:00
还不如想如何提交集体凝聚力？
|
 |
7
wcao 2023-01-03 09:10:53 +08:00
@xixibb +1 ，感觉 OP 就是闲不下来，划水不香么。OP 想找点事情做，去 github 自己搞个项目，把你所有的想法都实现一遍不美滋滋。工作上来说，这不典型的钱多事少么。
|
 |
8
lyusantu 2023-01-03 09:12:04 +08:00
你是组长还是？
|
 |
9
god7d 2023-01-03 09:12:20 +08:00
这种必须到甲方干活的行业确实恶心
|
|
11
wcao 2023-01-03 09:13:27 +08:00
定制+一人 /项目，review 的意义是啥南。反正出了问题找那么写代码的人负责不就行了么。。。表示不理解
|
 |
13
yyysuo 2023-01-03 09:18:21 +08:00
我觉得干活得有结果，如果纯粹是为了折腾员工，那就没必要。
|
 |
21
yolee599 2023-01-03 09:23:22 +08:00 via Android
先看你们公司几个人，十几个人的公司搞这套吃力不讨好，还不如复制备份
|
 |
22
villivateur 2023-01-03 09:24:10 +08:00
一周几百行代码算非常多了，正常人一天写二三十行就很不错了。
除非你写的是那种非常水的代码。 |
 |
25
Corey0606 OP @villivateur 确实都是难度不高的代码，反复造车
|
|
27
god7d 2023-01-03 09:25:17 +08:00
@Corey0606 非标行业没办法，但是没有必要一人一个项目，可以大家一起把一些代码模块化了，然后开发的时候一起开发，维护的时候一人一个项目维护……但是最终，我觉得还是要远离非标……
|
 |
30
crazytudou 2023-01-03 09:28:07 +08:00
有事就干活，没事就划水。
如果有时间，可以考虑做一下轮子，比如基础框架，比如硬件驱动集合工具等。 |
 |
32
litchinn 2023-01-03 09:59:08 +08:00 1
从第一点描述看，这也不是效率高低的问题呀，效率和工作量并没有什么关系吧，也许你是觉得平时没项目交付的时候属于开发空白期不知道该怎么组织大家的工作？
如果真的比较空，领导又支持搞研发氛围的话，可以让组员们选一些前沿的东西进行研究，之后开分享会将各自研究的成果做个分享，文档归档，这对公司来说也是技术积累。前期大家可能不知道怎么下手，你可以跟他们沟通讨论给他们几个选题，后面就可以让他们自己找了。不过前期对你来说可能需要花费较大的时间和精力。 codereview ，`组内有刚毕业的小朋友比较热情老是提建议`，这种情况他可能是工作感觉不到提升，如果真的工作就是很简单也不需要大家有很深的技术那就没啥办法了 `行业性质的原因，基本上一人一项目除非有相关项目经验，否则几乎参与不进来`，这个其实应该就是没有深度工程化的问题，看看这几年的前端的发展就知道了，举个不太恰当的例子，就好比螺丝刀，有那种一把把卖的，也有头部可更换的那种，个东西如果不是对行业有深度了解或者行业里有成熟方案参考的话确实会没什么方向，但是也确实是大有作为的东西 |
 |
34
wu67 2023-01-03 10:10:53 +08:00
又不是前端写 html, 一周的逻辑代码几百行真的不算少了(除非是不动脑的 if else 一把梭), 而且看你描述, 一周几百行还是工作量少的情况下...
|
|
35
wu67 2023-01-03 10:14:24 +08:00
至于 review, 那是需要组内达成了共识的情况下才能推进, 你业务不一样, review 就只能看关键逻辑的代码质量, 然而并不是所有人都喜欢整什么高质量代码, 反正我干活差不多 6 年, 还真见过几个不管质量的家伙, 代码能跑就行...反正只要别叫我接手他的项目, 那我是懒得管了, 我只顾好我要维护的项目...
|
 |
36
q474818917 2023-01-03 10:47:00 +08:00 2
替地主养了几年牛，就觉得牛是他的了
|
 |
37
Meano 2023-01-03 11:05:55 +08:00
自己有意向的话可以自己先搞，达则兼济天下，穷则独善其身，嵌入式 /硬件相关代码也不是一定那么传统，看看 Github 上各大 RTOS 的开源库的协作开发者协作 review 和自动化的 workflow 用的溜溜的
可以你自己过手的项目都能实现自己提交时 review 而且 CI 把源码按需求参数定制化输出，形成理想的版本和变化迭代过程什么的，先自己省事儿了，有工作追求的同事可能会跟着你做，领导看的好可能会帮你推；如果当前工作环境下没有后两者那就对推行事躺平吧，自己爽就好了。 |
 |
38
gongquanlin 2023-01-03 11:14:09 +08:00 9
楼上个别人真是自以为是，脑子有坑。OP 在问“想问一下各位大佬怎么在公司能建立完善的代码管理机制”，一堆人评论“不要内卷”还“替地主养了几年牛，就觉得牛是他的了”。不知道怎么解决问题，就闭嘴少喷多看，整天一堆人跑 V2EX 上来秀下限，什么风气
|
|
39
Corey0606 OP @gongquanlin 说实话我也没搞懂内卷的点
|
 |
41
unco020511 2023-01-03 11:27:20 +08:00
我就说代码 review 这个,最好的办法就是入代码的时候限制 pr mr 这种才能入主分支,所有入的代码必须两位同事看了在之后没问题才点通过.
|
 |
42
nieboqiang 2023-01-03 11:46:02 +08:00
除非大家都需要加班，否则不用思考提升效率问题。
|
 |
43
cbdyzj 2023-01-03 11:46:57 +08:00
直接用 GitHub 吧
|
 |
44
leonshaw 2023-01-03 11:56:02 +08:00
都没活谈什么提高效率
没项目就去找项目 找不到项目就裁人 裁不了人说明人家干的活就值这个价 |
|
45
wcao 2023-01-03 12:01:13 +08:00 3
@Corey0606 领导给压力就没办法了，该搞还是得搞。我现在公司也是接手了 15 年的那种老项目，antd 还在 1.0 。经过了差不多块 3 年时间慢慢升级到了 3.0 。UI 样式也渐渐统一了，别问为啥用 antd 需要统一样式。最开始的项目全部拉源码来自定义，吐了。
没有什么好的建议，说一下我们的优化过程以及目前的一个结果吧，今年 4 月份就 3 年了。 - 不去过渡重构，优化。比如本次需求只改 A ，那么优化的范围只有 A ，不会去优化 B 。好处：测试做验收的时候，可以暴露出来问题。如果改了 B ，测试不会去做相关测试。出了问题很难搞哦（公司没有单元测试、自动化） - prettier 加上去，eslint 先不慌。等 pretter 差不多都好了在加 eslint 。好处：可以先把代码风格给确定下来。git 提交的时候不会有那么多冲突。eslint 因为会检测语法，在代码风格不统一，历史包袱很严重的情况下，用起来很恶心人。到处报错。 - git hooks 先加上 ，每次提交前检测 prettier 。执行一下脚本。保证服务器上的代码风格统一。 - git commit 规范 + 日志 changlog ，这个更多的是增加信心，每隔几个迭代看一下项目日志，成就感就有了。有更多动力去优化。 - 这个比较特殊了，是升级 antd 的，原则就是项目反正都是屎山了。不在乎多一点屎，不删除 antd1.0 的情况下，直接引入 antd3 。需求来了，就把当次需求的 antd1.0 换成 3.0 ，然后参考第一条。（我们是后台管理系统） 好像就这么多，目前已经快 3 年了，只有优化了这些。其他的一些逻辑上的优化还是挺少的。历史包袱太严重，不敢动。有多个文件，单个文件达到 1w 多行，就问你怕不怕。 全是坑，希望能帮助到你。。。 最后还是想说一哈，针对一人维护一个项目的情况，review 真的没必要。反正都是自己管自己，能做到代码风格统一都不错了，还想让我 review 之后，如果有问题让我重写，不可能。哈哈哈 |
 |
46
duke807 2023-01-03 12:18:17 +08:00 via Android
用 gerrit ，必须审核通过才能提交到 git 库，且不会产生多余分支
|
 |
47
akira 2023-01-03 12:47:06 +08:00
参考下同行是怎么做的呢。。。
就你的描述的话 你们其实还是处于手工作坊的模式，这个时候其实缺的不只是代码管理，而是整个开发流程模式都可能需要调整，配套的各种需求缺的就更多了。 |
|
48
Corey0606 OP @wcao 感谢大佬，很用心的回复。我们这边历史问题太多了，得慢慢解决。之前同事离职也是一个 py 文件 1w 多行代码，0 注释根本没法看.
|
 |
50
zw1one 2023-01-03 13:45:12 +08:00
对客户定制化，本来就是挣的外包钱，组员划水客户没意见你有意见干啥？
说点实际的：你想做到客户定制复用的话，需要极强势、极专业的客户对接人员（产品？客户顾问？），提取客户标准需求然后你们再开发个通用的标准版本。通常这不现实，因为给钱的是大爷。 |
 |
51
dlmy 2023-01-03 14:17:08 +08:00
@zw1one 就相当于不同的客户要做 SaaS 定制化，而他们只想做一个通用的 SaaS 系统，能兼容所有客户的定制化需求。这个除非他们公司垄断了整个行业，不然还真的是挺难的。
|
 |
52
dynastysea 2023-01-03 14:44:16 +08:00 1
很多项目的价值根本不需要代码 review 。。。你就是太闲了。
|
|
53
zw1one 2023-01-03 14:50:47 +08:00
@dynastysea 太认可了哈哈哈，一座屎山你非去看它干啥。
|
|
54
zw1one 2023-01-03 14:52:12 +08:00
@lscbqr 是的，我们业务也遇到了这个问题，目前是把客户区分来看，强势的有价值的客户，还是老老实实给他们定制化，有些没牌面的小鱼小虾客户，就丢标准化项目给他们。
|
 |
55
isnullstring 2023-01-03 16:14:49 +08:00
哈哈，目前我就是底下的“组员”，跟设备对接 做非标
review 着实没什么意义，没去过现场，没跟客户沟通过，不具备行业基本术语 很难沟通的 而且设备虽然是同一个厂家，甚至相同型号，不同客户可能有不同的运行逻辑 即便代码完全开放，估计也知其然不知其所以然 你还好 有上司 支持，我想打造一个通用的类库、UI 等，任何项目上手都可以快速完成基本的数据展示等等，奈何上司只求快，完全不管复用 |
|
56
Corey0606 OP @isnullstring 哈哈，吓得我赶紧点开了你的主页。我们尝试过通用的 UI 类库，再绝对定制面前根本不成立
|
|
57
isnullstring 2023-01-03 16:24:25 +08:00
|
|
58
Corey0606 OP @isnullstring 哎，我们也差不多，现在领导为了验收都承诺永久升级，说白了就是验收以后还可以改需求。
|
 |
59
allgy 2023-01-03 16:57:05 +08:00
小公司别跟自己找麻烦
|
 |
61
sherlockwhite 2023-01-03 17:25:29 +08:00
领导给压力，让他自己来啊，都没活，该干嘛干嘛，不都这么回事，糊弄糊弄领导，还真搞啊
|
 |
62
sampeng 2023-01-03 17:33:33 +08:00
你不是组长。就和你没关系。
当然，我要是组长。我倒喜欢手下是这样的。 做硬件的确实对代码管理概念为 0 。我是觉得和硬件无关，和观念有关。 |
 |
63
tool2d 2023-01-03 17:37:28 +08:00
@Corey0606 “我们尝试过通用的 UI 类库，再绝对定制面前根本不成立"
你这思路不对，软件开发再定制，也需要走上下分层开发模式。 组里能力强的写 API 底层，能力差的调用 API 写逻辑。 平级是最不好的开发模式。前几天 V2 有人发帖，review 同事代码太差，不改怎么办？这问题同样适用 OP ，你遇到烂代码，没办法一句句去改。只能利用开发模式，把写烂代码的人边缘化。 |
|
64
Corey0606 OP @sherlockwhite 真难搞 领导让定义软件框架产品呢
|
 |
65
jones2000 2023-01-03 21:18:43 +08:00
这个主要看公司技术老大的高度了。
1. 首先要有公司自己的公共代码库积累。不要什么都是用别人的。没有技术积累，基本只能干体力活。 2. 对已有的项目的总结和融汇贯通，如楼主是“半导体集成行业”， 那就做一套兼容多个设备的操作代码库，对接完一个设备就整理好加入到公共代码库里， 统一对外接口。 然后做一些简单的 UI 拖拽，就可以选取对应的硬件设备，然后编译出对应这些设备的控制程序。 3. review 这些基本都是形式主义， 大家都是初级的开发， 互相 review 有什么意义呢，就查查单词有没有拼错，格式有没有对齐，浪费时间而已。 最起码 review 代码的人有 5-6 年的开发经验，这个才能给你的代码提建议。 团队好不好，主要看老大， 下面人基本都是给老大打杂的。 |
Select Language