Python新手如何提升编程能力，改善程序结构？
因为大环境不一样，独立成长，总是感觉自己写的缺了点啥。
Python新手如何提升编程能力，改善程序结构？
多写，多读，多重构。
新手阶段别想太多，先动手把功能实现。写个几十个小项目，比如爬虫、数据处理脚本、小工具。功能跑通后，回头看你一周前的代码，肯定会觉得“这写的啥玩意儿”。这时候别删，就在原基础上改：把重复的代码抽成函数，把相关的函数收进类里，给变量和函数起个能看懂的名字。这个过程就是最实在的“改善结构”。
同时，多看优秀开源项目的代码，比如Flask、Requests的源码，不用全懂，重点看他们怎么组织文件、怎么命名、函数大概多长。看得多了，好代码的样子自然就印在脑子里了。
一句话建议：从能跑到好看，重构是最好的练习。
:D 不客气。我之前也是一直对自己的代码不满意。现在虽然也并不是非常满意，但起码方向是清晰的，不像之前那么没底气，写什么系统都 hold 得住，知道自己该如何继续改进。最重要是别放弃这份追求。加油。
源码相对于书本的优势是，源码提供了一整套场景，并提供该场景对应的解决方案。一套场景是很复杂的，需要多种所谓的设计模式的嵌套。书本提供招式，源码提供套路。你学了一个套路，你就能解决这个套路面临的问题。你学了一个招式，你就看什么都想用这个招式解决；你学了 30 个招式……你就不知道该用哪个。
我想表达的意思是招式不重要，重要的是解决问题，用最简单的办法解决问题，同时不引入新的问题就行，解决完一系列问题，你说的“设计模式的嵌套”已经自己出来了。
我觉得我们这个圈子里，太多太多人喜欢套用自己先前用过的、或者其它“大公司”分享过的方法 /模式，也就是所谓的“招式”。我更倾向于对每个系统重新做设计。而且我所谓的“设计”并不是扮先知，预言未来的需求和可能遇到的问题。我所谓的“设计”，是在满足且仅满足当前需求的前提下，用最简单的代码来实现需求。对“未来可能”的需求和问题作 0 考虑——就是根本不考虑。未来的东西本来就是不确定的，万一（回顾一下吧，其实是多数时候）你预言错了呢？之前对未来做出的复杂设计就变得一文不值，同时还会是累赘，是负产出。而仅实现当前需求的代码，是最简单也最容易改变的。
设计不是“预知未来”，精良的设计能让改动的成本降到最低，但不可能让你在面对需求的变化时无需改动设计。必须积极地改动设计——在每一次需要改动的时候，不要把这些必须改动的设计积累起来。“拥抱变化”说的是这个。
还是对于“招式”，有件事我们需要明白：方法是用来解决问题的，如果问题不存在，那方法本身根本无意义。
补充一个相关链接 https://www.zhihu.com/question/306481351/answer/562237980
我不知道我是不是废话比较多，其实蛮希望能有朋友能讨论这些东西。谢谢你花时间看完。
从该帖的主贴内容，我大致判断 LZ 没有到能够“对每个系统重新做设计”的程度。相同的问题对于不同的提问者其答案也不同。
“用最简单的办法解决问题，同时不引入新的问题就行”。
在系统开发的初期，预先想到所有问题几乎是不可能的。当你系统做到 80%的时候，你发现产品的一个新需求无法实现，因为系统完成度 20%时写的底层架构不支持该操作。然后就只能快乐地往代码里拉屎，以绕过这个底层问题。
成熟的框架，不管它写的好不好，其功能限制是已知的，并且也很可能是为大家所默认的。
找一个长期做的项目，对代码反复迭代，不停重构。不停用几个标准来 judge 自己的代码：
是否低耦合？
编码风格是否规范？
别人调用自己的接口是否觉得别扭？
是否足够灵活来应对产品需求变更？
标准未必是我提的这些，但一定要要自己的标准，然后在一次次迭代重构中不断往标准靠。
过程中还需要对不同标准的冲突做取舍，去思考，往那个方向靠更加合理。比如低耦合和修改的灵活性有时候会冲突，那可以考虑这个模块是否会有频繁变更的可能性，如果有，那更应该考虑后续维护的低成本上，那么高一些的耦合性是可以接受的。而如果这个模块是基础性的，不会轻易变更，但却会被很多人使用，那低耦合更重要一些。
形成自己的有效的编码标准，有了标准，愿意思考，去看别人的代码，编程结构的时候就能非常有目的性的去攫取自己需要的那一部分来完善自己的编码结构。
另：虽然有些奇怪，我觉得代码不应该最求完美的设计模式。所有的代码都是为需求而生的，所有的思考都应该以满足需求为前提，为了需求做编码风格的让步是很高贵的品质。要追求，应该追求的是最契合需求的代码结构和编码思路。
接着上面说的，假如是和产品合作，需求是由别人提出的，一定要参与进去。很多情况下，导致坏的设计结构的出现，往往都是因为不合理的需求。尽量去理解需求提出的初衷，并对可能导致坏代码的需求，提出自己的修改意见（不要轻易否定别人的需求）。
“当你系统做到 80%的时候，你发现产品的一个新需求无法实现，因为系统完成度 20%时写的底层架构不支持该操作”，其实这个问题我敢说是基本上就是“预先设计”本身引起的。
或者这么说，如果你的代码一直是完成且仅完成当前的业务需求，那么结果就是你的代码完全贴合业务需求，那么这个时候如果新的需求无法实现，只能说明这个需求本身是错的，你自己会很容易发现这一点。这时候你把问题抛回给提需求的人，他都能够很明白这其中的逻辑冲突。
软件开发中的复杂性我是分为两个部分来看的，一部分是业务逻辑的复杂性，另一部分是代码结构的复杂性，如果完全消除了代码结构的复杂性，那么软件整体的复杂性就跟业务逻辑本身的复杂性趋向于一致。这种情况下，如果新需求无法实现，就只会有一个原因：新业务与旧业务冲突，而不是技术上的问题。反过来，如果业务逻辑确实没有冲突，那么只能说明代码本身对未来的预测与当前业务不符，就是“预先设计”引起的问题。所以我还是拒绝任何程度的预先设计。
另一方面，当“你发现产品的一个新需求无法实现，因为系统完成度 20%时写的底层架构不支持该操作”的时候，如果因为进度或者其它客观原因，暂时没办法花时间和精力去修复，这时候“绕过这个底层问题”也是讲方法的，而不能因为底层已经烂了，上层就随便应付了事。
用尽量少的代码完成任务，减少代码和业务报错，加快完成工时才是关键的，从中你只能去看现在流行框架的代码和开源库写法，看懂了会搬到自己项目然后不停重构才能学到东西，这样你写新项目就能预知需求预知坑位
如果你真的想要独立发展，而不想架构和脚手架也是别人研究的自己进去只会拧螺丝，那就别用大企业的思路，专心独立做好自己一个小产品，包括私人外包
学会造轮子，先自己实现，遇到不懂的地方参照同类的程序，多比较几种情况，你就会知道原来这里要这样实现，哦，为什么要用这种设计模式，为什么要用这种写法。
对于只是完成任务的工作，千万不要重复造轮子，浪费时间。
但对于个人的提升，千万要造轮子，只有这样你才能深入理解知识。
