美团骑手团

这个问题（图）是不明确的。
按 MVP 来说，两种都是对的。
如果错的话，或者比较的话，只能说是实现中的侧重点问题。

只有明确 P 是什么，才能选择哪个是“对”的。


如果直观理解，
图 1 是侧重功能的实现；
比如假如产品是支付
那么类比过程就是
线下支付 - 汇款验证 - 第三方转账支付 这样的升级路线；

图 2 是侧重功能的完善；
比如假如产品是支付
那么类比过程就是
密码验证支付 - 指纹支付 - 扫脸支付 这样的升级路线；


换句话说，主要矛盾和矛盾的主要方面，是两个不同层面的东西；

感觉这么做的话，得重写方法，在里面再做一层定义，但应该是挺棘手的。

比如上面说的 django-guardian，你模仿它的做法，然后在对应的 orm crud 方法，做一层判断；

需要判断的信息放进 context 带过去就试试；

网易不用考虑，会踩坑。


西昊一般般，但价格够便宜；

可以考虑金豪 B 或者买个享耀家；

因为是自学状态,没有大佬带路, 想知道写的这些代码有木有不规范的,或者说是不应该这么写等等,一开始就想发在 V2 上,但怕丢人....今天想了想还是发出来, 毕竟大佬们的批评才能让我进步么

如果实话说的话，代码质量有点脏，但对于是自学来说，第一个写的程序，还是很棒的。

如果说代码问题的话，大概可能有这几个方面可以改进

最主要的
- 逻辑
- 规范
- 语法

逻辑上来说，你要写这样的一个东西，可以拆成
获取数据，保存数据，展示数据；
你已经拆成几个类去做是 ok 的，但最后调用是有些怪的，
不如写一个大类，然后再引用对应的模块；
如
app = Lottery()
app.run_ui()

调用之间分离，入口出口收窄；


规范的话，就楼上说的，PEP8


语法的话，就看熟练度了，多看多写就好；

代码质量还有一个问题就是不统一，这个主要是抄（语法）之类，没重新做调整；
也有一个就是，写的过程，为了实现这个放得过重；
可能从怎么实现变为怎么组合，这个角度去思考，代码能够轻灵些；

> 另外想问如果和前端(TypeScript)合作是否合适放在一个仓库内，怎么放比较合适。


放在一起可以的，分支可以这么考虑，适当调整；
main - dev -test - frontend + backend - dev_<user>

代码的话，各自放在项目层
- frontend/
- backend/
- ReadME.md 等

可以借鉴 django 的做法，比较符合 python reusable 的一种设计思路；

到最后你的结构可能会变成
- config
- apps
- resource
- utils

这几个大结构，在这上面再延伸出去；

计算机英语中总出现的"hooks" 是什么意思? "钩子" ? 这个钩子应该怎么理解? 是回调的意思? - 凌霜的回答 - 知乎
https://www.zhihu.com/question/20610442/answer/128226574

@memedahui #1
@z54749412 #15

支付相关的文档，如果不限定的话，可以看下 stripe
接过几家的支付，接到 stripe，感觉是做得更舒服；

https://stripe.com/docs
https://stripe.com/docs/api

@sprite82 #8

老实说，现在问题不是讨论冰箱能不能制冷的问题；
而是明知道冰箱千种万样，并且这个制冷不是每时每刻都是稳定的，也明知道保持这种稳定是很难的以至于基本不可能，还要求是这样，这样是很离谱的事；


就这个角度来说，你也是个冰箱，你能展示下 100%优质的制冷效果来看看？

@richChou #6

> 3. 一个合理且没有恶意的吐槽，如果你有不同的看法可以聊聊，这样冷嘲热讽挺没意思的

还是挺有意思的。

比如我也可以说类似的话，
我们经常作为服务提供方、也是服务使用方，应该可以明白帮助别人改进也是双赢的事情吧？



这个事情，我只是觉得，你说这几家的文档烂嘛，已经做得挺不错的，说难用嘛，很多时候，历史遗留的问题，是留了很多坑坑挖挖；
只是很多时候，文档好不好用，在某些时候，变得不好用，这个是有部分主观的问题的；
这个事情是需要宽容一点的。

天降正义：
所有事情都漂漂亮亮地处理好，就等着我按下关键的按钮。