这是一个创建于 1934 天前的主题，其中的信息可能已经有所发展或是发生改变。
一开始
小组后端就俩人.一个为主(楼主),一个打杂.
现在项目扩大.
将来可能要将近 10 个人.
每个人的代码风格都不一样(python). 将来很容易乱套啊.领到的意思是, 不用分那么细.大家的活大家一起干.
但是风格不统一,很糟糕啊 .
举个例子.
django drf 的 serializer 只有我一个人再用. viewset,也只有我一个人再用.
其他人都是基于 apiView 在写.
另外还有一部分人连 django orm 都不用. 直接裸 sql.
目前组内规模 4 个后端, 本人不是领导.这事儿我不吱声,也没啥大事.
可预见的将来,组内最懂 django 的应该还是我. 我不提,大家应该是意识不到这个问题.(我猜的)
1. 如何分工,能把自己摘出去,自己代码自己维护?
2. 如何统一风格?
3. 三字真言?
谢谢
小组后端就俩人.一个为主(楼主),一个打杂.
现在项目扩大.
将来可能要将近 10 个人.
每个人的代码风格都不一样(python). 将来很容易乱套啊.领到的意思是, 不用分那么细.大家的活大家一起干.
但是风格不统一,很糟糕啊 .
举个例子.
django drf 的 serializer 只有我一个人再用. viewset,也只有我一个人再用.
其他人都是基于 apiView 在写.
另外还有一部分人连 django orm 都不用. 直接裸 sql.
目前组内规模 4 个后端, 本人不是领导.这事儿我不吱声,也没啥大事.
可预见的将来,组内最懂 django 的应该还是我. 我不提,大家应该是意识不到这个问题.(我猜的)
1. 如何分工,能把自己摘出去,自己代码自己维护?
2. 如何统一风格?
3. 三字真言?
谢谢
第 1 条附言 · 2019-09-05 11:10:14 +08:00
其实楼主在问两个问题.
1. 技术问题,如何处理? -- 其实楼主已经有答案了, java 这类可能可以用编译器(Java 的接口泛型 Spining)约束.python 很难.
2. 这是一个职场话题,楼主,现在应该咋做呢?管好自己就行了?
1. 技术问题,如何处理? -- 其实楼主已经有答案了, java 这类可能可以用编译器(Java 的接口泛型 Spining)约束.python 很难.
2. 这是一个职场话题,楼主,现在应该咋做呢?管好自己就行了?
 |
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
接口丰富一下，统一成插件标准，各写各的。
|
Select Language