原文链接 https://annatarhe.github.io/2015/12/22/after-d2.html
注：以下为加速网络访问所做的原文缓存，经过重新格式化，可能存在格式方面的问题，或偶有遗漏信息，请以原文为准。
杭州一路
18号买了车票，一路小跑去了杭州。
出了火车站举目无亲，也根本不知道哪里是哪里。
由于不用手机，也拿不出导航。就按照之前在学校画的路线图坐车。
我之前从未来过杭州。而现在的第一印象是 广告之下的城市
无论在干什么，只要眼睛睁着就能看到一堆广告挤进眼里。
南京城也没见到此种盛况。说实话，心情不好了。
坐地铁转公交车。在地铁上见到一个短发版柳岩，当然没有胸。挺好看的。
在路线图上到了一个节点之后不能再走了，因为太晚了，都十点钟了。只得找宾馆。
花了一个小时左右，才总算找到个住的地方。
吃饭，洗澡，吃饭，睡觉。
顺带说一下： 府新花园北附近有家牛肉粉，特别的好吃。遗憾的是只吃了两顿。
D2 进行时
关于具体内容我不太想说，知乎有回答挺全面的。
全程感受也特别好。
这应该是我第一次大面积见到程序员。
见到程序员们感觉其实不错。大家人都挺好的。说点儿什么也都亲切。你讲点儿什么大家也都明白，就算不明白，你再多说两句就懂了。
途中和旁边的小伙子说过一些话，他是杭州电子什么大学的，才大二。不得不感叹大好年华。
和他的交谈中差不多了解到他的水平。应该是不错了。至少和我差距不大。然而他可是比我低一个年级！
不禁感叹自己老了。
一整天下来，当时感觉好像收获并不是很大。
来自腾讯的杨文坚讲了前端组件化。说实话，我收获并不是很大。我认为组件化胜在开发效率和后期维护。而组件化我认为比较难处理的就是 数据流。
最近的 Flux 比较火，我期待的是关于数据流这一部分能多说一些，顺便谈谈他们如何处理。
这场下来我去问了他一下数据流的事情，然而我表述能力有限，他并没有听太懂。
他最后对我说了一句
工程化这种事情，从来就没有万全的解决方案
现在想来，果真十分有道理。
Node.js加速Qzone 那一场我觉得挺不错。
他解决了切实的问题，而且几乎适合所有的中大型项目。
做一个本地缓存，在页面准备加载，而数据未到的时候先把老的页面给放上去。
用户做的处理，先在旧的页面上展示，等真正数据返回了再调整。
很像 meteor 的做法。 这就是的吧。。。
然后 Alinode 的一场。整个时间都在说 Alinode。解决node的单线程的错误控制和代码检查的问题。
我并没有写过大型的Node程序，所以感触不是特别深。然而这个东西在那些大公司肯定是特别重视的。腾讯的一位工程师就在问开源计划什么的。
项目大了会很有用的东西。
当时感觉
这里说个实话，当时感觉周围的人并没有让我特别肃然起敬，代码写得棒的人。
我在中午的时候听到有人说 TypeScript 结果好多人都不知道。
在开始的时候不四问台下的人写不写测试，结果只有几个人举手。
整个 D2 下来其实当时我的想法是 "不过如此"， 还是我自己倒腾好了。
D2 之后
D2 之后，看看知乎上大神的讲解。在想想当时的情形。
我发现自己错的很离谱。
杨文坚老师讲的题目叫 《Component组件设计与实践》，会不会用是一回事，设计可是完全不同的东西！
这时候会想起当时他讲的内容，何止惊艳。
兼容到 IE6, 整个代码库gzip压缩以后只有 10kb，react也得30kb哎！
想仔细回想下他讲的内容，可惜脑子太笨。没抓住时机。哎。。。
由这个事情其实想了很多。
我最近在用 Vue 写东西。这个构建流程很舒服，写起来很简单。
我在想，为什么要组件化
为何组件化
我想简单点儿说是模块化。
一个人撸10行代码其实挺难写不好的。
然而，一个人撸100k行代码却不是一般人能写出来的了。
组件化最最最好的一点是这个代码可以分离。一个500行代码的大文件分割成三个组件。命名不太扯淡的话，稍微看看就能懂。
其次应该是降低耦合。这个组件写的不好可以随手撸一个好的组件，直接替换上。
再次是降低编写难度。把组件的构建交给大牛去写，像我这样的菜狗就看着文档用大牛写好的组件就好了。
如何组件化
其实这个话题有点儿困难了。
我个人认为组件化做的最好的是 Vue
React 在js里写 HTML 其实挺别扭的。而且style还得在对应的目录下创建同名的。
Vue 的组件是这样的：
{% highlight html %} {{ title }} export default { data() { return { title: 'Hello world' } } }
.foo color teal font-size 2rem {% endhighlight %}
这个版本看起来就棒多了。真正的把一个组件放在一个文件里。
接着讲实现，我觉得其实挺难的。
首先是一个最频繁的 parse。解析做起来不是特别难，难在在量特别大的情况下还得保证效率。
还有Virtual DOM的问题。在大量DOM的情况下如何做DOM diff，然后正确的反映到真实DOM里。我觉得比较困难。
还会有其他问题，可能我哪天想试试自己撸个组件框架的时候会写个文章吧。
设计模式
同上面一个原因，十行代码用不着设计模式，十万行代码不用就是想不开了。
我之前写的zhihuCrawler即便是用了点儿设计模式到现在维护起来也是困难重重。前几天想写个log模块给放上，坐些日志记录什么的。那个代码的酸爽，简直了。
原先的想法是，这个log可以先写个装饰器模式，然后把log class给add_decoration跑。
然而这样就完了吗？哪里该写入日志，哪里该读取本地日志你确定不用改？
其实坑很多的。代码量很大的。
任何一个项目，只要代码量一上来，那个复杂是绝对的。
数据结构算法
这个是我挺头疼的。
一方面知道大公司特别看重这块儿，另一方面我又确实看不太明白。
现在想想，算法好像也是蛮有用的。
20条数据，时间复杂度为O(n2)和复杂度为O(logN)能差多少？内存占用的差别能有多大？
然而， 200万条呢？
之前在知乎爬到了200万的用户索引数据。我也是先从数据库分块读取，转存到Redis，执行爬虫。如此循环。要是直接 $db->fetchAll() 那我就能换电脑了。
开个玩笑，其实PHP有内存保护机制的。
当数据量如此之大的时候，优秀的算法，可靠的数据结构能相当大的提升效率。
我决定还是好好看看这个吧。
数据流
我觉得我对数据流挺重视的。
起因是我之前写的React在代码量上去以后，整个数据流就开始变得不可控。
一会儿这边变一下，一会儿那边又出事了。相当的痛苦。
去看Flux其实看不懂。
直到最近接触Vuex才明白了一些。
我只能说，在代码量稍微起来一点儿以后，数据流这个事情一定要管！不然数据量越大，整个工程就会越痛苦。
总结
这次D2在我的自大之后认识到了自己的渺小。
可能我知识面广一点儿，在代码量比较小的时候写的代码也不差。
但是我也要认清代码量巨大才是这个世界的真实情况。
我以后肯定也是要写工程化的大量代码。
所以还是好好学习吧