拾遗

一直都想把去年一年的一些收获做一个简单的总结，但总是给自己找理由推脱。一方面觉得这些东西有些无足轻重，不够系统，另一方面自己已经在准备考研。但是这种想总结的这种念头却一直心里潜水，时不时地冒出来，最终“浪费”了周末时间总结下了这篇博客。
这也是博客标题叫拾遗的原因。

博主是一名大三的软件工程在校生，之前学习了差不多一年的Python web开发，博文主要是自己的一些遇到的问题，感悟和理解，现在再一次站在了人生的分岔口。

博文包括以下内容：

• 语言和框架（Python+Django）
• 数据库遇到的问题
• 服务器部署遇到的问题
• 项目需求的设想
• 对于软件团队开发的理解
• 展望

一、语言和框架

大概17年下半年的时候，我随着知乎对Python的推崇大流，半知半解的开始学习。而现在越来越多的高校把它当做大一入门的编程语言。

1.1 Python

解释性语言，天生被贴上执行效率慢的标签，但这个解释也是有中间产物的，Python在解释源程序时分为两步：

• 第一步：将源码转为字节码
• 第二步：将字节码转换为机器码

留意的话会注意到，当的python文件被编译过，文件之间存在import关系，就会生成一个__pyc__文件夹。pyc 文件是由 Python 解释器将 模块的源码 转换为 字节码。（pyc，py代表pychon，c 是 compiled的含义，pyc即编译过的python文件 ）当我们的程序没有修改过，那么下次运行程序的时候，就可以跳过 从源码到字节码 的过程，直接加载 pyc 文件。这么做的目的就是为了加快运行速度。想要提高开发效率，就可能执行效率做一些取舍。

作为动态类型语言，可能单单阅读一部分代码很难判断一个变量或者参数代表着什么意思，是什么类型，所以注释和变量命名规范很有必要。而当你真正想把代码跑起来想看看里边到底是什么样，也可能会因为异常或其他情况导致变量里边不再是原本的数据类型。所以在python库中有许多的is instance和type语句来确保变量能按照预期的保存想要的数据结构。

这就凸显编码规范，文档和注释的重要性。
软件=程序+文档+数据=数据结构+算法+文档 +数据

这种每一个变量可以指向不同的对象（《流畅的Python》中说：在Python中，所有都是对象），怎样保证一个对象，一个变量从一个对象指向另一个对象之后呢？原来对象应该就没用了，那么所占用的内存也应该被释放掉。为了解决这个问题，Python使用引用计数法作为默认的垃圾回收机制，为每个对象维护一个对象引用字段记录引用数，一旦对象的引用计数为0，该对象立即被回收，对象占用的内存空间将被释放。但是为了维护这样一个字段，每一个对象又要占用多余的内存空间，并且还无法解决循环引用的问题，所以Python引入了标记-清除和分代回收两种GC机制。

如果想进一步学习，《流畅的Python》绝对是能够帮助打开Python的新大门。

1.2 编码规范

虽然PE8规定说不建议tab，而是使用4个空格，因为不同的编辑器可能对tab的定义数是不一致的。即使本地写代码的时候不会有问题，也不能避免在其他人用其他编辑器的时候不出问题，毕竟Python没有大括号这种构造代码块的语法，对缩进自己缩进的依赖要比其他需要的多的多，但还是改不掉只用tab的习惯，不良习惯的养成可能需要一个星期，而改掉他却要多花好几倍的功夫。命名的习惯不一致，也没有合理的注释，时间长了，我都看不懂自己的代码。
我好像记得在哪看过这么一段话，大致是说

编程的最终目的是交流，实现功能是为了和用户，编码的规范是为了和团队其他人沟通，你写的别人能理解，别人写的你也能看懂

1.3 Django

