接上篇
模块
最早的时候，程序员们为了重用代码，会直接把代码 #include 到自己的项目中来，然后把库代码和应用代码一起编译出一个可执行应用。这个时间点，library
是通过源代码分发的。但是那个时候外部存储设备非常慢，而内存则非常贵并且容量很有限。没有办法把所有代码都放在内存中进行编译，这样编译器就需要多次从外部存储设备中读取源代码，然后多次访问巨慢的外部存储。可以预见，库的代码越多，可能会导致程序的编译过程就越慢，为了缩短编译时间，程序员们想出了可以把库和
application 分开编译的法子：
只要把 library 加载到固定的内存位置，例如 2000，那么我们就可以直接使用编译好的 library 了。
不过这种做法很快遇到了问题，程序自己要使用的内存很快就超过了
这半年来和同事陆陆续续有一些关于业务的代码、框架方面的争论，期间阅读过一篇陶师傅给的，推销 DCI
模式的文章/论文，认真地做了笔记。年底了，又有美团的人跳出来说互联网的业务也越来越复杂了，传统的糙快猛已经满足不了当下的需求，我们必须要认真考虑设计，而不是在学到了样子没学到根本的敏捷开发思想之上堆屎。看起来现在有不少人把矛头指向了曾经奉为圭臬的
OO 和 web 开发中最常见的 MVCL(S) 分层以及国人学了半瓶水的敏捷开发，并且各自提出了一些所谓的解决方案，比如 DCI 号称解决了 OO
驱动的开发模式下代码难以和需求所对应，而 DDD 也解决了项目上了规模以后，代码和业务描述脱节难以理解的问题。(这么看来两者解决的都是一样的问题。
虽然通过阅读，
曾经天真地认为只要严格遵守有 go 必有 recover 就能保证程序永不宕机。直到有人对开源库有了类似下面这样的误用：
package main
func main() {
var a = map[int]int{}
defer func() {
if err := recover(); err != nil {
println("oh no")
}
}()
go func() {
defer func() {
if err := recover(); err
阿里最近开源了新项目，叫 ApsaraCache，号称对 redis
做了一些优化，但开源分步骤(明显是你们没开发完吧)逐渐放出。这也进一步体现了大公司技术栈的混乱，相信在阿里内部这种类 redis
的玩艺儿绝对也不少。不过不扯这个。在 ApsaraCache 开源一期的优化中，主要有两个功能点：
1. 在 redis 4.0 的基础上增加了 memcached 协议的支持
2. 对短连接的情况进行了优化
把 ApsaraCache 的代码 down 下来用
最近想起来之前写的一个比较有意思的程序，简单说一说吧~
某互联网黑产需求
之前在帮某“互联网黑产大佬”干苦力的时候有这么一个需求，如果读者玩过某个集换式卡牌手机游戏的话应该知道卡牌的概念。手游卡牌的黑产生意实际上是通过 http
接口去刷别人的初始卡牌组合(就是看脸抽卡)。在刷卡的过程中可能会刷出一些价值比较高的初始号从而拿来挂在什么地方赚钱，这个初始号里相当于预先就存在了一些稀有的卡片，而省去了非洲人百抽不出
SSR 的窘境。而用户的购买过程则是需要提供其心仪的卡片，在已有的卡组里查询符合自己搜索条件的对应卡片。
啊，那换成微博的共同关注？
看不懂上面这段没有关系，我们把这个场景稍微修改，最近微博因为小鲜肉的恋爱爆料挂得比较惨，我们以微博的一个场景来举例：
用户 A 关注了 N 个人，把这些被 A 关注的用户 id
