这是一个创建于 809 天前的主题，其中的信息可能已经有所发展或是发生改变。
在小规模团队中，招聘开发的标准应该包含比如不少于 5 年工作经验、代码风格优雅、有一定架构经验等，这样可以保证每个成员都可以独立开发并且保证质量。一般来说，小团队对新手的容忍度较低，只有中型团队以上可以考虑培养新手。
团队开发工作一旦分工完成，成员所负责的代码部分应该不允许他人修改，除非是在得到了充分沟通和授权的情况下。如果其他成员发现其代码问题，应当指出并由该成员自主修改。在团队成员长期稳定的情况下，成员所负责的代码应该与该成员长期绑定，实现成员对代码“终身负责“和风格统一的问题。有的公司规模不小但是流动率超高，每个人都抱着最快完成任务而不在意代码质量的想法，导致项目可维护性极差，甚至无法维护，而重构的代价是比较大的。（不过对于这种公司来说他们的产品可能是一锤子买卖）
对于开发工程师来说，光速交付然后快速重构的模式可能是非常恼人的，因为这样会让人觉得疲惫，且开发过程中不慎愉悦。当然付钱的是老板，很多时候开发工程师并没有选择。不过在一些传统行业中，很多时候软件是具备充足的开发时间的，这时候选择精雕细琢显然是两全其美的事情。
第 1 条附言 · 2022-09-14 10:13:36 +08:00
招聘的时候就已经充分考虑了楼上说的问题，首先团队成员都有很强的自觉性，不存在写成“屎山”的问题，大家都是对代码质量有一定追求的人；其次，团队内部分工确实是五个人独立开发的，每个人开发的代码对于其他人都是黑盒，只要约定接口、处理好线程等问题就可以；最后团队不追求统一风格，团队的理念是给每个人充分的发挥空间，保持自己的特性。
 |
1
Navee 2022-09-14 09:30:24 +08:00
gitlab
protect branch merge request code review |
 |
2
lcy630409 2022-09-14 09:33:03 +08:00  1
感觉有个问题
5 人小团队 一般订单不多，还要保证不少于 5 年工作经验，养得起么 代码终身负责 也会带来一个问题，每个人都有代码风格，说不好听点 叫癖好吧，，如果不让其他人插手 就会导致 shi 山 越来越高，后续这个人离职怎么办？ shi 山代码 一般都是一个人堆出来的，多人参与的代码 shi 山几率小，有问题会有大概率被发现出来 |
 |
3
golangLover 2022-09-14 09:44:47 +08:00 via Android 3
反了。小团队给不起钱，都是找低水平的
|
 |
4
nothingistrue 2022-09-14 09:45:38 +08:00 2
“谁编码谁负责”可不是让你这样搞的，结对编程或者相互代码评审才是保证代码风格的途径。你这样搞是 5 个独立的人在开发，不是 5 人团队在开发。
|
 |
5
Cbdy 2022-09-14 09:47:01 +08:00 via Android
GitHub
|
 |
6
god7d OP @lcy630409
@golangLover @nothingistrue 看行业，很多传统制造业上千人，养 5 个人做个内部系统应该不成问题吧？可能你们一说软件就代入到互联网行业。在传统行业里，工作清闲朝九晚五，工资开的虽然没有互联网高，但是足以招到一些水平不错，代码风格良好的程序员了 |
 |
7
h1104350235 2022-09-14 10:00:58 +08:00
过于理想化
|
 |
8
jones2000 2022-09-14 10:06:56 +08:00
基本就是钱的问题，5 年工作经验老手， 每个 6w/月要的吧，1 个月就要 30W ，1 年下来就要 360W ，还不包括 5 险 1 金。只要你钱给足，你要怎么管理代码都可以。
|
 |
9
daimubai 2022-09-14 10:09:13 +08:00 10
5 年工作经验老手， 每个 6w/月要的吧。
张嘴就来 |
 |
10
zhujq 2022-09-14 10:12:13 +08:00
5 年就要 6w 了啊，真好
|
 |
11
beiyu 2022-09-14 10:13:13 +08:00
5 年才 6W/月？少说得要个 10w 吧。
|
 |
12
king888 2022-09-14 10:15:05 +08:00
低情商在扯淡，高情商过于理想化
|
|
13
king888 2022-09-14 10:16:29 +08:00 1
每个人开发的代码对于其他人都是黑盒。。。这还是团队嘛，就算是保密项目也没这么搞
|
 |
14
darkengine 2022-09-14 10:19:11 +08:00
这样的团队 OP 你组建出来了吗？
我目前见到的小团队，都是一两个 5 年以上经验的人，带其他新人做。 |
 |
15
Torpedo 2022-09-14 10:23:27 +08:00
@golangLover 我觉得同事水平低，也是有办法让他们保持一致的代码风格的。如果能意识到团队代码风格有问题，又不能解决，那说明水平和所谓水平低的同事们没太大差别
|
 |
