两年做后端开发的一些感受

python上的理解

tornado框架用了两年多，但其实用的python感觉其实还是皮毛方面的，python较之其他语言像java这种重型框架的语言来说，按我玩无主之地的经验来说，就像一把突击步枪，近距离还是远距离都非常合适，但只是打小怪，但是打大boss（构建大型项目，处理高并发，可分布式），就可能需要开技能（使用设计模式），不像java一开始是重型火箭炮，所以打大boss还是很给力的，那么python的缺点应该就是被人所诟病的并发性能低下了，相比竞争不过golang，所以python的 优点在哪呢，第一：解释型语言，非常接近自然语言。因此python拿来做脚本处理服务器上的运维工作相当不错，虽然同样可以用shell语言，但是python有另外一个优势就是库多，因此也更为灵活方便。第二：丰富的机器学习库。python有numpy，pandas，tensorflow等等这些优秀的数学库，因此使用python作为主要的机器学习语言优势也是非常明显的。

设计模式的理解

其实在学校的时候我也不是很理解为什么要有设计模式，但是出来工作之后也才渐渐懂得设计模式的好处，所以说工作经验越丰富，理解的设计模式可能也就越深。比如迭代器模式，对于做占用内存资源较高的情况时非常好用，之前我参加过的数据挖掘的时候就是比赛方会给出一张几十万条数据的职位招聘表，然后我们对其做出职位分类的处理，但是我的电脑只有8G，一时间把所有的数据导入到python的运行内存中直接内存就跑满了，所以当时我们采取的做法是筛选出一批样本数据，其实到现在可以用迭代器的方式解决，就可以避免内存不足的问题，只是这样子修改的代码就可能会稍微多一点点，又或者过滤器模式，装饰器模式或是策略模式等等这些设计模式，都是在实际中遇到对应的场景而产生出来的比较不错的代码设计模式，这些模式有可能帮助你减少重复代码，提高代码可用性和可扩展性等等。

需求整理，数据库设计及在现有的架构上对功能的扩展

对需求的整理地越为充分，对后面的代码设计为减少修改的负担，然而在我工作这两年中，遇到的比较麻烦的需求有这种情况：

1. 需要和客户对接接口，但是客户的接口请求格式或是响应格式比较特殊，因此就要进行适配，因此针对不同的客户接口适配不同的模式
2. 十分奇葩，跟业界规范格格不入的接口，比如我之前跟某咕对接点击接口时，对方使用kafka来接收消息，然而对方接收消息的机制需要登录，产生消息，下线这三个接口，因此还必须特地为咪咕编写一个发送消息的模块，发送消息的模块会对上面提到的三个接口进行调用，但是总体还算是可控范围内，因为这个模块对于点击的事件已经算是最后一步，相当来说影响已经是最小的。所以特地为兼容某个客户而去影响代码的逻辑的话，尽可能把范围控制到最小。如果有较大影响的话，还是先跟客户进行沟通。
3. 在原来的项目代码已经定型的情况上进行扩展需求，扩展需求之后随之又废弃需求，这种情况怎么说呢，确定是短期需求的话，最好将数据放在非关系型数据库如mongodb，可扩展性好，以免影响mysql存储，比如会造成数据冗余，比如扩展了一个字段，之后需求变更之后字段又用不到，所以mysql数据库设计的时候如果字段的属性范围是会动态得发生扩展的话尽可能将可能发生的变化控制在这些字段上，迫不得已才新增字段，只是会造成信息冗余，这个时候就可能要考虑分表了，不过主要工作还是需求方面，需求方面如果能比较稳定得确定下来数据库的改动会较小，也不会有那些不明所以的字段或者令人感到费解的字段取值了。

编程感悟

一开始其实也不是很喜欢打代码，但是打着打着可能也会有一定的成就感吧，比如在安排的时间内完成安排的任务，说明其实也不是完全讨厌。所以相对来说代码也许提醒了我一些东西，这其中有几件就是令我感受颇深的。

1. 当我使用python的tensorflow库高效得完成了美橙互联登录验证码识别的训练，训练效果有80%多，我从没想过cnn卷积神经网络如此强大，数学真的很强大，数学永不过时，其次是在看cnn训练网络的过程中给了我另外一个启发，cnn训练的时候按照让交叉熵最小化的方向来，并且设置梯度下降幅度，其实这里的梯度下降方向我想到了我自己的前进方向，如果我能找到让自己前进最快的方向，然后按着这个目标来前进，我的进步应该是巨大的，可惜的是我工作这两年，原先负责的老大离去，我独自维护以前的项目，为了完成临时交付的需求，急急忙忙得写完代码应付需求即可，可想而知，写出的代码当然是烂到不行，可维护性相当得差，那时候完全不知道怎么做才是比较好的，就像梯度下降幅度设置好了，但是完全不知道交叉熵最小化的方向，就只能随机梯度下降，所以进步是相当有限的，因此，其实这种情况真的也许需要改变了。
2. 当我老被老板叼的时候，其实我反思我自己为什么老能出这种又或是那种的问题，有些是错误操作处理预防不足，有些是前人留下来的锅，有些是自以为修改完代码之后认为没问题实际有问题的，这些上面的问题，可以归结于我的技术能力不够，但是其实也是公司的技术氛围环境或许是有点不怎么好了，没有能留下能力足够强大的技术骨干来形成良好的技术规范，以致于开发的时候触及到不该犯的错误，虽然我也想吐槽之前的技术负责人的错误处理也是用一个装饰器模式，然后就错误扔给装饰器处理，没有完整的事务处理机制，但这也或许是初创公司的通病，技术规范还没形成主要技术负责人就走了大半，我承认我自身不是大牛，因此希望能努力得处理这些遗留下的这些问题，但这些也许超过我个人所能处理的范围了。
3. 技术的价值以及可移植性，从以前到现在，很多技术得变得价值低微甚至毫无价值，这让我不禁想起之前C语言老师给我们做毕设答辩问的问题，你的这个程序有什么社会价值？swift被h5所取代，C#职位少，python不适用大项目高并发的问题，我学了半天的hibernate和struts2，发现后面只用到spring框架，所以我所学的技术到底是不是一门有价值的技术，我会的技术的方面的东西有多少是随着时代变化还能发挥其作用的？我也不好回答这个，唯有不断学习。
4. 关于个人进步，公司永远是希望你干活的，所以学习这东西只能靠自己。我回顾了我这两年的经历，其实学到的东西大部分是跟业务相关，当然作为一个后端了解多一点业务相关也无妨，并且掌握一些事故处理的方法，但是想说自己学到了多少，又觉得没有多少，反而是我工作之余看的技术书籍给我有一些更深的技术理解。所以工作的事情做好，也得做一些工作以外的事情。所以做什么，觉得什么是对的应该还是要有自己的一个标杆。