在工作中，公司、团队间、部门内部的沟通，邮件是非常重要的一个渠道。如果能将邮件用到极致，那么可以让我们工作更加省时和高效，生活也变得便捷。

这里，我列举一下工作中我自己写的邮件脚本，以及一些经验之谈。具体技术就不讲了，只讲故事，主要是希望通过这些故事可以打开大家的思维，让大家知道如何去“偷懒”。

这个邮件服务印象很深刻，那是毕业工作的第一年，工作不像大学，放假时间只有过年那几天，导致那个时间段的机票很贵。而我和几个同事都是刚毕业也没多少钱，当然不愿意承担昂贵的机票。

飞机票和火车票不同，飞机票的价钱是不停地变化的。当时，我们就考虑有没有个软件，输入机票所能承受价格、时间、路线等，一旦符合标准，就自动发消息通知我们。遗憾的是，当时没有完全符合要求的软件。既然没有，既然你是程序员，既然你是做网站开发的程序员，你怎么可以忍！

所以，就打算自己写一个，刚开始需求就很明确：
1. 查一下有哪些航空公司哪些航班是从公司飞到你家的
2. 写个程序去这些网站抓取数据
3. 从数据中获取所有机票价格
4. 通过比较得到最便宜的价格
5. 最便宜的价格是否小于等于你的所能承受价格
6. 一旦符合标准，程序自动发一封邮件
7. 收到邮件，立马下单抢票
8. 开开心心回家

在编写过程中，遇到了几个问题：
1. 每个航空公司查询机票的方式不同，需要写不同的抓取程序去抓，代码量很大
2. 航空公司的机票价格并不是最低，第三方机票服务商价格更低比如去哪儿（当时去哪网比现在良心多了）
3. 航空公司的特价票有要求，有的并不能买，比如限制是青老年
4. 等等。。。

一系列问题，导致软件开发变得复杂，难以进展，我也不想占用太多下班以后的休息时间。所以当时，又换了一个思路，既然第三方便宜，那么直接去第三方抓取好了。通过接口爬取和分析，找到了去哪网的一个接口，可以满足以上需求，因此需求变得简单了：
1. 通过去哪网接口，输入航线、时间
2. 接口返回符合要求的机票和价钱
3. 根据自己所能承受的价格，找到符合标准的机票
4. 程序自动发一封邮件
5. 收到邮件，立马下单抢票
6. 开开心心回家

这是当时的配置

这是当时的收到的邮件

故事的过程很残忍，一共出现两次，在凌晨两三点钟，某个航空公司突然将价钱调到很低，时间仅持续五分钟，然后价格又变回去了。我猜，是内部组织所为，谋取暴力。
故事的解决很美好，有个同事较早买了一张很贵的机票，通过我的邮件提醒，及时发现了便宜机票，退票重买，省了五六百块钱，过年回来还请我吃了顿饭。

随着公司的壮大，随之而来的是产品多样化，产品功能复杂化，作为程序员的我们需要维护一套庞大的代码。为了让软件开发清晰、稳定，往往会将最底层代码、常用扩展、SDK等抽离出来，甚至做成框架，每个程序在框架之上运行。不同产品的开发，程序员只需要维护一套框架即可，极大减少代码维护的工作。

那么，维护这套通用代码，遇到的问题或者说挑战随之而来：
1. 通用代码的稳定性
2. 通用代码的正确性
3. 通用代码的更新

因为项目都依赖这套通用代码，正所谓动一发而动全身。我们在工作时遇到的最大问题就是：
1. 通用代码修改，各项目开发人员往往不知道，导致产品不稳定甚至出错。
2. 通用代码提交，没有清晰地描述，难以进行审核。
3. 代码提交操作很简单，也没有限制，导致大家养成了频繁提交的坏习惯。

针对这些问题，我们的解决方案是：
1. 通用代码提交，提交人需要邮件通知所有开发同事，确保信息对称。
2. 项目负责人code review审核代码。
3. 宣传代码提交规范，告诉大家减少代码提交次数。

执行下来的结果很不好：
1. 人是记性差的，提交通用代码后，很少有人记得发邮件。
2. 人是懒惰的，code review不及时、覆盖率不全，导致审核难进展。
3. 人是感性的，喊口含、宣传精神，一般都是三分钟热血，抛之脑后。

