lz 写 python 两年了 总感觉代码不够工程化(对比 java 或 c ) 有点随心所欲的意思 现在就想规范下自己那些不好的习惯 请问下各位有什么技巧或者见解么
lz 写 python 两年了 总感觉代码不够工程化(对比 java 或 c ) 有点随心所欲的意思 现在就想规范下自己那些不好的习惯 请问下各位有什么技巧或者见解么
|
1
先谢谢各位老哥
|
|
2
不懂 python
但是从方法论上讲,无非就是高内聚、低耦合、可读性高。 |
|
3
不用奇技淫巧,老老实实写:容易读懂,容易维护,容易扩展,稳定可靠的代码。
|
|
4
先保证不写重复代码,你自然知道如何工程化
|
|
5
我写代码就是如此,当年用非常原始的代码风格撑起了几十万的 GPS 并发,后来终于有资深一点的工程师参与,做了几层拆分,不过反而从此不在追加新功能了,毕竟框架的意义是多人分工,而不是让编码更灵活
|
|
6
想起了两个大佬撕逼,
一个说都 21 世纪了,js 的 express 还直接把所有业务逻辑都写到一起。 另一个说:是,我不用写一个方法都要封装几十层的类, (滑稽 |
|
7
-Werror
|
|
8
python 的话,别写一些花式语法就好了。
|
|
opengpsMay 27, 2020 via Android
11
@vitoliu 其实很小的,4 层通信不像 7 层那么浪费资源,我从前东家走的时候已经上百万设备了,用了也就 100 台左右低配 ECS 服务器分流负载
|
|
12
玩一下 tdd
|
|
13
python 的话学 tornado 下呗
|
|
14
多看看大佬的代码
|
|
15
整体架构搞好,把 lint 和 test 加上。工程化就是既要开发效率 /迭代速度,也要代码质量。这些是通用的,跟用不用 Python 没有关系。好的开发框架其实就为工程化打好了基础。
|
|
16
把你觉得工程化的代码抄过来,说是你写的
|
|
sekiMay 27, 2020
17
买一本代码大全看看吧
|
|
18
设计一个功能的时候多想想“意外情况”,我觉得工程化的很重要的一方面就是对错误分支的处理
|
|
19
工程化的核心就两条:可读性、可扩展性(或者说 easy to change )。
做到这两点基本上就没什么问题了。这也是为什么我很烦一些 Java 的范式(比如 Guice ),为了一些所谓的便利严重牺牲了代码可读性,当然深层原因还是语言本身。就 Python 来说,主要还是不要沉迷黑魔法,尽可能用大家都看得懂的方式写代码,不要老想着做一行超人。如果一定要用,就多写点注释吧。 至于可扩展性,个人觉得主要还是跟具体场景有关。虽然也有些通用原则比如高内聚低耦合啥的,但落实到具体的项目,还是依赖于你首先把整个逻辑理清楚,再考虑哪些东西是未来有可能要变的。 |
|
20
因为经验的关系,单纯看好的代码你可能无法 get 到那个点,去看看<Clean Code>吧,至少对我挺有帮助。
|
|
21
多封装,多抽象,撸码前多考虑一下现在和将来就行了....不要为了工程化而工程化,稳定才是第一位
|
|
22
PY 确实不那么容易的工程化吧,JAVA C 这俩都有业界规范,老哥学一个玩玩感受下?
|
|
NostalgiaaaaMay 27, 2020
23
|
|
24
@q8164305 #4 不是不写重复代码就是好的工程代码,(尤其是新手工程师)从一开始就各种封装抽象,导致扩展性不够,后期需求变动导致更难修改。
|
|
25
工程=业务逻辑+框架。业务逻辑靠刷题,框架设计模式八股文。
|
|
evaseemeflyMay 28, 2020
26
也在关注这个
|
|
lancelockMay 28, 2020 via iPhone
27
感觉 java 的做法有点过头了
|
|
opengpsMay 28, 2020
29
@xavierxiu GPS 终端业务,从我名字可以联想下,我不是在说 QPS 指标,按照业务场景转化下,可以认为是十分之一到 20 分之一的终端数可以约等于 QPS
|
|
AvenirXMay 28, 2020 via iPhone
30
楼上都是工程大神...
我的建议是根据实际需求来,不要为了“工程化”而去“工程化” 不然适得其反。写了一段只会用到一两次的过程化的代码,何必搞成各个模块条条框框?以后你还能看懂吗? 某段代码每次随着需求改来改去?某些功能需要复用到另一个工程?有些参数牵一发动全身?... 有了这些需求你再去请教应该用什么方式去优化。 |