16
VictorJing94 2022-09-14 10:25:57 +08:00
@jones2000 ...老哥啥坐标啥行业...五年国内新一线一般也就 15-25 吧,高低都还有比较大浮动空间
|
 |
17
ChenDJ 2022-09-14 10:27:53 +08:00 1
借楼吐个槽，实验室环境，代码靠 U 盘在几个师兄弟之间同步，曾力推 gitlab ，小导直接把 build 文件夹传上去 T_T
|
 |
18
daliusu 2022-09-14 10:32:32 +08:00
就我在成都的经验，能做到你说的这些的，不会来你个 5 人团队。另外别太看不起传统工厂了，传统工厂也起码几十个码农，而且根本没有你这么做的，我从到成都就一直在传统厂干
|
|
19
god7d OP @king888 这里的黑盒指的是不关心实现，只关心如何调用，所以你可能理解上存在一定偏差
@darkengine 我们这边都是 10 年以上的作 leader ，带一群 5 年左右的 @daliusu 我完全没说看不起啊，我是说传统制造业养 5 个完全不成问题😅 @ChenDJ 没有 git 不成方圆，以前同事有用 tfs 的，有用 svn 的，现在大家统一用 git |
 |
21
wu00 2022-09-14 10:51:25 +08:00
6 人团队，4 后 2 前
gitlab flow 、mr 、code review 、ci/cd 后端严格执行，有建立统一技术规范、编码风格等内部文档，堆了 2 年的代码，还很清爽。 前端仅使用 gitlab 做仓库和自动化部署，堆了一年已成屎山 |
 |
22
shijingshijing 2022-09-14 10:52:56 +08:00
**招聘的时候就已经充分考虑了楼上说的问题，首先团队成员都有很强的自觉性，不存在写成“屎山”的问题，大家都是对代码质量有一定追求的人；**
----------------------------------------- 盲目自信，“屎山”是相对的，即使是一个设计优良的系统，如果对应的业务飞速成长，后续也存在小马拉大车的问题，更不谈这个过程中一直存在的修修补补，哪怕不是“屎山”，掺入越来越多的老鼠屎也是不可避免的。 代码质量是个比较笼统的概念，是性能很好？是扩展性好？是可读性很好？还是 bug 很少？目前，我见到的几乎没有全面兼顾的，即使是开源的巅峰 Linux 内核这样的项目，特别是接近硬件的部分，里面也有一堆骚操作。 **其次，团队内部分工确实是五个人独立开发的，每个人开发的代码对于其他人都是黑盒，只要约定接口、处理好线程等问题就可以；** ----------------------------------------- 这一段几乎就可以确定，日后项目成为“屎山”是必然，黑盒意味着日常开发别人做 code review 无从下手，紧急时刻别人无法替补，人员离职别人无法接手。 **最后团队不追求统一风格，团队的理念是给每个人充分的发挥空间，保持自己的特性。** ----------------------------------------- 成为“屎山”条件+1 ，意思是给程序员最大的自由度吧，但是自由是有条件的，Linux 内核不仅想要 Merge 进主分支不仅要符合严格的内核代码风格规范，https://www.kernel.org/doc/html/v4.10/process/coding-style.html ，还要担心 Linus 这种仁慈的独裁者随时邮件骂你。软件工程的最高境界就是整个项目仿佛一个人写出来的，这个人的水平处于团队中上等级。 |
|
23
shijingshijing 2022-09-14 10:54:41 +08:00
写点小工具还可以，大点的项目，几乎不可能。
|
 |
24
dayeye2006199 2022-09-14 10:56:52 +08:00
团队的水平方差甚至比均值有时候更重要
|
 |
25
HugoChao 2022-09-14 10:57:55 +08:00
20 个人的团队算小还是中？
|
|
27
god7d OP @shijingshijing 写的很好，领教了。我们这边业务量很小，基本上就是把固定的几个功能尽量优化。即便有新项目其实对于开发这边来说意义不大，因为使用的基础设施还是老一套，一般重新套个壳子就可以了，所以重心还是维护那些基础设施，比如核心算法、把三方库替换成自己造的轮子等等。至于说自由度的问题，主要是为了营造宽松氛围，因为工资不高等客观因素，需要提供其他方面的条件，但是就公司里的人来说，本身也比较散漫自由。但你的回复依然非常有意义，非常感谢。
@wu00 我们这边的项目不是严格意义上的工程项目，带有科研性质，成员除了写代码还要做实验分析数据 |
 |
28
CaptainD 2022-09-14 11:25:53 +08:00
我们就是 5 人左右的小团队，但是公司系统较简单，可能管理方式没你说的那么复杂，但有一点相同，也都是黑盒开发，自己负责自己的代码，这里有个问题，如果某个人离职怎么办，且不说能否找到合适的人，就算有新人来未必很快上手，而且其他成员对离职者的代码并不了解，甚至负责的方向有很大差别，技术栈完全不同，容易有交接问题
|
 |
