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

• 请不要在回答技术问题时复制粘贴 AI 生成的内容

This topic created in 2468 days ago, the information mentioned may be changed or developed.

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

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

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

谢谢

Supplement 1 · Sep 5, 2019

其实楼主在问两个问题.
1. 技术问题,如何处理? -- 其实楼主已经有答案了, java 这类可能可以用编译器(Java 的接口泛型 Spining)约束.python 很难.
2. 这是一个职场话题,楼主,现在应该咋做呢?管好自己就行了?

django

代码

将来

Python

24 replies • 2019-09-05 13:42:54 +08:00

chaleaochexist

Sep 4, 2019

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

chaleaochexist

Sep 4, 2019

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

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

MMMMMMMMMMMMMMMM

Sep 4, 2019

大多公司都是模块化

一人写 common，其他人拧螺丝

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

gz911122

Sep 4, 2019

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

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

Hopetree

Sep 4, 2019

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

gz911122

Sep 4, 2019

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

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

chaleaochexist

Sep 4, 2019

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

gz911122

Sep 4, 2019

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

bobuick

Sep 4, 2019

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

azcvcza

Sep 4, 2019

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

cydleadingx

Sep 4, 2019

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

whywhywhy

Sep 4, 2019 via Android

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

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

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

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

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

linZ

Sep 4, 2019

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

iPhoneXI

Sep 4, 2019

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

xulolololololo

Sep 4, 2019

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

xulolololololo

Sep 4, 2019

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

hmxxmh

Sep 4, 2019 via Android

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

hmxxmh

Sep 4, 2019 via Android

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

gz911122

Sep 4, 2019

@linZ 过啊

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

Leigg

Sep 4, 2019 via Android

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

whusnoopy

Sep 5, 2019

Python 在项目大了或人多了后，管理起来是相对麻烦点，这时候比较考验人的素质，大家都有协同意识，或愿意接受统一，那就是提前沟通一下确定好标准，否则靠工具撑死也就保持个代码风格，逻辑风格啥的完全管不住

DoctorCat

Sep 5, 2019

业务背景没有的情况下，姑且认为你们每个人可以独立负责一个服务，各自约定各自的接口，先文档化（要顾及性能要求、调用限制等详细的 API 设计约束条件），然后照着文档各自开发各自的。

技术栈需要约定，不然队友离职后，挖出的坑，你们老板（或交接人）会很抓狂。建议设立 CodeReview 流程，push 到仓库的代码必须是经过他人 review 过的。

非要总结出三字，那就是：责（各自负责各自的服务）、约（约定好技术规范和业务接口设计标准）、审（做代码审查）

DoctorCat

Sep 5, 2019

btw：软件工程本质上还是人的问题，不太可能达到完美状态，利用合理的工具和约定，尽量减少技术负债与沟通成本

starsriver

Sep 5, 2019 via Android

接口丰富一下，统一成插件标准，各写各的。