1
chaleaochexist OP 另外,本人之前的工作经历也一直是几个人做,最多 3 个人,没有大组工作经历.
|
2
chaleaochexist OP 还有领导是真牛逼(褒义)
前端出身, 现在是全栈, django 用的不熟, 自己手撸了一个阉割版除了他自己别人看不懂的 orm. 还要很多 drf 提供的功能不用,自己手撸. 撸的不好用啊...主要是... |
3
MMMMMMMMMMMMMMMM 2019-09-04 16:56:07 +08:00 1
大多公司都是模块化
一人写 common,其他人拧螺丝 各管各,尽量别动别人代码 |
4
gz911122 2019-09-04 16:57:21 +08:00 1
我们是 java
但是可以参考一下,我们组是做支付的 基本两个人为一小组来负责 3~4 个服务 代码风格之类的有插件来保证. 依赖库之类的优先用公司通用的,特殊的在技术评审上来说明采用的原因和目的 |
5
Hopetree 2019-09-04 16:58:31 +08:00
django 也是按照 app 来划分吧,其实就是模块化,反正保证路由接口都是 OK 就行,谁写的谁负责改问题就不大
|
6
gz911122 2019-09-04 16:59:58 +08:00
接楼上,我们组目前 13 个人..
然后两个人左右为一小组(单元)的话正好还能相互 review,以及在有人请假的时候出问题不至于谁也不知道怎么办之类的 |
7
chaleaochexist OP @gz911122 插件能保证的是编码风格,但是不能保证逻辑. 譬如,有人用 mybatis,有人直接 JDBC 裸 sql.
|
8
gz911122 2019-09-04 17:23:12 +08:00
@chaleaochexist
这种靠 code review 和技术评审了 |
9
bobuick 2019-09-04 17:25:33 +08:00
换语言. 超过 10 人的 python 团队, 对人员素质要求变高很多.
python 是个看视简单, 实际非常挑人的技术活 |
10
azcvcza 2019-09-04 17:47:13 +08:00
动态语言不都是要上 linter 来确保风格一致吗,
规范之类的要领导发布,例如不能裸拼 SQL,页面怎么写,等等等等 分工 的话,分模块吧,那块崩了就找谁,事先做好约定? |
11
cydleadingx 2019-09-04 19:36:31 +08:00
先讨论或者直接定义出一份 code style
技术评审 /code review 搞起来 必须 很多人 都 approve 了 才能 merge 这种会导致项目进度 刚开始慢一些 |
12
whywhywhy 2019-09-04 19:41:31 +08:00 via Android
我们的乙方估计就一两个开发,其他的实施兼二次开发。
他们时不时就把对方代码覆盖。 牛 X,于是苦了我们的数据。 终于他们后面统一了。。。 不知道为什么有的代码还是不见了。 |
14
iPhoneXI 2019-09-04 19:59:48 +08:00
python ?格式之类 black 一把梭,不准有异议,
其他风格搞个内部规范,不在规范内的随便发挥 |
15
xulolololololo 2019-09-04 20:13:54 +08:00
最好不用 django serializer 之类的吧,自由度受限,我现在规模 35 人左右的 py 后台开发团队,写一个通用的 baseview,其他人继承一下,这个 baseview 有通用的参数类型检验,和 jsonrespone 之类的方法,新来一个程序猿,熟悉一周业务开始干活,还是很快的
|
16
xulolololololo 2019-09-04 20:19:30 +08:00
直接裸写 sql 的组员赶紧辞掉吧
|
17
hmxxmh 2019-09-04 20:30:12 +08:00 via Android
@xulolololololo 这啥逻辑,裸写 sql 不用 orm 也有错。只要业务与数据分离就还好吧
|
18
hmxxmh 2019-09-04 20:32:35 +08:00 via Android
我现在也遇到了你的问题,一个项目五个后段,一开始也没有设计数据库,基本上是先分模块,然后自己的模块需要的表自己建……,写完自己测,再与前端对接
|
20
Leigg 2019-09-04 21:28:23 +08:00 via Android
需要统一!这时候老大得有,要么你去提议做代码评审
|
21
whusnoopy 2019-09-05 08:33:13 +08:00
Python 在项目大了或人多了后,管理起来是相对麻烦点,这时候比较考验人的素质,大家都有协同意识,或愿意接受统一,那就是提前沟通一下确定好标准,否则靠工具撑死也就保持个代码风格,逻辑风格啥的完全管不住
|
22
DoctorCat 2019-09-05 10:59:01 +08:00
业务背景没有的情况下,姑且认为你们每个人可以独立负责一个服务,各自约定各自的接口,先文档化(要顾及性能要求、调用限制等详细的 API 设计约束条件),然后照着文档各自开发各自的。
技术栈需要约定,不然队友离职后,挖出的坑,你们老板(或交接人)会很抓狂。建议设立 CodeReview 流程,push 到仓库的代码必须是经过他人 review 过的。 非要总结出三字,那就是:责(各自负责各自的服务)、约(约定好技术规范和业务接口设计标准)、审(做代码审查) |
23
DoctorCat 2019-09-05 11:02:14 +08:00
btw:软件工程本质上还是人的问题,不太可能达到完美状态,利用合理的工具和约定,尽量减少技术负债与沟通成本
|
24
starsriver 2019-09-05 13:42:54 +08:00 via Android
接口丰富一下,统一成插件标准,各写各的。
|