29
shaojz2005 2022-09-14 11:31:20 +08:00 1
看行业，很多传统制造业上千人，养 5 个人做个内部系统应该不成问题吧？可能你们一说软件就代入到互联网行业。在传统行业里，工作清闲朝九晚五，工资开的虽然没有互联网高，但是足以招到一些水平不错，代码风格良好的程序员了
============= 实际上没那么理想的。 传统制造业，很多软件可以外包或者买现成的产品。 传统制造业，对技术的追求没那么高，待遇不会很高，招不到合适的人。 还有个很致命的问题，在于传统制造业的业务需求的扩展性不是很大，因此技术氛围也很差。等软件稳定成熟之后，剩下的人会陷入工作量不大的状态。闲则生变，要么是领导觉得人太闲可以炒了，或者是人自己觉得太闲、上升空间不大，也跑了。剩下的都是老油条，也就不要想什么开发的精益求精了。 要实现这样的目标，需要有一个非常靠谱的技术负责人，对技术有追求，但又不大想去大厂打拼了，往往是本地人、名牌大学毕业、有家庭这种，那么他就有长期留在一个地方的心态，并且可以带领团队追求高质量的软件开发，也不怕人员流动。 这样的状态，其实是可遇不可求的。 |
 |
30
cubecube 2022-09-14 11:35:01 +08:00
不会不存在屎山问题，一个人觉得是金矿，另一个人没准会觉得是屎山。
代码风格的统一需要团队负责人规划实施 |
|
33
god7d OP 1
@CaptainD 我们这边非常依赖架构师，他会对所有人的代码进行 review ，然后每个人也会持续不断的进行技术文档更新，因此有人离职几乎都不需要交接；技术栈的问题有人离职架构师会暂时接手这些工作。btw ，我感觉我工作三分之一时间都在写文档，这边的文档可以用海量来形容，从专利说明书到每个人的技术文档、代码笔记、通讯协议文档、技术对接文档、技术支持文档等等都需要开发来完成，而且是一直更新的
|
|
34
god7d OP @shaojz2005 你说的很对，看楼上对 captainD 的回复，我们这边架构师就是你说的这种人，说这个架构师是整个团队的灵魂也不为过
|
 |
35
lengyuqu 2022-09-14 11:57:07 +08:00 1
团队不大
1 ，推荐使用 gitea 作为代码管理工具，对配置要求低，甚至最后整个软件仓库都可以备份好。 2 ，推荐准备一台极空间 nas 作为文件服务，主要是文件的储存。这涉及到线上代码原版备份和文档备份。 |
 |
36
lixintcwdsg 2022-09-14 13:23:52 +08:00
1. 小团队水平低。
2. 可以做 cr 并且管控这么细致的架构师，小团队用不起。 3. 小团队最重要的是产品然后还有销售。代码黑盒测可以接受就星。 最后，大公司小团队没办法讲，那属于大团队。 事实如此，真的小团队哪能这么养研发，太理想化了。如果有，那么是业务性质绝对的，本来就利润厚且稳定，而不是因为你这么开发管理导致的果。 |
 |
37
theguagua 2022-09-14 15:15:25 +08:00
@VictorJing94 坐标一线，5 年怎么说 20+了，三年 15+差不多，抛开重大厂不谈
|
 |
38
eric614802 2022-09-14 15:24:07 +08:00
|
|
39
jones2000 2022-09-14 20:28:26 +08:00
@daimubai 5 人稳定开发团队， 工资如果不对标大厂， 你前脚刚组好团队，后脚就被人挖走了。你如果 1 ，2W 招的人， 人员流动性很大，代码质量更不好管理，都是屎山。人员稳定才能确保代码质量比较稳定。
|
 |
41
luomu24 2022-09-14 20:46:13 +08:00
老实讲，这样的团队和薪资好招到匹配的目标成员吗？
|
 |
42
GP1 2022-09-14 20:51:24 +08:00
不可能三角了解一下。
|
 |
43
qile1 2022-09-14 22:16:15 +08:00 via Android
阿里的云效有没有用过，只是代码管理应该也省事
|
|
44
jones2000 2022-09-14 23:27:19 +08:00
@VictorJing94 金融，量化交易
|
 |
45
cepro 2022-09-15 00:23:35 +08:00
主要看这 5 人团队是否从事的是同一个工种的工作。比如都是 Android 、都是 Web 前端、都是后端、都是数据分析等。
如果这 5 个人，各自独当一面，只能从人员角度去保证。 如果这 5 个人从事同一类工作，那就考验架构师是否能够解构模块，代码是否具有可读性。即使出现人员离职，最多也就是重构模块，相对来说工作量会小很多。 但无论是哪一种，开发过程的文档都是尽量留下来的，尤其是关键的逻辑和流程。 无论薪资高低，水平高低，人员管理总会有疏漏，关键是要能从你（假设你是管理者）这里，在可接受的时间范围内，把窟窿堵上。 |
 |
46
likunyan 2022-09-15 11:54:46 +08:00
一些 eslint ，代码风格修正的用下就可以。
|
Select Language