大家好，今天小编关注到一个比较有意思的话题，就是关于python学习清单的问题，于是小编就整理了2个相关介绍python学习清单的解答，让我们一起看看吧。
码农工作一年，感觉没时间看书，技术提高慢，怎么解决？
作为曾经的码农，第一件重要的事是：做技术不应该只通过看书学习。
很多人都有一个误区，觉得看书才是正经的学习方式，这是非常大的一个坑，看书只是仪式感比较强，但并非只有这一种方式。
根据我的经验，程序员提升功力的有效方式，一种是看大牛的代码，学习前辈的编码思路；另一种是自己狂敲代码，去实践自己的想法，在这个过程中学习别人的经验、实践自己的想法，经历失败和成功，反思和总结后变成自己的智慧。
一门新技术的系统学习，可以看书，或者，可以参加培训、看***教程。学什么技术非常关键，成长慢有时候是没学，有时候是瞎学，一定要记住，人的生命是有限的，学习知识是无限的，一定要把有限的生命用在必要的知识学习上！
学什么有两个维度，一是现在工作中自己所欠缺的技能，二是自己下一个职位目标所需的技能。如果还不能很好的胜任工作，先查缺补漏看看需要学什么；如果已经能够游刃有余，就为下一步打算，看看以后跳槽需要强化什么。以终为始，才能切中要害。
当然这中间会有很多自己知识的盲区，怎么学习新知识，作为编程来说，手册是一个非常好的参考资料！另外，不要太依赖通过看书学习，图书追求知识的系统性和完整性，信息量往往非常大，并不很适合快速检索。
作为技术人员，要学会使用互联网……知道如何使用百度快速检索到自己想找的问题，会***用下谷歌，这都是最基本的技能，包括多泡技术社区，同行交流的QQ群等，都是一种获取知识和信息的方式。
没时间的背后，都是不重要。
每个人都说自己忙，实际上是不会利用时间。工作本身就是学习，在工作中解决一个个技术问题就是成长。休息时也不一定非要大块的时间才可以学习，不是只有半个小时、一个小时才是时间，三分钟、五分钟也是时间，可以用来阅读，可以用来思考，碎片时间利用好了一定可以聚沙成塔。
给自己设定学习任务，分解到每个月、每一周、每一天，制定奖惩，按时完成，光有一个大方向，只是想想很感动，琢磨一下挺激动，最后一动不动。
相信大部分程序员都有这样的困惑，包括我自己，面对大量的学习***，却无从下手，感觉没有时间主动学习，技术提高慢。关于这些问题，我和大家分享下经验。
面对大量的知识如何选择
十多年前，那时候的我们苦于资料太少；
十多年后，这时候的我们苦于资料太多；
我建议大家在学习的时候，最好是查看最原始的资料，而不是被人消化理解过的“二手资料”。比如你要学习Spring Boot的话，最好的资料就是***的文档，其次才是买一本中文版Spring Boot的书。
当然这个对程序员的要求就比较高了，因为最原始的资料大多是英文的，所以建议大家可以静下心来学习学习英文；如果大家仍然觉得英文资料“难以下咽”，也请中英资料结合着看（下面会再详细说明）。
面对枯燥的知识如何学习
通常情况，枯燥的知识都是大家不感兴趣的知识，因为这些知识我们在学习过程中看不到学习效果，不知道学完了之后有什么用；比如我们学习TCP/IP协议，并不知道它对我们写代码有什么用，因此学习起来感觉枯燥；不过这些枯燥的知识通常都是我们所说的基础知识，你为什么感觉新的技术学习时间长，技术提高慢，就是因为这些基础知识不扎实。
那么面对这些枯燥的知识，我们该如何下手呢？
先去找使用场景，找到实际使用的地方，再回来学习理论；
带着问题去学习，效果更好；
如果有资料能把枯燥的知识用生动的例子讲解出来，尽管它不是“原始资料”，但是对于我们的帮助也是很大的；我刚工作的时候看过一本书《大话设计模式》，让当时的我受益匪浅。
为什么觉得技术提高慢
上面的章节也提到过，技术提高慢，是因为基础知识不扎实，这里再详细地说一下。
这些原理性的知识和技术，都是经过长时间考验的，例如我们在大学时候学习的计算机组成原理、操作系统、算法与数据结构等课程；这些知识，看起来工作中用不到，但是学习这些知识，是为了未来学习其他知识的时候速度更快。
再和大家分享几个学习的经验：
利用碎片化时间学习虽然值得称赞，但是更鼓励抽出完整的时间去学习，最好关闭QQ、微信等一切通讯软件，避免被打扰；如果时间不够，那么也至少每天就抽出半个小时，养成良好的学习习惯。
反复的学习：对于基础的知识，需要反复的学习；相同的知识，不同的阶段学习起来，都会有不同的感悟。
善于总结：可以把学习的知识通过笔记、博客等方式记录下来。
学以致用：把学到的东西在项目中用起来，会让你的记忆更加牢固。
学会之后再讲出来：对于某些知识，如果能“讲出来”，那么就需要把这些知识了解的非常透彻；这也是我现在做技术分享的主要原因之一。
我将持续分享J***a开发、架构设计、程序员职业发展等方面的见解，希望能得到你的关注。
我直接给个可实操的方案吧！
别信你的脑子
题主有没有记笔记的习惯？没有的话，请立刻开始记笔记。
现在笔记软件很多，选个可以和手机同步的笔记软件，比如印象笔记，网易云笔记等。在工作中遇到什么问题了，不要百度一下，有答案了就完了。把问题记录下来，得到的答案也记录下来，最简单就是把URL地址直接拷贝下来。这个最多花三分钟时间吧？
另外工作中有什么点子或想法了，也要记录下来。
想法子「偷懒」
总结出自己工作中，重复性的工作，想办法把这部分工作自动化（你熟练的工作，再花出去的时间，就是一种浪费）。比如：很多人都抱怨，老是写CRUD，那有没有办法可以自动化这部分代码的编写？是否可以使用IDE的模板或snippet来简化？或者自己写个代码生成工具？
别让脑子歇着
题主总有通勤时间吧？在通勤时间，用手机复盘上面记录的问题（这就是要能与手机同步的笔记软件的原因）。去思考自己为什么会遇到这个问题？别人是怎么解决的？别人为什么能想到这个解决方案？我是因为欠缺什么导致没法解决这个问题？我现在有没有什么更好的思路？想到的内容可以用手机直接记录下来。
点成线，线成面，面成体
***设题主996。那还有个周末吧？总能挤个几个小时吧？花两到三个小时，对本周记录的和复盘的信息进行整理，能够系统化的整理起来。如果还不够系统，就进行分类。同时确认是否和之前的知识有关联？是否有延伸知识？可以去网上找找看，进行学习整理。
对于自己的点子和想法，考虑如何分配到后面的时间里去实现！
剥洋葱式拆解任务
很多书籍、文章都教你怎么去拆解一个任务。什么《清单革命》，todoList相关文章之类的啦。对于学习来说，一般的切分任务的方法是有问题的。它把完整的内容给拆散了。
就以读书为例吧！如果按照一般的拆分方法，可能就是每天睡前看20页！也就是把一本书拆成了n个20页！把一个连续的东西给打断了。你今天看完了，第二天再看，你还记得昨天看的是什么吗？
「剥洋葱式拆解」就是一层层的剥开内容。由宽泛到详细。还以读书为列，就是今天先看书的结构，可以猜测一下大概写的是什么，第二天再概读，验证自己的猜测，如果猜对了可以先跳过，如果不对了，具体又是讲什么的，是否感兴趣？感兴趣在哪里，第三天再细读自己感兴趣的地方，一步步的深入下去。每一步都保证书的内容是完整的。
之前回答的两个问题「如何阅读源码」和「如何编写代码」都是这样的方式，有兴趣的可以去翻阅，这里不赘述了。
这可以说是一个问题，但是又不算一个真正的问题。因为，大家平时工作中都很忙，我的朋友，一些也是程序员，在bat工作，我印象中好几个都要996，任务还是很紧。
其实无论是不是程序员，你会发现工作都很紧张，这个时候我们能做的主要体现在两个方面
1.每天晚上固定抽出一个小时来进行充电，比如你想学python，就可以买一本相关书籍，或者在网上找个相关的而且比较全面的教程，每天看一个小时，你会发现这可以快速提高自己的技能，比如我自己，就每天抽时间来学习python，一年多时间已经学完了基础，还通过爬虫爬取某某些数据来***分析经济形势。
2.在自己的工作中学习，工作看似平淡，其实可深入的东西很多，代码风格，算法，调试技巧，业务理解，这些都是可以不断深入的，各个方面都得到提升，本身就是对自己的一种充电。
3.技术行业在平时的工作中要多请教，多总结，多记录，积累经验就是蓄能。
这个快节奏的社会，大家都忙，我们要掌握好自己的节奏，自己找机会。
希望对你有帮助。
有个偏方，就是跳槽。一般一个程序员在一个公司呆久了就会产生惰性，这时候换个环境，给自己压力，就会逼着自己学习新的东西，技术提升的就会快。
不过跳槽也是有缺点和风险的，须谨慎！
一句话形容产品经理与程序员的关系？
一个是质，一个是量。合为质量。没程序员创新或巧匠的质，产品或软体有问题和毛病，卖不出或不好卖。但没产品经理的经营策略或广告手段，产品再好也不一定卖的好。因此最简单关係就质量！
在互联网公司，不吵架的程序员和产品经理，不是一名合格的程序员和产品经理。要说起程序员和产品经理的关系？估计很多人会用这几个词：冤家、死对头、扛精。程序员经常抱怨产品经理改需求，产品经理觉得程序员怕麻烦，总是各种砍需求……你不论找到哪一方，他们总会有一堆充足的原因与理由。
相爱相杀皆因需求
2018年有这样一则产品经理和程序员因需求发生斗殴***的新闻，把这种关系推向了高点，这是一个被实锤的真实***，估计很多小伙伴都听说过，这里就不展开细说了。
从中折射出了一个现象“大部分程序员与产品经理都是对立相杀的关系”。事实上，如果你是程序员/产品经理，在处理这段关系时，完全可以通过改变自己的一些“小任性”，将一把烂牌打成好牌，这个前提是相互信任、分享、尊重，希望通过我下面的分享，让大家对彼此有更深入的了解、理解。
让程序员愤怒的那些事儿
1. 项目做了一半变更需求
这点很有可能让程序员们发飙吐槽不已，因为往往需求的变更意味着程序员之前对需求的思考、设计、实现都是白费的。
2. 产品逻辑混乱不清晰
逻辑不清、矛盾的产品文档，最终会导致产品上线后，目标与结果相差甚远，这往往意味着推翻重来，更有甚者，最终各种扯皮、推诿责任有么有？
3. 拿领导的权威来压人
有些产品和程序员们交流无果时，喜欢将老板们搬出来，这个上线日期是“老板说的”，要怎么怎么改，这是“老板说的”。这个动辄把老板搬出来压制程序员的方式，其实是很不友好的，即便不是程序员，是其他岗位，也是不可取的。
4. 怀疑程序员的技术能力
“不就加个功能吗，有那么复杂吗？需要那么长时间吗”，这句话相信很多程序员曾听到过。一个功能的实现，程序员要考虑很多，譬如底层数据结构设计是否合理、代码是否符合规范、代码设计是否合理、是否支持系统扩展等等，只有把这些都梳理清楚了，才是一个负责任的程序员，如果只是急于实现需求，不考虑编码规范和系统的性能及扩展性，即使快速完成了任务，那么也是一个不负责任不合格的程序员。
让产品经理愤怒的那些事儿
1. 这不能实现，那不能实现
耗时半个月准备的产品需求，结果大部分做不了，做不了你得告诉我原因是什么吧，这个路径不行，能否用其他方法去实现，又或者因为***不足、还是其它项目没完成做不了……不要将产品经理当作对立面的一方，有问题充分交流、换位思考、共同解决，长此以往，大家的默契度会渐入佳境。
2. 拒绝需求变更
产品与技术一样都要经历迭代、完善的过程，程序员也不能保证一次就能通过测试，或者不用测试直接上传版本，so，如果一个产品经理偶尔出现的一次小小失误，请谅解。
3. 只关心多少代码，不关心用户体验
技术也要关注用户体验，譬如用户打开网页速度，用户使用软件时占用CPU和内存过多导致浏览器崩溃等等，这些都是程序员要主动考虑的。一个有经验的程序员，往往还能从技术的角度给产品提出许多优化体验的方案。
4. 不看产品文档，结果牛头不对马嘴
这几种情况是产品经理最头疼的，不看文档（极少）、不仔细看文档（有部分），又或者看了文档不跟产品经理交流沟通的，直接在自己的理解基础上开发，项目发布上线之后，才发现完全不是当初的需求了。
程序员与产品经理是相互成就的
术业有专攻，专业的人做专业的事儿，产品经理不要去干涉程序员开发的事儿，对于程序员不能实现功能的原因有多种，充分沟通、取得信任、协同解决。同时，程序员也要充分信任产品经理，认真对待每一个产品需求（都是产品经理的劳动成果），客观地从技术实现角度评估分析，给予产品中肯建议，帮助产品经理做得更好。
作为一名产品经理，如果在工作上得不到程序员的协作配合，工作将难以顺利进行；而作为程序员，与产品经理协力打造出一款好的产品，既能在项目中历练、精进自己的技术，还能提升自己的KPI(有些公司程序员会有20%-50%不等的产品KPI)，也是在成就自己。所以，作为一个10年+程序员，我用一句话形容产品经理与程序员的关系，即：程序员与产品经理是相互成就的关系。
觉得不错点赞支持，送你9本程序员高赞的架构学习图书（9本书清单见上图），关注我的头条号【优知学院】，发送关键词【书】，立即领取。
到此，以上就是小编对于python学习清单的问题就介绍到这了，希望介绍关于python学习清单的2点解答对大家有用。