大组是如何分活,协同工作的?

[chaleaochexist]

一开始
小组后端就俩人.一个为主(楼主),一个打杂.
现在项目扩大.
将来可能要将近 10 个人.

每个人的代码风格都不一样(python). 将来很容易乱套啊.领到的意思是, 不用分那么细.大家的活大家一起干.
但是风格不统一,很糟糕啊 .
举个例子.
django drf 的 serializer 只有我一个人再用. viewset,也只有我一个人再用.
其他人都是基于 apiView 在写.
另外还有一部分人连 django orm 都不用. 直接裸 sql.
目前组内规模 4 个后端, 本人不是领导.这事儿我不吱声,也没啥大事.
可预见的将来,组内最懂 django 的应该还是我. 我不提,大家应该是意识不到这个问题.(我猜的)

1. 如何分工,能把自己摘出去,自己代码自己维护?
2. 如何统一风格?
3. 三字真言?

谢谢

[chaleaochexist]

另外,本人之前的工作经历也一直是几个人做,最多 3 个人,没有大组工作经历.

[chaleaochexist]

还有领导是真牛逼(褒义)

前端出身, 现在是全栈, django 用的不熟, 自己手撸了一个阉割版除了他自己别人看不懂的 orm.
还要很多 drf 提供的功能不用,自己手撸.
撸的不好用啊...主要是...

[MMMMMMMMMMMMMMMM]

大多公司都是模块化

一人写 common，其他人拧螺丝

各管各，尽量别动别人代码

[gz911122]

我们是 java
但是可以参考一下,我们组是做支付的
基本两个人为一小组来负责 3~4 个服务

代码风格之类的有插件来保证.
依赖库之类的优先用公司通用的,特殊的在技术评审上来说明采用的原因和目的

[Hopetree]

django 也是按照 app 来划分吧，其实就是模块化，反正保证路由接口都是 OK 就行，谁写的谁负责改问题就不大

[gz911122]

接楼上,我们组目前 13 个人..

然后两个人左右为一小组(单元)的话正好还能相互 review,以及在有人请假的时候出问题不至于谁也不知道怎么办之类的

[chaleaochexist]

@gz911122 插件能保证的是编码风格,但是不能保证逻辑. 譬如,有人用 mybatis,有人直接 JDBC 裸 sql.

[gz911122]

@chaleaochexist
这种靠 code review 和技术评审了

[bobuick]

换语言. 超过 10 人的 python 团队, 对人员素质要求变高很多.
python 是个看视简单, 实际非常挑人的技术活

[azcvcza]

动态语言不都是要上 linter 来确保风格一致吗,
规范之类的要领导发布，例如不能裸拼 SQL，页面怎么写，等等等等
分工 的话，分模块吧，那块崩了就找谁，事先做好约定？

[cydleadingx]

先讨论或者直接定义出一份 code style
技术评审 /code review 搞起来
必须 很多人 都 approve 了 才能 merge
这种会导致项目进度 刚开始慢一些

[whywhywhy]

我们的乙方估计就一两个开发，其他的实施兼二次开发。

他们时不时就把对方代码覆盖。

牛 X，于是苦了我们的数据。

终于他们后面统一了。。。

不知道为什么有的代码还是不见了。

[linZ]

@gz911122 code review 需要过逻辑么。。。那不是过起来要好久

[iPhoneXI]

python ？格式之类 black 一把梭，不准有异议，
其他风格搞个内部规范，不在规范内的随便发挥

[xulolololololo]

最好不用 django serializer 之类的吧，自由度受限，我现在规模 35 人左右的 py 后台开发团队，写一个通用的 baseview，其他人继承一下，这个 baseview 有通用的参数类型检验，和 jsonrespone 之类的方法，新来一个程序猿，熟悉一周业务开始干活，还是很快的

[xulolololololo]

直接裸写 sql 的组员赶紧辞掉吧

[hmxxmh]

@xulolololololo 这啥逻辑，裸写 sql 不用 orm 也有错。只要业务与数据分离就还好吧

[hmxxmh]

我现在也遇到了你的问题，一个项目五个后段，一开始也没有设计数据库，基本上是先分模块，然后自己的模块需要的表自己建……，写完自己测，再与前端对接

[gz911122]

@linZ 过啊

很快的啊.因为项目很熟悉,再加上一般一个版本改动的文件也就几个到十几个之间

[Leigg]

需要统一！这时候老大得有，要么你去提议做代码评审