我们不得不思考有没有简单的方法解决这些问题呢？当然有！因为我们是程序员，那么我们可以写个程序呀！
1. 编写软件，定时去检查程序员提交的所有项目代码。
2. 分析提交的版本中，哪些是通用代码。
3. 得到通用代码的作者，改动描述，版本和时间等信息。
4. 将信息发送给所有相关同事。

以前全部是个人主观意向，往往偷偷提交好多次代码，才告诉大家甚至不告诉大家。而现在邮件是机器发送，改的频率越高，发送的越多，甚至会对别人造成打扰。这样就彻底地解决了大家频繁提交的坏毛病。

提交次数少了，每次提交都是合理的，对通用代码进行很好的升级，所有人当然愿意仔细去看代码改动，项目负责人也愿意审核改动是否是最优的，项目的稳定性自然就有了很大改善。

这是一张邮件截图：

和代码提醒类似，我们可以做很多事情，来帮助程序员提升工作效率。

比如我们做的小白系统，解决了最大的痛点就是code review。平时我们在做代码审查时，经常发现一些问题，比如：
1. 代码不按照规范来写。
2. 程序没有错误处理。
3. 无用函数、方法、注释、文件等，没有及时清理。
4. 函数过度封装。
5. 逻辑判断存在缺陷。
6. 代码存在xss、sql注入问题。
7. 等等

这些问题，往往是code review中出现次数非常高，而且每个项目都存在，即有一定的通用性。

我们进行归纳，完善了一套检测标准，大家每次code review按照这个标准就能发现这些潜在问题。标准都有了，还要人干嘛，对每一类问题进行详细的归纳，其实是可以让程序实现这套检测的，无非就是牛逼的正则和复杂的语句逻辑判断。所以我们写了一个小白系统，它支持灵活的扩展，所有code review通用问题检测都是以插件的形式存在于系统中，再加上检测频率控制、问题优先级设计、用户体系配置和邮件模板，小白成型了！

真的很爽：
1. code review不需要总是花时间浪费在检测代码规范这种问题了。
2. 以前通用性问题总是靠人眼检测，往往覆盖率不高，程序检测一个逃不掉。
3. 程序运行的实时性，让大家及时发现问题、及时改正问题。
4. 可扩展性，人工code review时，一旦发现通用性问题，即可提需求给小白系统的维护者，维护者编写个插件，搞定。
5. 好处真的很多，只能用爽来形容。

给个简单的截图：

刚才说到爽，我们就深入一下吧。

事情是这样的，市场部门的小伙伴每天早晨会去看一些文章，关于公司产品宣传／用户活动推广／媒体渠道采访等，这些文章访问量是市场决策的一个依据。这些所有访问网址，都生成了短链，访问是通过短链进行跳转的。所以市场同学会整理并记录最近需要的短链地址，然后每天早晨去短链平台查询这些短链的访问量。

当我发现她们每天是这么操作时，我给她们提了个建议，说可以写一个脚本，每天早晨定时去爬去所需要的短链访问量，然后发邮件给她们。可想而知，市场小伙伴很开心的同意了。

具体产品形态非常简单，提供个简单的后台页面，允许定制化：
1. 输入想要采集的所有短链网址。
2. 输入需要发送的邮箱地址。
3. 支持删除／修改。

将配置存入到数据库，脚本每天早晨定时从数据库获取数据，然后抓取，数据整理，发邮件。整个开发过程一个小时内就搞定了，不过解决的却是——帮助市场很多同事每天早晨节省五分钟。

作为一名喜欢网络安全的人，如果没有用程序和邮件打过交道，那是绝对不合格的。

在一些网络攻击中，攻击往往像地雷一样，等待用户踩上，这类攻击都是非实时攻击。非实时攻击中，黑客会留下后门，一旦处罚攻击马上发邮件。这里就不在深入讨论了，如果想要了解，可参考这篇文章，说明了邮件使用的一种思路：

利用jsonp原理精准定位约炮需求用户

就讲到这里吧，你是否对邮件产生兴趣了呢？