人在不断学习，语言和框架在不断进化满足需求，不可避免的，新版本与旧版本之间也有矛盾。软件工程里讲上层兼容下层，即新版本要兼容旧版本。但事实并非总是如此，使用xadmin作为后台管理系统时就出现和Django2.x不兼容的问题。原来的xadmin是基于Django1.x做的，而原来的作者已经不在维护。

前端对后端发送请求数据时总是会做重复的验证，比如表单提交，前端添加标签属性对数据输入做一次验证，后端拿到数据手动做一次验证，取出验证信息去跟数据库匹配时数据库模型会在匹配之前做一次验证，看起来三次验证有点不必要，但是总不能避免有人可能利用表单将输入的字符串变成可执行的脚本代码侵入主机或者盗取重要信息（sql注入和csrf）。
You cannot be more cautious。

框架的学习，官方文档绝对是最正确的一手资料。

二、数据库

就只是MySQL......

2.1 乱码问题

我接触的最大的数据量就是100万条数据（字段），是实验室的学弟做的爬虫爬取近几年所有的各个院校的高考录取分数，和院校的相关信息，数据拿到手的时候是两个表，我想把两个表做一次合并，结果电脑跑了几个小时还没有结束，最终放弃了。还有一个历时两天才解决的问题，从学弟的数据库mongodb导出表格然后导入我本地的mysql，两边数据库都默认UTF-8，但是数据导入我这边之后显示中文数据乱码，也考虑过mysql的utf-8其实是三个字符而不是四个字符，但这其实不是乱码的原因，后来学弟跟我说为了检查数据是否导出完整正确，在数据导出表格之后用WPS或者office打开查看了一下，其实这就是问题所在了，中文办公软件会默认中文字符以gbk或者gb2312编码，也就是中文字符在UTF-8—>gbk或gb2313没问题，而gbk或gb2313—>UTF-8就会很可能出现乱码问题。

2.2 表结构的设计

接触的小型网站表结构的设计都比较简单，真正常用的数据表可能也至多十几个，是否做表与表结构之间的关联，字段非空，默认属性，主键的设置，数据库表问题其实在本地开发和测试暴露的比较明显。很多时候都是为了实现和测试功能，都会重复数据的删除添加，外键为了维护数据库的参照完整性，就会出现提示异常报错，经常一股脑就直接把整个数据库删了，重新添加数据，而不是级联删除，这应该算是一个不好的习惯。

• 一方面数据表结构设计的不合理
• 另一方面，后台代码对异常的处理不够。

偶然的机会下，我看了到实验室的一个学姐做的一套内部绩效考核系统，由于是政府机关法院使用的，所以可靠性功能性还是很高的，数据库也是MySQL，学姐说表的话大概十几个，但是没有做表与表之间的关联，如果做关联的话对数据库设计和处理经验要求较高，也不容易管理。其实后来查看资料发现，在Django的数据库模型里面对于这种_set的表与表的关联查询还不如直接filter查询的效率高。但是如果做表结构的关联就意味着能更方便地用深层数的查询，如在Django Rest framework中有ModelSerializer做数据表的深度查询，具体问题具体分析。
所以如果让我在设计数据库：

• 要么数据表的主键外键一次设计完善尽量不再做修改；
• 要么不会轻易再做外键关联，主键也会使用默认，但字段是否非空，属性默认值的设置是一定需要认真考虑的。

三、服务器

去年的时候因为写的管理系统要上线，老师给了一台centos的服务器账号密码，我进去之后，第一次接触没有图形用户接口的操作系统，完全懵逼，照着网上的教程开始使用，在更改相关配置文件之后，额，远程就无法连接，尴尬。
为了弥补缺陷，自己买了一年的阿里云服务器，就去学了一点linux，当时看的是《跟着鸟哥学Linux》，厚厚的一本，看了小部分，其实很多命令都是看了一遍试了一遍，然后就忘了，只有一些的简单的命令还记着，如果说原理的话，权限和软硬链接的作用和原理还记忆犹新。

服务器部署使用centos+Django+Nginx部署的时候也出现过很多问题

3.1 样式不显示

在将django项目部署到阿里云（nginx作为web服务器）上之后发现出现后台管理界面admin不显示样式。打开浏览器查看css资源后发现，虽然文件指向项目文件中的静态资源，但是static目录下却没有相应的css和js资源尝试在项目路径下收集样式，在本地开发和项目投入生产，django项目对于静态文件的管理在两种状态下是不一样的，在部署上线需要指定静态文件路径。

3.2 代码修改失效问题

在将django项目部署到阿里云上之后，使用宝塔控制面板修改项目源码，或者使用直接在终端修改，修改之后重启uwsgi和nginx无效。在本地环境的时候，直接修改，然后重启runserver就可以效果，比较方便，但是到服务器上就出问题了。

• 一方面：如果直接在服务器中修改源代码，由于Python本身对缩进的严格要求，会造成异常出错。
• 另一方面：在本地时候，使用 python manage.py runserver 来运行服务器。这只适用测试环境中使用。也就是说每次修改源代码，就需要重启Ngnix。

在修改源码上传服务器之后，进入服务器项目目录，查看uwsgi进程，
然后杀死所有进程，再重新启动uwsgi，然后再宝塔或者直接命令重启Nginx，修改生效。

四、需求设想

有很多想做的功能，想学的知识（芝士就是力量）都只能暂时搁浅了。

• 匿名用户如何限制访问
• 如何自己做权限管理
• 高并发会怎么样
• 优化问题
• 数据处理
• 结合新技术
• ......

4.1 权限管理

虽然django-admin或者xadmin关于后台管理很完善了，但是如果要自己做呢？在django项目中生成超级管理员可以进入项目目录直接在终端输入

python manage.py createsuperuser

然后输入管理员，密码，邮箱。作为超级管理员拥有所有权限，包括添加普通管理员，普通用户等。在django默认生成的uses表中，默认有关于有用户身份的字段，is_staff，is_superuser，也就是字段的0或1对应着是否为普通管理员和超级用户。在xadmin中重新做了一些admin没有的补充和完善，将用户对于后台管理的日志功能重新做了一张表，并添加了管理人员进行操作使用的IP，某种程度上安全性更高了。

4.2 访问限制

利用IP地址来对用户，尤其指匿名用户进行访问限制，这在Django Rest framework有一个专门的名字叫做——节流（访问限制）。就是通常一个用户在多次请求一个页面，或者点击一个链接的时候，前几次点击是没有问题的，但是一旦连续几次之后，就会出现访问受限，只有一定时间过后才会限制解除，正常访问。想要对匿名用户进行限制就要确认哪些是哪些是匿名用户发出的请求，IP地址就是唯一的标识。在当一个用户第一发送请求的时候，可以在缓存中生成一个字典，字典的键值对分别是用户的唯一标识和用户的访问时间，每次请求则往字典中添加一个键值对，设置最多访问次数，设置比较第一次添加的键值对的访问时间和最后一次的访问时间比较判断是否允许访问。

4.3 并发

这仿佛是离我最遥远的事，但好奇嘛，总是去想模拟一些没有接触过的其他情况，按照学校的教务处来说，假如每天有2w+的点击量，时段分布在早六点到凌晨两点共20小时，那么按照二八原则，假设4个小时接受2w+的点击量，每秒也平均不到1.5次。放弃。

4.4 优化

简单的优化应该可以从很多方面做。
我记得在调试后端代码的时候，然后刷新浏览器会没作用，原因应该就是对浏览器页面做了缓存，打开操纵台取消缓存。在修改前端页面的时候，都会强调说尽量把主要部分css样式表放在头部，而动态效果的js文件放在页尾，为了防止网络延迟的情况，先加载样式表给用户一个简单的样式，在逐渐加载动态内容，最大程度的减少用户不满意。而浏览器同时请求文件的个数也会有上线，当点击一个页面的时候，假如包含多个css和js文件浏览器就会一部分一部分请求，所以减少静态文件的数量也是一种办法，较少的js语句可以直接嵌套在html标签中而不是新建一个js文件。

• 尽量减少与数据库的连接
• 增加Django缓存机制
• 数据库索引
• ......
• 都还没来及尝试

4.5 数据处理

在美国大超市里，尿布和啤酒摆在一起出售。这看似奇怪，但是尿布和啤酒的销量都增加了。这是发生的真实案例，尿布与啤酒所代表的行为模式：年轻的父亲下班后经常要到超市去买婴儿尿布，而他们中有部分人同时也为自己买一些啤酒。从顾客的购买习惯中挖掘“购买一种商品很大记录会购买另外一种产品（由于某些事件的发生而引起另外一些事件的发生）”，这种规律，又叫关联规则。如果有一个积累了大量顾客交易数据的数据仓库，那么就可以从数据仓库中进行数据挖掘，提取出关联规则，帮助零售商制定营销策略，价目表设计、商品促销、商品的排放和基于购买模式的顾客划分。我在想是不是可以将Apriori算法，作为电商项目的商品推荐算法？现在互联网数据红利爆发期。
有了以前的啤酒和尿布的故事，现在呢，在超市结账台的旁边都会放一些小的零食，口香糖，糖果，如果顾客买的商品是有零头的，很大几率会不要零钱而拿一些糖果作为代替。但现在呢？移动支付的便捷性使得人们已经完全不用考虑零钱所带来的麻烦问题，超市收银台小商品也渐渐无人问津。

4.6 新技术

将数据挖掘的技术应用于商场，现在很流行的图像识别应用于学校的管理？
一般的校园管理系统假如就是学生管理，宿舍管理，奖助学金评定系统等等，如果传统的按照人来评定奖学金助学金，那么肯定会有不公平，人的因素夹杂进去。如果管理系统与图像识别结合，通过宿舍门口，教室的摄像头检查学生的出勤率，上课率，作为参考系数，通过监控学生校园卡里面的余额和每月支出来参考评定奖助学金，要更加合情合理，公平公正。

实验室老师去年暑假的时候还和一家养殖场做猪的行为和叫声识别检测。

以上只是大胆设想，研究生阶段希望往这方面靠拢。

五、团队合作

5.1 沟通

我记得是去年九月下旬，十月初的时候，帮老师做了一个小的管理系统，第一次真枪实战心里还是发憷的。为了赶进度，中秋节和国庆节也没有回家。但是放假总想找时间休息一下，有的时候就没有去实验室，老师看到我没有在座位上就打电话让我过去，基本上隔个两三天都会找我聊聊，问我做的怎么样了，感觉实在催我，刚开始心里还是有点抵触。
其实也是自己的问题，之前我不太喜欢跟老师沟通，或者不大清楚沟通的意义，就是说我就闷头做自己的，每天的问题自己想办法解决，觉得老师忙也不和老师沟通，作为整个项目的管理者——老师，也不知道我的进度如何，每天都做了什么。
了解了软件项目管理这些看起来高屋建瓴的东西之后，作为整个项目的管理者，如果不能很好的把控好项目的进度，会造成用户的恐慌，和整个项目的延期甚至失败。老师这么做是对的。
而且我觉得如果以后作为一个团队里的新人，或者以实习生的身份工作，每周向自己的直系领导回报自己的工作情况和工作进度是十分有必要的，那至少会给他留有一种你一直在学习工作，而不是混吃等死的好印象。

如果知识技术是硬实力，那么沟通能力则是在一切岗位可以复用的软实力。

5.2 需求问题

计划，分析，设计，编码，测试，运行维护。
我真真切切体会到瀑布模型带来的问题，如果是一个人做小型项目，那么它至少给你一种可以参考的开发流程，从开始到结束，都有所依据。但是瀑布模型中前一阶段的成果是后一阶段基础，依赖性太高，如果一个阶段的问题可能会导致整个流程的崩溃，即使每个环节都有反馈，但不适合经常变化的项目。另外在项目开始时候也没有办法保证用户一开始就十分明确地完全表达自己的需求，不再做大程度的需求变更，并且用户只有等到交付阶段才能看到实际软件的运行效果和规模。

5.3 全栈

博主已经大三了，不少同学也都在为自己的下半年的实习焦急和忙碌，也有不少培训公司来捞鱼，培训的技术包括Python全栈开发，和Java企业级开发。可为什么只有Python是全栈？我原本以为是Python做后端跟Java相比较为轻量级，只有小公司才会使用Python+Django作为后端技术栈开发，然而我又错了。前几天博客园认识的朋友说拿到offer到鹅厂当实习生，做python web，就是用Vue.js和Django Restframework。不知道是不是编码阶段前端和后端的开发同时进行，采用前后端分离的模式。

我第一次听说全栈这个词，是一次和老师吃饭的时候老师说的，给我的第一印象是：全栈工程师就是一个人能顶一支队伍。
也有具体定义：一个能处理数据库 、服务器 、系统工程和客户端的所有工作的工程师 。
那么真的是这样吗？对于本科生来说，难度可能大了点。
团队职位分化细化，也就是各司其职，意味着一个人价值的压榨与贬值。而升值更多要靠自我驱动。
软件工程讲究代码的可移植性可复用性，代码映射到软件团队中的个人，比如一个后端如果可以在必要时能去帮助开发前端甚至维护服务器，那么他的竞争优势肯定就凸现出来了。所以全栈工程师就是可以独立完成一个产品的人 。
我有看过一本关于全栈的书，《Web全栈工程师的自我修养》，作者余果毕业于西电曾是腾讯高级UI工程师。书不厚但每一章都很精彩，以后一定要挤时间把每一章推荐的书单都看一下。

六、拾遗

我还记得去年三月初刚开学的时候毛遂自荐要跟老师进实验室学习，到今年三月初离开实验室，准备考研，不过我也觉得去年一整年是对我来说最有意义的一年。能和比自己厉害许多的学姐学长还有老师能够在一起共事，很幸运。
现在接近六月份，差不多三个月以来每天面对的都是折磨人的高数，英语的长难句和阅读，但我还是经常想念之前在实验室写代码的那种感觉，想实现的功能被自己像积木一样一块一块堆好，即使会出问题，积木本身也会倒，但问题被分析到最后被解决，所收获的快感恐怕不是游戏胜利能够相比的，问题解决留下来的经验也能避免以后重复再犯。还有，我很喜欢那种带上耳机敲代码，仿佛世界都是自己的的感觉。

刚开始准备考研的时候心神不宁也不知道如何下手，好基友告诉我说要未虑胜，先虑败，同时有学姐因为复试差点运气与心仪的学校插肩而过，我有段时间晚上连续梦到自己复试不幸被刷了，潜意识里再想怎么办，但答案都是未知，我也不知道如果这背水一战如果失败了该怎么办。如果继续留在实验室，我现在应该在刷算法题和面试题准备面试实习。

我也不知道我是不是适合考研，但是我现在真的很需要这么在三年的时间来看我想看的书，学我想学的知识技术，还有一个研究生的身份能够帮我接触到我本科接触不到的圈子，认识更多厉害的人。

这是一位本硕华科的大佬在我大一懵懵懂懂的时候对我说的一番话，到现在还印象深刻。

多看一些经典书籍，自己多动手，每个人都有自己的学习方法和研究方向，没有千篇一律的内容。

博客和视频教程都是个人总结，难免会有漏洞，逻辑不连贯的地方，但经过反复改版印刷的书籍基本上不会有这种问题。真的应该多看书，毕竟

以上皆一管之见，如有偏颇不当之处，但请谅解与指出，毕竟博主还是一个大三学生，too young, too naive