IT瘾艺术推荐

agentic coding 本质上是文档管理的艺术

Tue, 23 Dec 2025 09:59:55 CST

今天回东京后继续研究 agentic coding，由于本地项目是从 0 搭建的，需求和文档随着和 codex 和 cc 的沟通越来越明确，文档的复杂程度也逐渐加深。

这让我越来越觉得 agentic coding 本质上是文档管理的艺术，从 vibe coding 发展了一年后，自然语言编程似乎慢慢将软件工程转换为了文档工程。

最初，需求极其模糊。llm 会按照自己的想法为我们想做的事情设定一个 roadmap 和 mvp 版本，这是从零开始的第一步，它决定了迭代的大版本号。我一般会让 llm 在本地生成两个文件，第一个毫无疑问是 agent constitution，第二个是 http://roadmap.md 这是非常重要的文件，所有的需求，都会从这个文件的迭代 session 中派生出来，顺序是 roadmap:v0.1 -> stories/xxx.md 这里的 story 其实就是需求白板中的任务，它可能涉及到 API 或者 UI，包含几个甚至十几个复杂的任务，每一个 story 文件，都会是一个单独的文件，涵盖着某个可被测试的需求完整的结构，任务完成情况和相关联的文件路径。

stories 文件夹中每完成一个需求，我会要求 codex / cc 在 docs 对应的路径创建一系列 md 文档，以标记一个功能所涉及到的状态，如果这个功能产生了 bug，就在修复 bug 的过程中继续在这个文档中记录 bug 修复进度，于此同时，也要求它按照文档结构来组织 lib 或 api router 文件。以此类推，文档系统会形成一个巨大的网状结构，最终，它会成为整个产品的故事和描述文件。

传统的软件工程里，这个是产品经理干的活儿。但对于自然语言编程来说，这个任务变成了工程师的责任。一开始，我还设计了一个 architecture 文档，以要求 cc 用对应的技术栈来完成功能，后来，我发现随着软件的生长，强行要求一个万能的程序员按照人类的技术栈来实现功能并没有什么意义（维护已存在的项目除外）所以我废弃了这个文件，只维护产品故事和需求描述。

在整个 agentic coding 的过程中，我基本上只和文档打交道，在另外一个浏览器界面等待完成的需求被刷新，没关心过代码重构和其他技术问题，这让编程（如果还能这样定义它的话）成为了一种极其容易进入心流的对话情境，以我个人的体验来说，这是一件非常好的事儿。如果你没体验过 agentic coding，我推荐大家尝试一下！

超预期寿命：长寿的科学与艺术

Mon, 13 Nov 2023 07:54:09 CST

精英日课解读了一本2023年3月28日出版的新书《超预期寿命：长寿的科学与艺术》（Outlive: The Science and Art of Longevity）。作者是彼得·阿提亚（Peter Attia）。

阿提亚出生于1973年，毕业于斯坦福大学医学院，在约翰·霍普金斯医院当过住院医生，本来做手术有两下子，后来辞职去了麦肯锡咨询公司，现在自己创业做长寿项目。

万维钢老师特别赞赏阿提亚强硬的智识态度。我从第一性原理出发，看看这个事儿究竟是怎么回事，我自己拿个主意。你们要是说服不了我就改变不了我 —— 而且我还要改变你们。阿提亚不但有医学知识，还有临床经验，还有咨询公司的数学能力，还特别敢想敢干，可以说是个难得的人物。但是这些经历还不足以说明阿提亚有多厉害。这本书，才是他真正厉害之处。

这不仅仅是一本教你如何长寿的书。这是针对整个医疗体系的革命宣言。

当今的医疗体系可以说已经非常厉害，但是，是没有希望的。

阿提亚把目前为止的医学分成了两个阶段。

➡️ 一个是「医学1.0」，大概可以以西医的祖师爷、古希腊的一位医生，希波克拉底为代表人物。希波克拉底的贡献是把医学和巫术和哲学分离，使之成为一门专业学科。但是请注意，即便有了专业性，医学1.0也只是基于直接观察和经验做事，很多说法都是猜测性的，谈不上科学。也许中医也可以归为医学1.0。

➡️ 1.0的医生再聪明再努力也没有大用，因为你没有特效药。医学2.0带来的寿命改善主要是通过使用抗生素和通过改善卫生环境控制传染病实现的。一百多年以前，大部分人死亡是因为某种*急性*的病因，比如受伤感染，而医学2.0很成功地解决了这些急性问题。

现在大多数人都能活到七八十岁，人们死亡主要是因为一些慢性疾病 —— 这是医学2.0未能很好地解决的问题。阿提亚把现在导致死亡最多的四种慢性疾病称为“四骑士” —— 对标《圣经》里代表瘟疫、战争、饥荒和死亡的天启四骑士：

❌ 2型糖尿病

❌ 心脏病

❌ 癌症

❌ 神经退行性疾病（比如阿尔兹海默症，也就是老年痴呆症）

阿提亚认为，医学2.0对付“四骑士”的思路根本就是错的。因为它总是在病情发作之后才开始干预。阿提亚提出了「医学3.0」的概念，它跟2.0相比有四个特点 ——

✅ 1. 重视预防而非治疗；

✅ 2. 把每个患者当成独特的个体，因为每个人对比如说不同营养成分的反应是不一样的；

✅ 3. 从风险管理角度去干预，而不是固定走流程；

✅ 4. 不但要追求生命长度，还要追求健康度。

阿提亚乐观的判断是，现有的知识和手段，有可能把人健康的寿命增加10年到20年。

这本书的一个特点是用到的知识都非常新。书中关于营养学的说法跟市面上大多数营养学家说的就不一样。阿提亚的调研能量相当充沛，书中都是最前沿的研究结果。这些结果有五个主要来源：

👉 1. 对百岁老人的系统性研究；

👉 2. 动物实验；

👉 3. 对“四骑士”的最新的医学认知；

👉 4. 在细胞层面上对衰老机理的理解；

👉 5. 自然随机试验。

阿提亚不只是总结，他更要采取行动。他的健康策略是从五个方面入手的：最重要的是运动，然后是营养、睡眠、情绪健康以及药物。

长寿机制

彼得·阿提亚在《超预期寿命》这本书中列举了一组有关百岁老人的事实，这里面可能有长寿的秘密，但是要抓住那个秘密可不容易。

年龄超过100岁的人只占人口总数的0.03% —— 也就是三千多人中才有一个。人过了一百岁，每年的死亡率就会达到36%，人数会快速衰减。能活到110岁的老人被叫做“超级百岁老人”，这个人数，全世界在任何时候都最多只有300人左右。极少有人能活到117岁，能活到的基本都是女性。世界上有据可查的活到120岁的人，只有一个。120岁可能就是写在基因里的人类寿命的上限。

有大型研究显示，普遍来看，百岁老人并不比普通人更注重健康。他们中有很多人酗酒，抽几十年的烟；他们在70岁时经常锻炼的比例也低于同年龄的对照组；他们中不少人体重超标。他们到底为啥能长寿呢？只可能是基因的作用。

在做了大量研究之后，科学家发现了几个基因，对长寿有重要影响。

➡️ 有一个基因叫APOE，它对阿尔兹海默症有明显的影响，主要是因为它对大脑中运送胆固醇有重要作用。它有个变体还对葡萄糖代谢很有影响。

➡️ 还有个基因叫FOXO3，属于转录因子，它能决定其他基因是被激活还是被表达，从而调节新陈代谢。它能开启细胞修复的任务，还可以决定什么时候清理垃圾。

这两个基因就对我们很有启发。它们的存在说明第一，要想长寿，你需要关心胆固醇和葡萄糖；第二，新陈代谢、细胞修复和垃圾清理非常重要。那么有了这个线索，就算我们身上的基因版本跟百岁老人不一样，我们也可以模仿。比如FOXO3的作用，其实你通过运动和营养调节也能激活。

百岁老人有那个基因版本，所以他们不运动、随便吃也没事；你没有那个基因版本，那你多运动、少吃点，也可能能达到同样的效果。

大自然还送给我们另一个长寿线索，那就是「雷帕霉素（rapamycin）」。2009年，经过多家实验室重复验证发现，雷帕霉素能显著延长小白鼠的寿命。特别是它还能延长年老的小白鼠的寿命 —— 类比到人类，相当于能让一个60岁的人活到95岁。怕累霉素是复活节岛送给我们一个长寿药。

糖尿病

最终会导致2型糖尿病的新陈代谢问题

代谢功能障碍不仅仅通往糖尿病，它跟“四骑士”中其他三种病 —— 心血管疾病、癌症和神经退行性疾病都很有关系，可以说代谢就是健康的根本。

代谢功能是个复杂系统，但是它失控的前兆是简单的。那就是「胰岛素抵抗」。

皮下脂肪是最安全的脂肪，不会给身体带来坏处。又能随时释放能量，又能保暖，其实挺好。皮下脂肪不影响代谢功能。你吃的实在多，把皮下脂肪已经充值满了，还有多余的糖，怎么办呢？这大概就是代谢功能全部的问题所在。就好像一个浴缸已经满了，你还在往里注水一样。水必然会流到地板上，给你带来麻烦。胰岛素会把皮下脂肪之外还多余的糖送入以下这些地方变成脂肪，从而造成各种问题 ——

❗ 送入肝脏，会形成非酒精性脂肪肝；

❗ 送入肌肉组织，会导致胰岛素抵抗；

❗ 送入腹部，形成内脏脂肪；

❗ 送入血液，会导致动脉粥样硬化；

❗ 送入心脏和胰腺周围，引发相关病症……

现在医学界使用五个指标用于判断「代谢综合征（MetSyn）」，分别是高血压、高血脂、高密度脂蛋白胆固醇偏低、中心型肥胖（也就是肚子大）和空腹血糖升高。五个指标中满足三项，就是代谢综合征。美国有1.2亿人有代谢综合征，有90%的人至少符合其中一项指标。你不可能说这90%的人都不正常，但这些所谓的正常人都不健康。

阿提亚认为最关键的指标还是胰岛素。

胰岛素抵抗如果继续发展下去，下一步就是糖尿病前期，再下一步就是非酒精性脂肪肝，再进一步就是2型糖尿病。也就是说，2型糖尿病其实是代谢系统经历的一系列崩坏的最后一站。得了2型糖尿病，又给四骑士中的其他三种疾病铺平了道路……

这一切都起源于多吃的那一口糖。说来说去，都是因为吃得太多。脂肪过剩是现代富足社会才有的疾病。

心脏病

现代人死亡的第一杀手就是心血管疾病。《超预期寿命》这本书的作者彼得·阿提亚认为，我们已经有足够好的手段，让心血管疾病从第一杀手的位置落到比如说……第十杀手。前提是你提早干预。很早，很早就干预。

很多人认为动脉粥样硬化是胆固醇过高造成的，这是一个长期以来的误解。2015年，给美国政府提供饮食指南的咨询委员会终于承认，胆固醇并不是一项值得关注的过量摄入的营养素。

阿提亚认为，总的原则应该是减少载脂蛋白B的存在感，这意味着LDL浓度越低越好，而且要把血脂—— 包括各种脂蛋白 —— 水平降下来。我们前面说了，代谢系统的一个问题就是胰岛素把多余的糖送入血液变成脂肪。有研究表明，只要LDL浓度没有超过正常生理需要的水平，动脉粥样硬化就可能不会发生。

阿提亚建议用药物干预。最常用的就是他汀类药物降血脂。阿提亚本人是积极用药，所以他50岁时的心血管疾病风险反而比36岁时还要低 —— 他的目标是把人的载脂蛋白B浓度降到儿童水平。

癌症

癌症是个天大的难题。就连阿提亚的这本书的总体基调是乐观的，他也认为在我们有生之年，除非发生奇迹，否则根本就没有完全治愈或者完全预防癌症的可能性。但你也不能说前景只有悲观……我们的确能做一些事情。

什么是癌症呢？简单说，癌症是细胞在不该长的地方疯狂生长，以至于形成肿瘤。癌细胞和正常细胞有两个不同之处，这两个特点定义了癌症：

➡️ 第一个特点是癌细胞在应该停止生长的时候没有停止生长。

➡️ 第二个特点是癌细胞可以从身体的一个部位转移到比如说很遥远的另一个部位，乃至于扩散到很多个部位。

除了癌细胞在该停止生长的时候不停止生长、容易发生扩散这两个特征之外，不同的癌症之间基本就没有相似度了。癌症不是一种病，而是对很多种病的统称。乳腺癌和胰腺癌完全不同，各种癌症都不同。这意味着你不可能用一种药或者一个疗法治疗所有的癌症。

当然医学还是有进步的，有些新疗法作用很好。一个是靶向药。基因组项目还是很有用的，针对一些特定癌症的特定基因，确实有一些很有效的靶向药。但这方面阿提亚没有多说，阿提亚重点讲的是免疫疗法。

有效的概率太低。只有1/3的癌症可以用免疫疗法治疗，而在这些可以治疗的癌症之中，也只有1/4的患者能真正受益。别人为啥就不行……你也猜到了，那可能是基因的原因。但免疫疗法有个最大好处是只要它起作用，就能把病给你治好，而且不会反弹，它能让这种癌细胞消失。

但真正最好的办法还是早发现早治疗。癌症有几十种。这几十种不同类型的癌症之中，目前只有五种，有公认的、可靠的筛查方法。它们是肺癌、乳腺癌、前列腺癌、结肠直肠癌和宫颈癌。现在有些体检项目会把这几种癌症的筛查加进去。

阿提亚主张激进地进行癌症筛查，因为他认为收益还是大于风险。尤其是结肠直肠癌，很容易发现，回报最大。

神经退行性疾病/老年痴呆

《超预期寿命》一书中提到的死亡 “四骑士”的第四个是 —— 神经退行性疾病，也就是大脑的退化，最典型的就是阿尔茨海默症。

为什么说阿尔茨海默症是一种病呢？首先这是一种生理上的症状。犯糊涂，不仅仅是想法变了，而是大脑的整个硬件发生了巨变。

如果你去做基因测序的话，你要重点关注一个跟阿尔茨海默症密切相关的基因，叫ApoE。ApoE这个基因有三个版本，分别为E2、E3、E4。你从父母身上各得到一个版本，这是一种抽奖。E3是最常见的版本，我们把它作为基准。如果你抽到了E2，你很幸运，因为E2会降低阿尔茨海默症的风险。比如你抽到E2和E3，你就比两个都是E3的人得阿尔茨海默症的风险要低10%；如果抽到两个E2，风险就会降低20%。但如果你拿到了E4，那就很不幸运。如果你只拿到一个E4，你得阿尔茨海默症的风险就比E3版本要高出两倍。而如果你拿到的两个版本都是E4，你患病的风险就提高了12倍。

如果你现在还比较年轻，那别太着急。即使是有两个E4版本的患者，这个病一般也是65岁以后才发展到临床阶段。在此之前你可以做很多事情。

✅ 比如认知训练。

阿提亚综合各种研究的结论是对心脏、肝脏和胰脏有益就是对大脑有益。那么这就是一个身体综合治理的问题，手段还是运动、饮食、睡眠、情绪和药物。有两个有意思、很有作用、而你可能没想到的发现。

✅ 一个是牙齿健康和阿尔茨海默症之间有强烈的相关性。所以哪怕为了保护大脑，你也应该坚持刷牙并且使用牙线，而且要定期去洗牙。

✅ 还有个特别有意思的方法是去桑拿房干蒸。阿提亚调研的判断是如果你每周至少4次、每次至少20分钟，在至少摄氏82度下蒸一蒸自己，竟然能把阿尔茨海默症的风险降低65%，把急性心血管疾病的风险降低50%。

导致现代人衰老和死亡最重要的四种原因 —— 代谢障碍、心血管疾病、癌症和神经退行性疾病 —— “四骑士”. 阿提亚把应对策略分为五个方面：运动、营养、睡眠、情绪和药物。

运动

而对长寿来说，最重要的杠杆就是运动。运动是对健康和寿命最有效的干预，比任何药物、任何其他干预措施都有效。而且运动之中还有运动的杠杆。我们最应该关心的是三个指标：心肺功能、肌肉力量和稳定性。

现在学界已经形成共识，这个中等强度有氧运动，就是一切锻炼的根本。如果你只能练一门功夫，练这个就对了。

在这个基础之上，我们需要优化三项指标。

✅ 第一个是心肺功能指标，叫做「最大摄氧量（VO2 Max）」。它的意思是你每公斤体重每分钟可以消耗的最大氧气量。这个数值越大越好。阿提亚说，最大摄氧量也许是唯一最有力的长寿标志。最大摄氧量高说明心肺功能强。什么叫身体好？这就叫身体好。中等强度有氧运动也能在一定程度上提高最大摄氧量，但是为了更有效，你最好上高强度的有氧训练。这是一种间歇式的训练，快跑、骑自行车和用划船机都可以。比如你可以以接近冲刺的速度快跑4分钟，然后慢走4分钟，然后再快跑再慢走，这样重复四到六次。

✅ 第二个指标是肌肉力量。前面说的中等强度有氧练的都是1型肌肉纤维，但是你还需要锻炼2型肌肉纤维，也就是能快速抽动、让你“有劲儿”的肌肉。

✅ 第三个指标是稳定性。稳定性的作用是让你不受伤。一个测量稳定性的方法是双手叉腰单腿站立四十多岁的人的标准是闭眼单腿站立7秒钟，睁眼40秒钟；七十多岁则是闭眼2秒钟，睁眼18秒。

营养

阿提亚在《超预期寿命》这本书中全面总结了营养学的现状。万维钢读下来的结论是，“吃”不能给你吃出来一个好身体，但如果你身体不好，你需要注意吃。

并没有一种食物真能预防癌症。所有的什么吃这个能防癌、吃那个能致癌的说法，就算是流行病学研究的结论，也是要么不靠谱，要么只是个十分微小的效应。人们日常接触的东西里，科学家明确知道的、效应比较大的防癌致癌信息只有「吸烟会大大增加肺癌的概率」这一条。

什么冬虫夏草、什么燕窝鱼翅的疗效都是老百姓“把稀有当珍贵”的思维偏误。有些人相信茅台酒有健康功效，那是愚昧。至于说什么茅台必须用少女踩曲、某某茶叶必须让少女采摘，那就不但是愚昧，而且是野蛮。

如果你非得问有没有最简单的“该吃与不该吃”，那么阿提亚书中提到三种食物，有相当坚实的、可以说是非黑即白的科学结论。

✅ 第一，不要喝任何含有果糖的饮料。你吃水果没关系，但如果你是一个严肃对待营养学又有强硬意志力的人，我建议从此戒断所有的含糖汽水、果汁和奶茶。

✅ 第二，酒精没有任何健康好处。酒精带给人唯一的好处是快乐。

✅ 第三，如果你非得问哪种饮食风格好，那么现有研究证据最支持的是「地中海饮食」。地中海饮食不忌讳脂肪也不强烈反对碳水，讲究多样性，其中最关键的两种东西是橄榄油和坚果。所以，你以后可以把炒菜用的油都改成橄榄油，把坚果当零食，而且别怕脂肪。

你应该考虑的不是具体的食物，而是食物的营养成分。我们需要对三种营养成分制定科学策略：碳水化合物、蛋白质和脂肪。

👉 碳水化合物。科学的做法不是取消碳水，而是控制碳水。

一种尽量避免碳水化合物 —— 干脆不吃米面、只吃肉蛋奶和蔬菜 —— 的所谓「生酮饮食」比较流行，阿提亚本人也尝试过一段时间。他现在的看法是生酮饮食是一种极端的做法，应该只对比如说糖尿病患者使用。

阿提亚从血糖检测仪数据中总结出一些对所有人都有用的规律 ——

➡️ 越是精致的碳水化合物，升糖速度和水平就越高。这意味着你应该吃加工程度比较低、纤维含量比较高的东西，而不是大米白面。但是糙米的血糖值只比大米低一点点。

➡️ 中等强度有氧运动最能有效清除葡萄糖。高强度运动因为会促使肝脏输送更多葡萄糖，会让血糖短暂升高，但那不是毛病。

➡️ 菠菜和西蓝花之类的非淀粉类蔬菜对血糖几乎没有影响，可以随便吃。

➡️ 高蛋白和高脂肪食物 —— 比如鸡蛋、牛排 —— 对血糖几乎没有影响，鸡胸肉之类的瘦肉蛋白也只会让血糖轻微升高。别怕吃肉。

👉 蛋白质。对大多数人来说，蛋白质的问题不是吃多了，而是吃少了。蛋白质和组成蛋白质的氨基酸是构建我们身体的材料，蛋白质摄入不足你的肌肉就会流失。蛋白质不是能量来源，我们的身体不会储存多余的蛋白质，吸收不了的就直接变成尿素排出体外了。所以不用担心蛋白质过剩。美国政府有个对每天蛋白质摄入量的标准建议，阿提亚表示很不屑，认为那个建议量太小。他认为体型跟他差不多的成年男性每天的蛋白质摄入上限大约是七八块鸡胸肉这种水平。

最好的蛋白质来自肉蛋奶，也就是动物蛋白。那你说我是个素食主义者，我只吃豆腐什么的植物蛋白行不行？答案是不太行。植物蛋白往往被难以消化的纤维所束缚，阿提亚认为营养效率太低，你得吃很多才能吃够。

👉 脂肪。肪既提供热量也提供蛋白质，而且以胆固醇形式给身体提供激素，脂肪酸对新陈代谢平衡和大脑健康都很有用，你需要脂肪。很多人认为吃脂肪会变胖，其实最能让你变胖的是大米白面那种纯碳水化合物。脂肪的好处是它把碳水和蛋白质相结合，很容易让人产生饱腹感，你不会吃太多的。

总而言之，碳水要限制吃，蛋白质要尽量多吃，脂肪则问题不大。

现在流行一种“16小时断食”节食法，也就是每天选择固定的八个小时可以吃东西，其他时间禁食，阿提亚对此不以为然，因为研究结果不支持这个做法的有效性。至于说长期的节食，那就更不对，因为你会因为蛋白质摄入不足导致肌肉流失，而且你的免疫力也会下降。只有严重营养过剩、必须上非常规手段的情况下，才应该搞禁食。

根据目前最好的知识，阿提亚把营养总结成以下四条基本规则 ——

✅ 1. 不要摄入过多或过少的热量；

✅ 2. 摄入充足的蛋白质和必需的脂肪；

✅ 3. 获得所需的维生素和矿物质；

✅ 4. 避免大肠杆菌等病原体以及汞或铅等毒素。

睡眠

你身边有没有那样的人？他们的精力好像根本用不完，做事儿能量特别足，不但能轻易全神贯注而且还积极主动。他们更有创造力，自动冒新想法。他们的健身效果都比别人好。他们的形象也好，整天红光满面神采奕奕。他们的长相比实际年龄年轻，连皱纹都比别人少。他们必定有充足的睡眠。

你每天需要七个半小时到八个半小时的良好睡眠。阿提亚说有多项研究表明，这是一个不容商量的、由人体硬件规定的时间长度。

但是请注意，睡眠时间长短是个问题 —— 但是熬夜，可未必是个问题。有的人喜欢早睡早起，有的人习惯晚睡晚起，其实都可以。

更重要的认知是睡眠不是一个累赘，也不只是一种享受，睡眠是健康的必须。

慢性缺觉，也就是长期的睡眠不足，则直接就是一个健康杀手。你的免疫力会下降，你会比别人更容易得普通感冒，你的荷尔蒙平衡会受到破坏。更重要的是，你更容易陷入代谢功能障碍和心血管疾病。

如果你的勤奋已经到了影响睡眠的程度，那不是健康的勤奋。

阿提亚分析，睡眠不足影响代谢的机制可能是压力。睡不好，你的情绪得不到缓解，你的心理压力就大。心理压力大又往往导致更睡不好，这是一个正反馈过程。

阿提亚说，安眠药的作用不是让你真正入睡，而是让你……昏迷。真正的睡眠是有周期的，得有深度睡眠和快速眼动睡眠才好，昏迷可没有那样的阶段。

如果你有严重的失眠，你只能去找医生谈谈。但如果是一般的失眠，最好的办法是营造一套有利于睡眠的环境和生活习惯：

✅ 一个是不管黑天白天，只要想睡觉，就一定要把房间弄得非常黑才行。只有黑暗环境能让跟视觉直接相连的松果体释放褪黑素，这种荷尔蒙能告诉大脑该睡觉了。而这又意味着睡前一两个小时内都不要使用像手机、平板电脑之类带有屏幕的东西，因为电子屏幕会发出蓝光，蓝光很像太阳光，会阻碍褪黑素。

✅ 一个是睡眠环境的温度要低一点。跟一般人想的可能不太一样，人入睡的信号之一是体温下降大约一摄氏度。要做到这一点，睡觉时候卧室的最佳温度是大约18.3摄氏度（华氏65度）。这也说明睡前洗个温水澡会有帮助，因为能降体温。

✅ 白天做做运动，特别是中等强度有氧运动对睡眠很有帮助。但为了睡眠，这种运动最好在阳光充足的时候进行，不要在睡前两三个小时运动。

✅ 对付失眠的一个好办法是把“困意”攒起来。医生会建议你白天不该睡觉的时候哪怕有点困也不要睡，等晚上一起睡。

✅ 很多人认为喝酒有利于睡眠，那其实是个错误的认知。喝酒的确让你容易入睡 —— 但是也容易让你醒来。

✅ 那咖啡就更不能喝了。这里的关键是每个人对咖啡因的耐受性和代谢速度不一样。有的人需要六个小时才能代谢掉一杯咖啡，这意味着你到了下午就不应该喝咖啡了。

✅ 还有就是避免压力。尤其是睡前别做那些让人焦虑的事情。

总而言之，长寿不容易，长寿不属于所有人，长寿需要你在某些方面享受奢侈。别人忙碌你睡觉，这就是真正的奢侈。

情绪/心理健康

《超预期寿命》这本书提出的应对死亡四骑士的方法之一是情绪，即精神健康，更严格地说是情绪健康。

现实是直到目前为止，大多数人并不认为情绪健康是一个需要治疗的问题。可能你身边有个人整天发怒、是个自大狂、动不动就指责别人，而你觉得这就是一种个性。那不是个性，那是一种病。这就如同肥胖不是一种身材类型，而是一种病态。精神创伤不是少数人的事情，也不是只是“软件”问题。它是对身体健康的残害。

童年的痛苦经历，会让人到了成年仍然长期处在痛苦之中。情绪痛苦的一种表现是容易发怒，于是就容易跟人冲突，而这就容易引发心脏病。情绪痛苦的另一种表现是自杀。所有年龄段的前十大死因中都包括自杀。但情绪痛苦最常见的表现，则是不爱惜自己的生命。患者可能会酗酒、滥用药物、吸毒，可能专门去做一些没什么意义的危及生命的事情。他们生活在绝望之中。这种自暴自弃，等于是慢性的自杀。

阿提亚小时候受过连续的虐待。但作为一个男人，你不会去寻求帮助，你反而会把那些经历视为羞耻。你认为唯一正确的反应就是把自己从受害者变成复仇者 —— 羞耻感，就这样变成了自大感。把羞耻化为自大的确可能给你一个巨大的激励。但是在阿提亚的心理医生看来，这在长远上，只会给生活带来灾难。一项工作没做好，阿提亚感到羞耻。羞耻变成了愤怒，于是阿提亚对自己的孩子大喊大叫。事后又觉得不该拿孩子出气，于是又感到羞耻。然后又是对自己的愤怒。这是一个恶性循环。后来阿提亚开长寿公司，他有个病人，是一位非常成功的知名人士，说过一句话，最能概括这种心态：「我需要变得伟大，这样我才不会觉得自己一无是处。」

童年创伤有五种 ——

➡️ 1. 身体、性或者精神和情感上的虐待；

➡️ 2. 被忽视；

➡️ 3. 被遗弃；

➡️ 4. 父母与孩子之间界限不清晰，比如把大人的事儿让孩子做、把孩子当成满足自己情感需要的工具、侵犯孩子的私人空间、过度控制孩子等等；

➡️ 5. 目击灾难事件。

这些创伤不论大小，共同的特点是让孩子产生*无助感*。你不喜欢这样，你很痛苦，可是你无力改变。但你总得做些什么去适应这个局面，于是就有了一直持续到成年的各种功能障碍，也就是创伤树的四个分支 ——

❌ 1. 上瘾，包括对毒品、药物、酒精的上瘾，也包括对工作、锻炼和完美主义的上瘾；

❌ 2. 心理上过度依赖他人；

❌ 3. 习惯性的愤怒和暴躁倾向；

❌ 4. 难以与他人建立或保持有意义的关系。

有一派方法论叫「辩证行为疗法（dialectical behavior therapy, DBT）」，专门帮助有严重情绪问题 —— 称之为「边缘型人格障碍（borderline personality disorder）」—— 的患者。这个疗法认为光找到原因、有了认知是不够的，你要把良好的情绪能力当作一项需要好好练习的技能，这是一套行为疗法而不是认知疗法。辩证行为疗法的有效性得到了临床实验的证实。练习的目标是打破「负面刺激 → 负面情绪 → 负面想法 → 负面行动」这个连锁反应，说白了就是控制自己不要一点就炸。就是你要在刺激和反应之间找到自主决定如何反应的自由。

做到这一点，你得在自己陷入愤怒之类的负面情绪的时候能主动跳出来，观察自己，认识到自己现在是个什么状态、是什么样的刺激把自己变成了这个样子。这其实很困难，你可能需要药物的帮助，但是正念冥想很有用。更重要的是行动。要非常积极主动地去做一些事情，要改变行为模式，以至于哪怕遇到负面刺激也能淡然处之。阿提亚打了一个比方，人对各种苦恼、各种烦心事的承受能力就如同一个垂直开合的窗口：窗口越宽你的心就越宽，窗口越窄你遇到事情就越容易情绪失调.

很多外界因素会压缩你的窗口，而你平时要做的就是通过行为练习来扩大这个窗口。体育锻炼、充足睡眠、良好的营养、一些调节情绪的药物、接触大自然、不计较胜负的娱乐活动都有帮助，但是以下这些方法可能更重要 ——

✅ 关键是改善人际关系。阿德勒不说吗？人际关系是一切烦恼的根源。如果你跟周围的人有良好的关系 —— 比如最起码跟家人关系很好 —— 你的窗口就有一个坚定的支

✅ 人相处的一个好办法是用对方的视角考虑问题，这叫认知「重构（reframing）」。你觉得你很忙、你做的事儿最重要，别人都应该给你让路 —— 可难道别人做的事儿就不重要吗？想想他人视角中的你此刻是个什么形象，对你会很有帮助。

✅ 还有个技巧是反向行动，也就是主动做跟自己的冲动相反的事。阿提亚有一次在家里，工作特别忙，妻子要带孩子出去玩，他明确说了自己不会去。就在这时候，阿提亚跳出了习惯的模式，来了个反向行动，主动跟着妻子和孩子出去，效果非常好。

✅ 后一个建议是你对你自己也要好一点。把自己当成一个好朋友对待，不要苛求，要包容和鼓励 —— 这也是我们多次讲过的「自我关怀」。

长连接网关技术专题(四)：爱奇艺WebSocket实时推送网关技术实践

Mon, 17 May 2021 23:12:00 CST

本文由爱奇艺技术团队原创分享，原题《构建通用WebSocket推送网关的设计与实践》，有优化和改动。

1、引言

丛所周之，HTTP协议是一种无状态、基于TCP的请求/响应模式的协议，即请求只能由客户端发起、由服务端进行响应。在大多数场景，这种请求/响应的Pull模式可以满足需求。但在某些情形：例如消息推送（IM中最为常见，比如IM的离线消息推送）、实时通知等应用场景，需要实时将数据同步到客户端，这就要求服务端支持主动Push数据的能力。

传统的Web服务端推送技术历史悠久，经历了短轮询、长轮询等阶段的发展（见《新手入门贴：史上最全Web端即时通讯技术原理详解》），一定程度上能够解决问题，但也存在着不足，例如时效性、资源浪费等。HTML5标准带来的WebSocket规范基本结束了这一局面，成为目前服务端消息推送技术的主流方案。

在系统中集成WebSocket十分简单，相关讨论与资料很丰富。但如何实现一个通用的WebSocket推送网关尚未有成熟的方案。目前的云服务厂商主要关注iOS和安卓等移动端推送，也缺少对WebSocket的支持。本文分享了爱奇艺基于Netty实现WebSocket长连接实时推送网关时的实践经验总结。

学习交流：

- 即时通讯/推送技术开发交流5群： 215477170 [推荐]

- 移动端IM开发入门文章：《新手入门一篇就够：从零开发移动端IM》

- 开源IM框架源码： https://github.com/JackJiang2011/MobileIMSDK

（本文同步发布于： http://www.52im.net/thread-3539-1-1.html）

2、专题目录

本文是系列文章的第4篇，总目录如下：

《长连接网关技术专题(一)：京东京麦的生产级TCP网关技术实践总结》

《长连接网关技术专题(二)：知乎千万级并发的高性能长连接网关技术实践》

《长连接网关技术专题(三)：手淘亿级移动端接入层网关的技术演进之路》

《长连接网关技术专题(四)：爱奇艺WebSocket实时推送网关技术实践》（* 本文）

其它相关技术文章：

《绝对干货：基于Netty实现海量接入的推送服务技术要点》

《京东到家基于Netty的WebSocket应用实践分享》

爱奇艺技术团队分享的其它文章：

《爱奇艺技术分享：轻松诙谐，讲解视频编解码技术的过去、现在和将来》

《爱奇艺技术分享：爱奇艺Android客户端启动速度优化实践总结》

《爱奇艺移动端网络优化实践分享：网络请求成功率优化篇》

3、旧方案存在的技术痛点

爱奇艺号是我们内容生态的重要组成，作为前台系统，对用户体验有较高要求，直接影响着创作者的创作热情。

目前，爱奇艺号多个业务场景中用到了WebSocket实时推送技术，包括：

1）用户评论：实时的将评论消息推送到浏览器；
2）实名认证：合同签署前需要对用户进行实名认证，用户扫描二维码后进入第三方的认证页面，认证完成后异步通知浏览器认证的状态；
3）活体识别：类似实名认证，当活体识别完成后，异步将结果通知浏览器。

在实际的业务开发中，我们发现，WebSocket实时推送技术在使用中存在一些问题。

这些问题是：

1）首先：WebSocket技术栈不统一，既有基于Netty实现的，也有基于Web容器实现的，给开发和维护带来困难；
2）其次：WebSocket实现分散在在各个工程中，与业务系统强耦合，如果有其他业务需要集成WebSocket，面临着重复开发的窘境，浪费成本、效率低下；
3）第三：WebSocket是有状态协议的，客户端连接服务器时只和集群中一个节点连接，数据传输过程中也只与这一节点通信。WebSocket集群需要解决会话共享的问题。如果只采用单节点部署，虽然可以避免这一问题，但无法水平扩展支撑更高负载，有单点的风险；
4）最后：缺乏监控与报警，虽然可以通过Linux的Socket连接数大致评估WebSocket长连接数，但数字并不准确，也无法得知用户数等具有业务含义的指标数据；无法与现有的微服务监控整合，实现统一监控和报警。

PS：限于篇幅本文不详细介绍WebSocket技术本身，有兴趣可以详读《 WebSocket从入门到精通，半小时就够！》。

4、新方案的技术目标

如上节所示，为了解决旧方案中存在的问题，我们需要实现统一的WebSocket长连接实时推送网关。

这套新的网关需要具备如下特点：

1）集中实现长连接管理和推送能力：统一技术栈，将长连接作为基础能力沉淀，便于功能迭代和升级维护；
2）与业务解耦：将业务逻辑与长连接通信分离，使业务系统不再关心通信细节，也避免了重复开发，浪费研发成本；
3）使用简单：提供HTTP推送通道，方便各种开发语言的接入。业务系统只需要简单的调用，就可以实现数据推送，提升研发效率；
4）分布式架构：实现多节点的集群，支持水平扩展应对业务增长带来的挑战；节点宕机不影响服务整体可用性，保证高可靠；
5）多端消息同步：允许用户使用多个浏览器或标签页同时登陆在线，保证消息同步发送；
6）多维度监控与报警：自定义监控指标与现有微服务监控系统打通，出现问题时可及时报警，保证服务的稳定性。

5、新方案的技术选型

在众多的WebSocket实现中，从性能、扩展性、社区支持等方面考虑，最终选择了Netty。Netty是一个高性能、事件驱动、异步非阻塞的网络通信框架，在许多知名的开源软件中被广泛使用。

PS：如果你对Netty知之甚少，可以详读以下两篇：

WebSocket是有状态的，无法像直接HTTP以集群方式实现负载均衡，长连接建立后即与服务端某个节点保持着会话，因此集群下想要得知会话属于哪个节点有点困难。

解决以上问题一般有两种技术方案：

1）一种是使用类似微服务的注册中心来维护全局的会话映射关系；
2）一种是使用事件广播由各节点自行判断是否持有会话，两种方案对比如下表所示。

WebSocket集群方案：

综合考虑实现成本与集群规模，选择了轻量级的事件广播方案。

实现广播可以选择基于RocketMQ的消息广播、基于Redis的Publish/Subscribe、基于ZooKeeper的通知等方案，其优缺点对比如下表所示。从吞吐量、实时性、持久化、实现难易等方面考虑，最终选择了RocketMQ。

广播的实现方案对比：

6、新方案的实现思路

6.1 系统架构

网关的整体架构如下图所示：

网关的整体流程如下：

1）客户端与网关任一节点握手建立起长连接，节点将其加入到内存维护的长连接队列。客户端定时向服务端发送心跳消息，如果超过设定的时间仍没有收到心跳，则认为客户端与服务端的长连接已断开，服务端会关闭连接，清理内存中的会话。

2）当业务系统需要向客户端推送数据时，通过网关提供的HTTP接口将数据发向网关。

3）网关在接收到推送请求后，将消息写入RocketMQ。

4）网关作为消费者，以广播模式消费消息，所有节点都会接收到消息。

5）节点接收到消息后判断推送的消息目标是否在自己内存中维护的长连接队列里，如果存在则通过长连接推送数据，否则直接忽略。

网关以多节点方式构成集群，每节点负责一部分长连接，可实现负载均衡，当面对海量连接时，也可以通过增加节点的方式分担压力，实现水平扩展。

同时，当节点出现宕机时，客户端会尝试重新与其他节点握手建立长连接，保证服务整体的可用性。

6.2 会话管理

WebSocket长连接建立起来后，会话维护在各节点的内存中。SessionManager组件负责管理会话，内部使用了哈希表维护了UID与UserSession的关系。

UserSession代表用户维度的会话，一个用户可能会同时建立多个长连接，因此UserSession内部同样使用了一个哈希表维护 Channel与ChannelSession的关系。

为了避免用户无限制的创建长连接，UserSession在内部的ChannelSession超过一定数量后，会将最早建立的ChannelSession关闭，减少服务器资源占用。SessionManager、UserSession、ChannelSession的关系如下图所示。

SessionManager组件：

6.3 监控与报警

为了了解集群建立了多少长连接、包含了多少用户，网关提供了基本的监控与报警能力。

网关接入了 Micrometer，将连接数与用户数作为自定义指标暴露，供 Prometheus进行采集，实现了与现有的微服务监控系统打通。

在 Grafana中方便地查看连接数、用户数、JVM、CPU、内存等指标数据，了解网关当前的服务能力与压力。报警规则也可以在Grafana中配置，当数据异常时触发奇信（内部报警平台）报警。

7、新方案的性能压测

压测准备：

1）压测选择两台配置为4核16G的虚拟机，分别作为服务器和客户端；
2）压测时选择为网关开放了20个端口，同时建立20个客户端；
3）每个客户端使用一个服务端端口建立起5万连接，可以同时创建百万个连接。

连接数（百万级）与内存使用情况如下图所示：

给百万个长连接同时发送一条消息，采用单线程发送，服务器发送完成的平均耗时在10s左右，如下图所示。

服务器推送耗时：

一般同一用户同时建立的长连接都在个位数。以10个长连接为例，在并发数600、持续时间120s条件下压测，推送接口的TPS大约在1600+，如下图所示。

长连接10、并发600、持续时间120s的压测数据：

当前的性能指标已满足我们的实际业务场景，可支持未来的业务增长。

8、新方案的实际应用案例

为了更生动的说明优化效果，文章最后，我们也以封面图添加滤镜效果为例，介绍一个爱奇艺号使用新WebSocket网关方案的案例。

爱奇艺号自媒体发表视频时，可选择为封面图添加滤镜效果，引导用户提供提供更优质的封面。

当用户选择一个封面图后，会提交异步的后台处理任务。当异步任务处理完成后，通过WebSocket将不同滤镜效果处理后的图片返回给浏览器，业务场景如下图所示。

从研发效率方面考虑，如果在业务系统中集成WebSocket，至少需要1-2天的开发时间。

如果直接使用新的WebSocket网关的推送能力，只需要简单的接口调用就实现了数据推送，开发时间降低到分钟级别，研发效率大大提高。

从运维成本方面考虑，业务系统不再含有与业务逻辑无关的通信细节，代码的可维护性更强，系统架构变得更加简单，运维成本大大降低。

9、写在最后

WebSocket是目前实现服务端推送的主流技术，恰当使用能够有效提供系统响应能力，提升用户体验。通过WebSocket长连接网关可以快速为系统增加数据推送能力，有效减少运维成本，提高开发效率。

长连接网关的价值在于：

1）它封装了WebSocket通信细节，与业务系统解耦，使得长连接网关与业务系统可独立优化迭代，避免重复开发，便于开发与维护；
2）网关提供了简单易用的HTTP推送通道，支持多种开发语言接入，便于系统集成和使用；
3）网关采用了分布式架构，可以实现服务的水平扩容、负载均衡与高可用；
4）网关集成了监控与报警，当系统异常时能及时预警，保证服务的健康和稳定。

目前，新的WebSocket长连接实时网关已在爱奇艺号图片滤镜结果通知、MCN电子签章等多个业务场景中得到应用。

未来还有许多方面需要探索，例如消息的重发与ACK、WebSocket二进制数据的支持、多租户的支持等。

附录：更多相关技术资料

[1] 有关WEB端即时通讯开发：

《新手入门贴：史上最全Web端即时通讯技术原理详解》

《 Web端即时通讯技术盘点：短轮询、Comet、Websocket、SSE》

《 SSE技术详解：一种全新的HTML5服务器推送事件技术》

《 Comet技术详解：基于HTTP长连接的Web端实时通信技术》

《新手快速入门：WebSocket简明教程》

《 WebSocket详解（一）：初步认识WebSocket技术》

《 WebSocket详解（二）：技术原理、代码演示和应用案例》

《 WebSocket详解（三）：深入WebSocket通信协议细节》

《 WebSocket详解（四）：刨根问底HTTP与WebSocket的关系(上篇)》

《 WebSocket详解（五）：刨根问底HTTP与WebSocket的关系(下篇)》

《 WebSocket详解（六）：刨根问底WebSocket与Socket的关系》

《 socket.io实现消息推送的一点实践及思路》

《 LinkedIn的Web端即时通讯实践：实现单机几十万条长连接》

《 Web端即时通讯技术的发展与WebSocket、Socket.io的技术实践》

《 Web端即时通讯安全：跨站点WebSocket劫持漏洞详解(含示例代码)》

《开源框架Pomelo实践：搭建Web端高性能分布式IM聊天服务器》

《使用WebSocket和SSE技术实现Web端消息推送》

《详解Web端通信方式的演进：从Ajax、JSONP 到 SSE、Websocket》

《 MobileIMSDK-Web的网络层框架为何使用的是Socket.io而不是Netty？》

《理论联系实际：从零理解WebSocket的通信原理、协议格式、安全性》

《微信小程序中如何使用WebSocket实现长连接(含完整源码)》

《八问WebSocket协议：为你快速解答WebSocket热门疑问》

《 Web端即时通讯实践干货：如何让你的WebSocket断网重连更快速？》

《 WebSocket从入门到精通，半小时就够！》

《 WebSocket硬核入门：200行代码，教你徒手撸一个WebSocket服务器》

>> 更多同类文章 ……

[2] 有关推送技术的文章：

《一个基于MQTT通信协议的完整Android推送Demo》

《求教android消息推送：GCM、XMPP、MQTT三种方案的优劣》

《移动端实时消息推送技术浅析》

《绝对干货：基于Netty实现海量接入的推送服务技术要点》

《极光推送系统大规模高并发架构的技术实践分享》

《魅族2500万长连接的实时消息推送架构的技术实践分享》

《专访魅族架构师：海量长连接的实时消息推送系统的心得体会》

《基于WebSocket实现Hybrid移动应用的消息推送实践(含代码示例)》

《一个基于长连接的安全可扩展的订阅/推送服务实现思路》

《实践分享：如何构建一套高可用的移动端消息推送系统？》

《 Go语言构建千万级在线的高并发消息推送系统实践(来自360公司)》

《腾讯信鸽技术分享：百亿级实时消息推送的实战经验》

《百万在线的美拍直播弹幕系统的实时推送技术实践之路》

《京东京麦商家开放平台的消息推送架构演进之路》

《技术干货：从零开始，教你设计一个百万级的消息推送系统》

《长连接网关技术专题(四)：爱奇艺WebSocket实时推送网关技术实践》

>> 更多同类文章 ……

本文已同步发布于“即时通讯技术圈”公众号。

▲ 本文在公众号上的链接是：点此进入。同步发布链接是： http://www.52im.net/thread-3539-1-1.html

Jack Jiang 2021-05-17 23:12 发表评论

千人万面奇妙自见：爱奇艺短视频推荐技术中多兴趣召回技术的演变

Fri, 23 Apr 2021 17:28:46 CST

导语

推荐系统的本质是信息过滤，多个信息漏斗将用户最感兴趣的内容逐步呈现在用户面前，如图1所示（《爱奇艺短视频推荐之粗排模型优化历程》）。召回阶段作为首个漏斗从多个维度将海量视频中用户可能感兴趣的内容滤出交给后续排序技术处理，它直接决定着后续推荐结果的效果上限。本文主要介绍爱奇艺随刻推荐团队多兴趣召回技术的发展历程。相比于其他召回技术，多兴趣召回技术能够同时挖掘出用户的多个潜在兴趣，在个性化推荐系统中突破传统的“千人千面”而达到“千人万面”效果。

图1 视频推荐系统主要流程[1]

01技术背景：如何召回“好苗子”，打破信息茧房

优秀的视频推荐系统可以精准地将视频分发给兴趣相匹配的用户，这个过程可以类比为优秀运动员经过层层选拔最终在世界大赛成功登顶，而召回阶段则相当于运动员年少时期的初次面对的市队选拔。

优秀的国家队教练固然业务水平精湛，但若没有天赋迥异的好苗子，也难以培养出世界级冠军选手；排序技术固然能够通过大量特征和精巧网络将效果提升，但若召回的所有视频本身质量不佳，那排序技术效果的上限将会提前锁死。因此，国家队教练需要多个省市的运动人才作为选拔来源，排序技术需要多个召回源作为待排序内容。

谈到召回技术，熟悉推荐的同学将举出诸多策略与算法，例如策略包括考虑内容关联的频繁项集挖掘Apriori等、考虑用户与内容相关性的召回itemCF等、基于协同过滤的召回SVD等；算法包括将内容变为embedding后再进行近邻检索的item2vec和node2vec、应用内容理解的CDML召回以及近年来兴起的GNN召回等。

图2 多兴趣召回主要流程[2]

如图2所示，多兴趣召回技术类似其他召回技术都依赖着用户过往的历史行为，但不同点在于多兴趣召回技术可以学习到用户的多个兴趣表示，将个性化推荐的“千人千面”升级为“千人万面”，每一个兴趣表示都能根据最近邻搜索得到相应的视频成为召回源。一方面，多兴趣召回技术符合多数用户拥有不同志趣和爱好的现实情况，能够让推荐结果精准且丰富，能够防止内容同质化带来观感疲劳；另一方面，除了挖掘用户的已有兴趣，多兴趣召回技术不断挖掘出用户自己从未发现的潜在新兴趣，防止传统推荐算法造成的“信息茧房”现象，让爱奇艺线上海量的文化资源呈现给用户。

同时，由于爱奇艺旗下丰富的产品矩阵，往往一个用户会同时使用包括爱奇艺基线、随刻、奇异果等多种产品。在多端用户行为混合训练的情况下，往往能够抽取出用户在不同端的不同兴趣、不同端用户的共同兴趣。这些兴趣往往能够帮助用户找到自己喜爱的社区与圈子，完成产品间的渗透打通和爱奇艺产品矩阵的复合生态建设。爱奇艺短视频推荐现在使用到的多兴趣召回技术有聚类多兴趣召回、MOE多兴趣召回、单激活多兴趣召回。本文将依次进行介绍。

02聚类多兴趣召回

聚类多兴趣召回的主要优点在于不用训练复杂的神经网络，只需利用线上其他深度学习的embedding即可形成多个兴趣向量（例如较为成熟的node2vec，item2vec等video embedding空间），时间和空间代价都较小。主要理论依据为KDD2020提出的兴趣聚类方法PinnerSage[3]。（是不是和PinSage名字很像，但它与图神经网络没有太大关系）。

PinnerSage聚类多兴趣召回是传统ii召回基础上结合聚类方法的新型策略。传统的ii召回中往往有两种做法：1，选择用户短期历史行为的每个视频，进行多次ANN查找选出近邻视频，这样的做法不仅时间成本高而且推出视频同质化严重。2，将用户短期历史行为的所有视频embedding进行pooling形成代表用户的user embedding，再进行ANN近邻查找，这样的方式能一定程度的融合信息减少时间空间代价，但很容易造成信息损失， pooling出的embedding如图3所示很可能差了十万八千里。

图3

PinnerSage则取两者之长，对用户历史行为中的视频进行聚类分组，pooling形成多个兴趣向量。聚类既避免了多次ANN带来的压力，也能一定程度上避免信息损失。PinnerSage 聚类多兴趣召回分为两步走：

a. 聚类过程。如图4所示，对用户观看过的所有视频进行聚类操作，Pinnersage聚类采用了hierarchical clustering聚类方法，并不需要像K-Means设置初始类别数，而是首先将每一个视频均看作一类，接下来每两类开始合并，若合并后组内variance增加最少则可以将两类合并为一类，直到variance超过阈值即停止。

图4

b. 取出embedding过程。PinnerSage依然不对类内视频embedding 取平均，而是选择类内的一个视频embedding作为类（兴趣簇）的代表，该视频embedding需满足与类内所有视频embedding距离之和最小。再利用这些代表用户兴趣的embedding们进行ANN即可。

聚类多兴趣召回通过简单的策略便形成了用户多个兴趣，时间代价较少。但由于依赖其他算法形成的embedding空间，学习到的多个兴趣embedding很容易有偏，推出内容趋于高热难以满足个性化。因此，团队继续向深度学习领域的多兴趣网络进发。

03MOE多兴趣召回

双塔模型是业界比较主流的召回模型，但是双塔模型在实际场景中效果有限。因此团队将双塔中的用户侧的塔结构进行修改，引入类似于MOE[4]的结构，提取多个向量表示用户潜在的兴趣，从而获得了极大提升。其中MOE是多目标学习中使用广泛的经典结构，根据数据进行分离训练多个专家模型，我们最终将多个专家模型的输出作为用户兴趣向量，通过与视频侧提取的向量分别计算内积得到最相似的一个用户向量参与损失的计算。

图5

MOE多塔结构如图5所示，左边为用户侧MOE多塔部分，右边为视频侧单塔部分。模型的实现细节包括：

a. 用户侧的输入主要是用户的偏好序列，包括用户偏好的视频id序列、上传者id序列与内容标签(tag)序列，序列特征经过embedding处理与average pooling操作后得到不同的向量，拼接之后组成MOE多塔的输入，经过MOE多塔计算后得到多个向量表示用户潜在的多个兴趣。

b. 视频侧为单塔结构，输入为用户交互过的视频id、上传者id与内容标签(tag)特征，经过embedding提取和拼接之后使用单塔结构提取信息。

c. 在loss计算上，由于召回是从千万级的视频库中寻找出用户可能感兴趣的几百条视频，因此实际样本中负样本空间十分巨大。为了增加模型对负样本的筛选能力和提升模型负采样的效率，我们在模型中使用batch内负采样，将batch内其他样本作为当前样本的负样本，同时使用focal loss损失函数来提升模型对难样本的识别能力。

经过修改之后的MOE多塔模型上线之后，单召回源的点击率和人均观看时长得到极大提升（全端CTR提升0.64%，召回源推出视频CTR比全端高出28%，展均播放时长比全端高出45%）。

经过修改之后的MOE多塔模型上线之后，单召回源的点击率和人均观看时长得到极大提升。但是MOE多塔共享底层的输入，仅仅使用简单的DNN网络提取不同的向量，导致多个塔之间的区分度比较低，多向量中冗余较多难以优化；此外用户序列特征中实际包含的位置信息对用户比较重要，当前模型难以利用，因此我们希望通过其他的网络来加以利用。

04单激活多兴趣召回

单激活多兴趣召回从19年开始便被工业界使用，其中最绕不开的是阿里提出的MIND[3]，其利用胶囊网络对用户序列进行动态路由收集多兴趣的方法在测试集上取得爆炸效果，激起了整个工业界对多兴趣网络的探索热情。随刻推荐团队也进行了探索。

4.1 单激活多兴趣召回初版

基于MIND等网络的启发，团队进行了单激活多兴趣网络的初版探索，网络结构如图5所示。在MIND网络中，采用了胶囊网络来抓取用户的兴趣，胶囊网络可以很好地同时捕捉观看的序列顺序信息和视频间的相关性，但由于结构较为复杂计算开销较大，且观看顺序仅单个维度即可表示不需要网络对位置信息太过敏感，因此团队选择transformer结构进行代替以保证训练速度。

图6

大致流程为：

a. 截取用户观看视频id序列{V1,…VN}作为sample，第N+1个视频作为target输入网络，经过video embedding层后形成embedding序列E={E1,E2,..EN}。

b. E经过transformer构造的兴趣抽取层得到多个兴趣向量M，取|Mi|最大的兴趣向量与target视频的embedding进行sampled softmax loss负采样，因此每次训练实际上只激活一个通道的兴趣向量。

c. 模型训练好后在推理阶段，取出用户所有兴趣向量，逐个进行ANN检索得到召回结果。

初版虽然结构简单，但上线后效果较好，极大提升消费指标、视频覆盖度和多样性。然而初版也存在着不同兴趣向量召回结果重复度较高、特征较少、即时性差等问题，因此也产生了多个版本的演变。

4.2disagreement-regularzation多兴趣召回

4.2中兴趣向量间无任何约束，因此容易出现兴趣向量过于相似的问题，因此在损失函数上需要施加正则项。鉴于初版多兴趣召回主要部分为transformer，团队在不改变网络结构的情况下使用三种正则函数进行探索[4]。

图7

如图7所示，分别对学习到的视频embedding(公式1)，Attention(公式2)，兴趣向量（公式3）进行正则化约束。在实际生产环境中发现，直接对兴趣向量进行正则化约束能达到最优效果。

4.3 容量动态化多兴趣召回

不同用户往往呈现不同的兴趣发散性，因此兴趣向量数应该是一个弹性指标而非超参数，在4.1与4.2的基础上，如图8所示在网络结构中引入兴趣激活记录表。

图8

训练过程中每当用户有任何兴趣向量被激活时，记录表均会记录这次激活。推理阶段，回溯激活表情况，将用户未激活或激活较少的兴趣向量剔除，以达到兴趣数动态化的目的，从而匹配不同用户兴趣发散性存在差异的现实情况。

4.4 多模态特征多兴趣召回

4.1-4.3中，多兴趣召回仅使用到视频id特征，学习效果依然有限，因此在后续版本的发展中，将上传者和内容标签(tag)融入训练成为主要方向。如图9所示，为网络主要结构。

Transformer部分与4.1-4.3中大致相同，不同点在于训练样本加入上传者和内容标签(tag)特征后经过embedding和pooling部分再进入transformer中。值得注意的有两点：

loss部分依然只对视频id的embedding进行负采样（与MIND等结构不同），这样的目的是让视频id的全部embedding可以进入负采样中，而不用折中使用batch内负采样，能够让最终推理阶段主要使用video id embedding更加精准（推理阶段ANN部分不会使用tag与uploader）。一个视频往往有多个内容标签(tag)，因此在对内容标签(tag)做embedding时需要对所有内容标签(tag)做embedding操作后进行一次pooling。

图9

4.5小结

如4.1-4.4所示，单激活多兴趣网络进行了多次演变过程，一次次改进后的应用带来了非常显著的效果，全端CTR显著提升2%，全端时长提升1.5%，人均播放提升1.5%；特别是在推出视频的多样性上，直接提升4%以上。

同时作为一个老少皆宜的内容平台，在爱奇艺一直存在着以家庭为单位，不同年龄段用户使用同一账号的情况，因此同一账号下的历史行为往往来自各个年龄阶段，用户历史行为的复杂性给推荐带来了难题。而单激活多兴趣网络的兴趣向量在学习过程的采样中具随机性、在数学呈现上具正交性，这就使得兴趣向量的搜索范围能够召回不同年龄段所喜爱的海量视频。

单激活多兴趣网络现在也是学术热点之一，希望能够有更多的研究者提出新的idea让推荐技术继续大放异彩。

05总结与展望

本文已经大致展现了爱奇艺短视频推荐召回技术中多兴趣召回的发展情况。多兴趣召回最大的亮点，在于可以抽取一个用户的多种兴趣，让曾经“千人千面”的画像迈入“千人万面”的高维空间，让推荐结果同时提升精准度和丰富度，同时也有兴趣试探，避免用户走入信息茧房。同时该技术也在爱奇艺产品矩阵复合生态建设与用户历史行为复杂性问题解决方案的前路上一直探索。

本文也认为多兴趣召回依然有可以优化的方向：

在行为序列的选取上，大部分的多兴趣策略与网络依然只考虑到用户的观看历史，如果能够运用事件知识图谱，将用户在平台上的搜索、订阅等行为一起纳入训练数据中，应该可以抓取用户更多的兴趣与倾向。在负反馈信息的处理上，多兴趣召回尚无应对之策。视频中的许多点踩、消极评论、不喜欢、取消关注等行为尚且未融入到多兴趣召回中，这些信息对指导兴趣网络的也至关重要，后期该方向将成为重点工作。在用户的静态信息与偏好特征的整合上，亦有很大的应用空间。这部分特征的组合能够很好地和排序目标对齐，提升召回源质量和排序效果上限。

参考文献

[1] 2021-2-26期，如何提升链路目标一致性？爱奇艺短视频推荐之粗排模型优化历程

[2] AdityaPal, et al. PinnerSage: Multi-Modal User Embedding Framework for Recommendations at Pinterest. KDD 2020

[3] Jiaqi Ma, et al. Modeling Task Relationships in Multi-task Learning with Multi-gate Mixture-of-Experts. KDD 2018

[4] Yukuo Cen, et al. Controllable Multi-Interest Framework for Recommendation.KDD 2020.

[5] Chao Li, et al.Multi-Interest Network with Dynamic Routing for Recommendation at Tmall. CIKM 2019.

[6] Jian Li, et al. Multi-Head Attention with Disagreement Regularization. EMNLP 2018

OCR技术在爱奇艺的应用实践及演进

Tue, 13 Apr 2021 09:59:56 CST

随着人工智能的热度上升，图像识别这一细分领域也渐渐被人们所关注。在很多公司的业务中，有很多需要对图片进行识别的需求。为了帮助业务实现对这些图片、文档的识别和结构化，业界进行了一系列的实践和探索，最终确定了一些可行的方法，总结了在实践过程中可能遇到的问题和难点。

为了更好地了解OCR技术在爱奇艺的应用实践，最近，InfoQ“大咖说”栏目邀请爱奇艺智能平台部助理研究员——Harlon 进行了一场直播分享，结合目前的业务需求，为我们陈述了爱奇艺在探索OCR技术发展过程中遇到的痛点和难点，以及识别技术的一些细节，以下是采访实录。

嘉宾：Harlon

InfoQ：您好，非常开心有机会采访您，您方便简单介绍下过去几年 OCR 技术的整体发展吗？大致可以从哪几个维度来看？

Harlon：随着互联网的发展和智能设备的普及，图像以及视频的产生速度大大加快，图像文字中包含的丰富的语义信息，也在人机交互中扮演着重要角色，从图像中提取文字的技术，也就是 OCR 技术得到了越来越多的关注。随着深度学习的发展，OCR 技术从基于传统的图像处理和机器学习转到了以深度学习为主，其主要包含如下两个步骤：

一是文字检测，用于检测图像中的文字位置，一般以矩形或四边形来表示，区别于常规的物体检测，文本行具有长短不一、长宽比例范围大，而且方向性较强的特点，也较易受到复杂背景的影响；

二是文字识别，输入是文本检测得到的文本行图像，输出为图像对应的文本信息。传统的文字识别方法可以分为字符分割和单字符识别两个步骤，现在的文本识别算法大都是基于序列到序列的网络，一个网络里面可以同时进行分割和识别，这样做的好处是大大减少了数据标注量。另外，由于同时训练分割和识别算法，算法性能也得到了大幅提升，我们可以从以下几个方面来看 OCR 技术的发展：

首先是文字检测部分，借鉴物体检测技术的发展，文字检测技术也从检测单行、较规则的文字发展到了检测任意方向文本，典型算法包括：CTPN、EAST、PMTD、DB 等；文字检测的方法主要分为基于检测框和基于 Mask 两个大类，基于检测框的文本检测，其思路是先利用若干 Anchor 产生大量候选文本框，再经过 NMS 得到最终结果；基于 Mask 的文本检测，其思路是通过分割网络进行像素级别的语义分割，再通过后处理得到文本框，由于后处理比较复杂，这个步骤会直接影响基于 Mask 文本检测算法的性能。

其次是文字识别，主要有两类方法：一种是基于 CTC 的 CRNN；另一种是基于注意力机制的编码器 - 解码器结构，两类方法的流程非常相似，主要包括图像预处理、特征提取、序列建模、字符预测四个流程。

具体来说，CRNN 采用的是 CNN 加 RNN 的结构来提取基本特征，损失函数采用 CTC loss，CTC 最早应用在语音识别中，能够在不分割输入数据的条件下解决序列的预测问题，也就是输入一串语音信号，不需要做分割就可以直接输出语音信号对应的文本，CTC 最大的特点是输入和输出都是一个序列，移植到 OCR 领域以后，基于 CTC 的 CRNN 算法也取得了很好的效果。至于注意力机制模型，主要是编码器 - 解码器结构，文字识别算法解决的核心问题是将长度不匹配的图像特征和文本序列对应起来，编码器 - 解码器这种结构非常适用于解决这个问题，加入 Attention 模块以后，可以自动寻找到需要预测的文本区域，将注意力集中在图像中需要识别的字符附近，显著提升模型准确性。

然后是端到端 OCR，上面讲到的文本检测和文本识别都是串行流程，也就是文本检测完毕以后再进行文本识别。不同于这两个步骤分开进行的模式，端到端 OCR 是将文本检测和文本识别联合起来训练，共享特征提取网络，然后在训练阶段输入训练图像，以及对应的文本框信息和文本内容，损失函数定义为文本检测和文本识别误差的加权和，通过这种方式希望能达到联合优化的目的，预测阶段相当于少了一次特征提取的操作，预测阶段的资源开销也会更少。从实际效果来看，由于两个任务也就是检测和识别的特性不同，整个端到端算法的训练收敛难度会比较大。

最后就是基于 OCR 的信息提取技术，传统的 OCR 技术只解决了从图像中提取文字的需求，但是类似票据识别等场景，除了识别文字外，也需要识别文字之间的关系，判断哪些文字属于预打印的内容，哪些文字属于填写的内容，只有掌握了文字之间的对应关系，后续的业务才能顺利开展，这种基于 OCR 的信息提取技术对 OCR 的业务应用起到了很大的推动作用，近年来的研究也是比较多的。

InfoQ：您方便聊聊目前 OCR 技术在工业界的主流应用有哪些？技术层面还存在哪些瓶颈？

Harlon：OCR 在工业界一直有很多应用场景，最著名的例子就是 LeCun 为美国邮政系统设计的支票号码识别算法，这个数据集后面演化成了 MNIST 公开数据集，可以说这是所有深度学习人员接触到的最早示例，基本上所有框架都会拿该数据集作为最初的学习。

早期，由于算法性能受限，OCR 主要是应用在特定场景下的文字识别，比如车牌识别、扫描文档识别以及银行卡卡号识别。整体来说场景是可控的，输入的图像质量相对来说也比较好。随着硬件条件的提升以及算法的发展，现在的 OCR 技术越来越多被应用于像网络图片文字识别、自然场景文字识别等通用领域。

现在，OCR 技术在业界有了很多应用，包括在线视频、在线教育以及智能交通分析等多个领域，只不过应用点可能并不相同，在线教育最核心的应用点是拍照搜题，拍照搜题的核心是需要 OCR 识别用户算法的题目；对于在线视频，因为影视剧的视频较多，需要识别视频里面的文字信息，提供给业务做应用。现在的 OCR 技术主要是根据具体任务设计的专用算法，对不同语种或者不同类型的文字识别效果差异很大，所以提升 OCR 技术的通用能力以及泛化能力是一个需要探索的问题。另外，像小样本或者无监督条件下的 OCR 算法现在的研究也比较少。最后，利用 NLP 以及单字符标注信息提升 OCR 算法的整体性能也是一个没有完全解决的问题。

InfoQ：过去一年，OCR 领域也出现了不少开源项目，对开发者选型而言，您认为可以从哪几个层面考虑？

Harlon：事实上，深度学习本身就有很多框架可以选择，比如 PyTorch、Tensorflow 还有最近开源的 Paddle OCR。在 OCR 领域，同样有很多开源项目可以选择。对开发者而言，需要从自身需求出发进行选型，如果是科研目的，那么 PyTorch、Tensorflow 更加适合，二者提供了众多基础模块，还有很多项目及实践经验可以参考，便于大家复现论文，实践新的思路；如果是其他目的，我觉得可以考虑 Paddle OCR 框架，因为其提供了一整套 OCR 工具库，比如仿真数据生成、模型训练、测试以及模型调优等，包括最近又开源了一些 OCR 标注工具，提供了部署服务相关的接口，Paddle OCR 提供了很多经典算法的开源模型，工程人员可以快速实验各种模型，并用自己的数据微调模型，非常利于模型快速选型。

另外，我觉得 Paddle OCR 框架还有两个比较好的地方：一是该项目由百度开源，对中国的开发人员来说，直接用中文沟通更加便利；二是 Paddle OCR 有专门的人员负责更新文档和代码，用微信群进行沟通，我觉得对于专业的 OCR 人员来说，这是一个不错的选择。

最后，不同的 OCR 模型有不同的特点，就选型而言，开发者需要明确分析自己的任务特点，只有搞清楚业务特点，才能找到最合适的算法。

InfoQ：Paddle OCR 也是一个非常轻量级的框架，实现这样一个框架的难度大概是什么？

Harlon：从算法角度来说，如果要实现一个轻量级的框架有很多手段，比如选择一些轻量化的模型，另外可能针对模型里面的具体层调小参数或者进行量化，这样或许可以很轻易的得到一个轻量化的模型，但是怎么让轻量化的模型达到比较好的效果是一条比较漫长的道路。

InfoQ：您方便介绍下爱奇艺内部主要有哪些场景应用到了 OCR 技术？用来解决哪些问题？

Harlon：OCR 技术在爱奇艺内部得到了非常广泛的应用，对爱奇艺来说，影视剧是核心资产，但视频属于非结构化数据，不利于应用，如何更好地利用视频？为此，我们上线了智能台词分析功能，该功能以 OCR 为基础，可以实时提取影视剧、综艺等节目中的台词信息。

智能台词分析用于提取影视剧视频中的台词信息。同时，会利用 NLP 算法处理识别出来的台词，将用户可能感兴趣的信息提取出来作为标签数据，这些标签数据可以和其他视频信息构成视频的原始数据，然后提供给搜索或者推荐业务使用。

与此同时，我们还在扩大台词智能分析的业务范围，比如提供曲目板识别，广告权益识别、片尾检测等功能。另外一个应用场景就是视频文本 OCR，主要用于识别视频中出现的英文、数字、繁体中文、简体中文等文本，算法可以很好的适配复杂背景，精准识别视频画面中出现的关键文字，为视频分析提供更多数据。

除了上述两大应用外，我们还有一些专用 OCR，用于识别身份证、银行卡以及新闻标题等，这些 OCR 构成了我们的基本算法，被广泛应用于各个业务，既能提高员工效率，也可以改善用户体验。

InfoQ：您方便聊聊爱奇艺是什么时候开始打造 OCR 技术体系的？到现在经过了哪些阶段，有哪些重要的时间节点？每个阶段主要用于解决哪些问题？

Harlon：事实上，OCR 算法一直是爱奇艺算法体系中的重要一环，主要经历了三个发展阶段：第一个阶段是基础阶段，主要完善 OCR 算法对基础业务的支持，比如图文分析、智能台词分析、新闻拆条等，这个阶段我们开发了多种 OCR 基础算法，提高编辑人员的效率。重要的时间点是 2017 年，这一年，我们结合爱奇艺自身影视剧库存量较大的特点推出了业内第一个台词搜剧功能，实现的主要功能是用户可输入感兴趣的台词信息搜索对应的视频点位，该功能的推出极大丰富了用户体验，同时让视频搜索更加便捷。

第二个阶段是发展阶段，主要优化算法速度。随着 OCR 业务的发展，我们整个后台需要处理的视频和图像数据量成倍增长，OCR 算法开始出现瓶颈，主要体现在随着数据量的增加，硬件资源消耗巨大，这个阶段基于成本等各方考量，我们使用了多种方法优化算法性能，包括替换轻量化网络、采用新的模型等，让算法运行速度更快，资源消耗量更少；工程层面，我们同样做了很多优化，包括优化算法的处理流程，合并冗余步骤，加入更多进程...... 通过一系列优化，智能台词分析的性能大大提升，40 分钟的影视剧视频只需要 5 分钟就可以完成台词识别，这个速度还是比较可观的，同时大大降低了对硬件的依赖程度。

最后一个阶段是优化阶段，我们从各方面优化算法的性能指标，并且扩大应用范围。横向来看，我们扩大业务的支持范围，挖掘更多业务的使用点，比如将智能台词分析服务从仅识别影视剧扩展到识别综艺节目等。从实践来看，这个阶段为业务方带来了更多便利。

纵向来看，随着场景的扩大以及业务的增长，算法需要更强的泛化能力，因为业务增长以后，算法看到的数据类型越来越多样，如果泛化性能不强，有可能就会出现很多 Bad Case。因此，我们后续开发了很多辅助算法，包括语种分类算法、竖向文字识别算法等，通过此丰富了整个 OCR 算法矩阵，并将相关算法集成到了爱奇艺的奇观中，可以解决用户不同层次获取信息的需求，欢迎大家体验。

InfoQ：在这个过程中，爱奇艺主要用到了哪些算法和模型？效果如何？

Harlon：我们会根据不同的应用场景使用不同的算法和模型，然后对模型结构进行优化和改进，文字检测算法包括 CTPN、EAST、PMTD 等，CTPN 的特点是只能检测水平文字，而且对长文本和短文本都有很好的检测效果，不容易发生长文本丢失的现象，特别适合于影视剧的台词检测，但是 CTPN 对单个台词的检测效果不太稳定，可能会存在漏检的情况。

PMTD 其实是一个基于 Mask RCNN 的文本检测方法，可以预测整个文本的 Mask，通过 Mask 推测包含文本的四边形区域，这样就可以兼容横向、纵向、倾斜文本的检测，适用范围较广，但是对密集倾斜文本会发生文本区域检测混乱的情况。

DB 是去年推出的算法，基于分割检测，它在论文中提出了一个叫做 DB 的模块，也就是可微分模块，通过该模块替代分割的后处理部分，而且可以设定自适应阈值来提升网络性能，因为其把繁琐的后处理直接用 DB 模块来替代，相当于网络直接可以运行，DB 算法在水平以及倾斜文本检测上都可以达到很好的性能。

接下来介绍文字识别部分，现在主流的方法都是基于序列到序列的，比如 CRNN，或者基于注意力机制的编码器 - 解码器网络，相比传统的单字符识别算法，这两种方法都是以文本行为单位进行训练，最大的特点就是不需要单字符的标注信息，可以大大提升标注效率，而且将字符识别与字符分割同时放在一个网络中训练，大大提升了算法性能。对于粘连情况比较严重的文本行，效果是非常好的。从实践来看，以上两种文本识别方法的效果是相当的，注意力机制模型的特点就是对英文、数字以及长文本的识别效果较好，CRNN 解码很快且对中文识别效果较好。

InfoQ：我们都知道，识别率是衡量 OCR 识别是否精准的重要条件，你们是如何提升识别率的？其中的难点是什么？目前的准确率是多少？

Harlon：首先介绍下 OCR 算法的整体评价指标：文字检测算法使用的评价指标类似于物体检测，根据 IOU 来判断检测框和标注框的重复程度得到召回率和准确率；文字识别算法使用的评价指标是整行识别率，也就是识别的文本串跟标注文本串完全一样才认为是正确的。

在算法研发的过程中，我们发现图像中的文本样式、字体、文本方向、语种、背景复杂多样，这些都给 OCR 技术带来了很大挑战。此外，不同场景的文本特点不同，如果为每个业务单独开发一套算法，重复的工作量也非常大。基于此，我们构建了 OCR 解决方案，根据不同的业务特点进行微调，我们也配套开发了 OCR 技术模块，比如文本仿真模块，训练、测试模块以及数据清洗模块。

针对不同的业务场景，我们会选择合适的算法。以智能台词分析为例，我们选择的是对中文识别效果较好的 CRNN 模型。在影视剧特别是综艺节目中，经常会出现不常见的字体及文字特效，比如《青春有你》、《热血新说唱》等节目会使用活泼且有个性的字体，我们开发了文本仿真引擎用以模拟各种文本的特效，包括台词常见的阴影、描边、发光体等效果，以及收集了 150 多种常用字体，用来生成各种样式的仿真台词，最终生成了千万级别的仿真数据用于强化模型的泛化能力。在下一阶段的训练中，我们又加入了一定量真实数据一起训练，这样得到的模型更加适用真实场景。最后，我们针对特殊情形做了很多优化，比如在双语电影的台词识别方面，由于英文台词的字符数量比中文台词多很多，如果强行使用一个识别模型的话，整个模型解码时对英文识别会出现预测长度偏小进而导致字符丢失的现象，针对这种情况，我们单独开发了语种检测算法，用于区分中文台词和英文台词，以及单独的英文识别算法，这样就可以保证整个台词识别算法的效果。

通过上述一系列优化，我们的台词智能分析服务在中文台词、英文台词上都得到了较优水平。同时，我们会根据算法的特点进行一些针对性优化，比如上述提到的 PMTD 算法，对比较密集的倾斜文本行检测效果不太好，通过实验发现这是由于生成的训练数据不准确导致的，因为倾斜的文本行虽然标注的时候是一个倾斜的四边形，但是最后训练的时候会转换成矩形，导致面积扩大，如果倾斜行文本行过密，矩形区域里面就会包含另外一个文本行，这样的训练效果是非常不好的，在这种情况下，我们通过限制倾斜文本行的长度以及对过长的倾斜文本行进行分段解决了这个问题，最后达到了比较好的效果。

InfoQ：接下来，爱奇艺还将做哪些事情提高 OCR 技术的整体效果？

Harlon：未来的规划主要包括几个方面：一是视频中的文本识别和跟踪，爱奇艺本身有大量的视频数据，这些数据具有数据量大、时序性强的特点，如何在保证算法实时性的同时利用这些特点优化 OCR 算法的性能是值得关注的。

二是结合 NLP 技术优化整个 OCR 算法的性能。图像中的大部分文字都有很强的语义信息，如何结合 NLP 优化 OCR 算法对易错样本的识别效果。

三是 OCR 算法移植到手机端。随着爱奇艺业务的增长，整个 OCR 算法需要处理的数据量越来越大，如果将 OCR 算法移植到手机端，能缓解整个后台服务的压力，同时可以为用户带来更好的体验。

QA 部分

端到端的 OCR 框架有哪些注意事项？有什么可以参考的吗？

答：端到端的 OCR 框架，可以同时完成文字检测和文字识别，需要注意：文字检测和文字识别属于两个问题，训练过程中，需要保证共享的特征同时适用于两个算法才行，但是同时训练这两个任务，会导致 loss 震荡，整个网络不收敛，因此一般的步骤是先训练一个任务，稳定以后再把另一个任务加进去；参考：FOTS。

对于添加了水印或印章的图片，是否有比较好的识别方式？

答：如果水印比较好去除，建议先去除水印，否则，可以生成一些带水印或印章的仿真样本，用于模型训练，能加强模型对这种图片的识别效果；

east 文本监测的优缺点有哪些？

答：优点：速度较快、支持任意方向文本检测；缺点：相比最新的一些方法，性能有差距，对倾斜文字的检测效果不太好

方便分享下模糊文本的识别吗？

答：造成模糊样本的原因有很多，比如本身的拍照环境较差导致样本模糊等，可以用算法生成一部分模糊样本，将其与清晰样本结合起来进行训练。需要注意的是模糊样本的模糊程度，如果过于模糊可能文本信息已经没有了，此时用来进行训练可能就是脏数据了，这种情况是需要避免的。另外，模糊样本和清晰样本的比例需要掌握好，如果模糊样本过多会影响模型对清晰样本的识别效果。

从 0 到 1 搭建 OCR 有哪些坑可以绕开？

答：1）字符集：确定任务需要的字符集，生成仿真样本时，查看字体是否包含所有需要的字符集，生成仿真样本后，对样本进行抽查；根据任务判断字符集中是否需要加入空格这个字符；2）标注数据：根据任务需要确定标注规则，比如：基于单词的检测方法，需要将空格两侧的单词分开标注；整行文字检测方法，可以将包含空格的整行文字一起标注；3）优化方法：多尝试优化方法，选择对当前任务最优的方法；4）标注样本数量：检测算法对样本的需求量较低，识别算法由于字符数较多，需要更多的样本；

嘉宾介绍：

Harlon，爱奇艺智能平台部助理研究员，来自爱奇艺智能平台部 AI 服务组，从事 OCR 算法、视频内容分析、智能审核等研发工作。

end

也许你还想看\

效能篇 | APP的自动化录制回放系统全云化处理新体验\

i技术会 | 如何用AI挖掘和生成视频广告点位\

扫一扫下方二维码，更多精彩内容陪伴你！

本文授权转载自《InfoQ》作者｜钰莹\

爱奇艺短视频分类技术解析

Wed, 12 Jun 2019 11:38:00 CST

简介

近年来，短视频领域一直广受关注，且发展迅速。每天有大量UGC短视频被生产、分发和消费，为生产系统带来了巨大的压力，其中的难点之一就是为每个短视频快速、准确地打上标签。为了解决人工编辑的时效和积压问题，自动化标签技术成为各大内容领域公司都非常关注的关键课题。短视频大规模层次分类作为内容理解技术的一个重要方向，为爱奇艺的短视频智能分发业务提供着强力支持，其输出被称为“类型标签”。

以下是我们对一条爱奇艺短视频的分类效果：

算法结果：游戏-题材-角色扮演，与人工结果一致。其实“漫威”、“蜘蛛侠”这类IP的作品既可能是“影视”也可能是“游戏”，或者其他周边，如果缺乏背景知识，人工也不容易做出准确的分类，但是模型由于见到了足够多的样本，反而比单个人工有更大概率做出正确判断，在一定程度上体现了集体智慧和算法的优势。

类型标签在爱奇艺内部有着广泛的应用。

在短视频生产领域，类型标签从视频的生成、准入、审核、标注等多个方面发挥着重要作用。

标签自动化：部分标签的准确率已经达到95%以上，这部分标签已经用算法结果替代人工标注，减少了大量标注人力，提高了视频生产效率；
频道自动化：目前的频道由上传者填写，上传者会投机取巧乱填频道导致频道混乱，影响用户的使用体验，使用类型标签替换频道，提升了频道的分类准确率。

由于准确率很高，短视频生产系统乐高已经部分将自动化标签代替人工标签，并推送到各个业务线，支持着大量业务的智能运营策略。

在个性化推荐领域，已使用算法生成的类型标签全面替代人工标注的频道，成为推荐系统最重要的基础数据之一，在以下的策略中发挥了重要作用。

多样性控制：使用标签完成多样性控制，减少相似内容对用户带来的疲劳，提升播放时长等关键业务指标和多样性等生态指标；
用户画像：基于标签完善用户的长期兴趣和短期兴趣，提升用户画像的完整性、准确性和可解释性；
召回：增强无用户行为的新视频的分发能力，提升用户兴趣探索阶段的泛化性，提升用户的负向兴趣过滤的泛化性，从而提升用户体验；
排序：基于画像的用户兴趣和视频类型标签作为模型的特征，增强排序模型的排序效果。

本文将详细介绍爱奇艺短视频大规模层次分类算法。

技术难点

分类体系复杂

短视频分类体系是一棵人工精心制定的层次结构，体系和规则都比较复杂：层级最少有3级，最多有5级，总计近800个有效类别，类别间有互斥和共同出现的需求。

需要文本、图像、生态信息等多模态特征综合判断

短视频具有标题、描述、封面图、视频、音频等媒体信息。同时，一个短视频也不一定是独立存在的，它可能来自一个影视、综艺片段，它的上传者可能是一个垂直领域的内容贡献者，所以，关联正片、视频来源、上传者等信息对分类也可能有帮助。

解决方案

短视频分类可以分为特征表示(Feature Representation) 和层次分类(Hierarchical Classification) 两个模块，前者基于多模态特征建模短视频的整体表达（在我们的模型中通过Feature Representation和Representation Fusion两个子网络级联建模完成），后者基于前者完成分类任务。我们模型的整体结构如下图：

下文将分别介绍这两个模块。

特征表示模块

短视频的特征种类和形态各异，只有正确使用这些信息才能提升模型效果的天花板，下文将介绍各种特征表示的建模方式以及融合方式。

文本表示

短视频一般都有一个代表其视频意义的简短标题和更为详细的描述信息，通过对这些人工抽象出的文本信息进行分类会比直接从视频学习出分类更容易。下文将首先介绍业界常见的文本表建模方式，然后分享在我们任务中采用的方案。

业界常见建模方式：

1.BOW

Bag-of-words model忽略掉文档的语法和语序等要素，将其仅仅看作是若干个词汇的集合，每个单词的出现都是独立的，由一组无序的单词(words)来表达。实际操作上可以直接使用线性分类（单层NN，下左图）或者嵌入到一个词向量空间中进行AVG等操作后再进行分类（CBOW，多层NN，下右图）。由于模型假设文档是一个词袋，忽略了出现的顺序和组合，所以在构建特征时，可以考虑将表示了词组的ngram和词共现的组合特征放入模型中，提高模型的效果。

优点：建模容易，性能好，在使用了大量人工构造的特征后也可以达到极佳的效果。

缺点：过渡依赖人工特征的构造，构造的人工特征可能因为过大，在模型训练上带来困难。

2.CNN

利用CNN对文本建模表示进行分类是源自图像领域CNN取得的巨大成功，但是在文本领域仅用CNN进行文本建模效果并不突出。CNN通过不同大小的filter对有序的词向量进行卷积操作，以期望模型能够从中学到不同大小的ngram信息，并且通过pooling操作（一般是max-pooling），找到最强的信号，作为该文本的表示。

优点：建模比较容易，性能不差。

缺点：模型效果上限较低，对长距离共现信息建模较差。

3.RNN

利用RNN（GRU/LSTM）进行文本建模，理论上具有最高的天花板，在实操上效果也介于CNN和精选了人工特征的BOW，以LSTM为例，其不仅对词序敏感，并且具有长短记忆功能，能够将短距离的ngram信息和长距离的共现信息学习到。

优点：模型效果上限高，效果较好。

缺点：建模和训练较难，运行时间慢，在大数据集训练实用性不高。

4.Attention

使用Attention可以对长距离的共现信息进行建模，并且能够识别整个序列中最为关注的部分，该技术可以和上述的CNN和RNN这种与序列有关的技术配合使用，能够取得更好的效果，下图是典型的基于点积的（多头）注意力机制。

优点：建模难度一般（Attention实现方式多种多样），几乎总是能够提升模型效果。

缺点：无明显缺点，可以和其他模型共用。

我们的建模方式：

权衡模型的执行效率和效果，最终类型标签采用的是BOW和CNN+Attention方式完成文本表示的建模。

1.CBOW与人工特征构造

前面已经提到BOW在使用了大量人工构造的特征后也可以达到极佳的效果，所以我们也尝试了很多人工/机器构造的特征：

(1) 字、词特征，用以提高模型的泛化能力

(2) Ngram特征，提供片段特征

(3) 词对特征，提供远距离组合特征

(4) 经过gbdt学习到的组合特征，更高维的组合特征

(5) 一些ID类的离散特征我们也一起和字和词组合到一起

2.带位置信息的CNN

普通的TextCNN使用的Max Pooling是全文进行，忽略了文本表达的顺序信息，我们将Max Pooling以一定步长进行，提取出每个位置上的文本表示。

3.Self-Attention

基于CNN提取出的带位置信息的文本表示，我们加入Attention结构，组合不同位置的文本表示，并且让模型识别应该关注哪个部分。

02 图像表示

短视频数据存在的文不对题、标题描述类型区分力弱的问题，这些问题都对模型的学习带来较大的困难。封面图作为从短视频中精选的一帧，能够在一定程度上代表短视频主题的意义，并且与文本具有互补性，如果能够从其中识别图像表征，补充到类型标签分类任务，应该能够提升模型的分类效果。

表达融合方式：

对图像进行表征，并融合到分类模型中，目前业界非常流行的做法是基于预训练的ImageNet模型在训练数据较少的目标任务上进行迁移学习，有3种方式：

1. 特征抽取

实现方式：把ImageNet预训练的模型作为特征抽取器，将模型的某一层或者某几层特征作为类型标签模型特征提取源。
优点：预训练模型容易获取，不需要训练模型，只需要进行特征抽取，上线速度快。
缺点：模型效果差，需要选择抽取那一层的输出作为抽取的特征，需要保留的特征如果很多的话，特征保存的开销会很大。

2. FineTune+特征抽取

实现方式：把ImageNet预训练的模型以类型标签为目标进行FineTune，然后将模型的某一层或者某几层特征作为类型标签模型特征提取源（因训练目标一致，一般选择最后一层即可达到较好的效果）。
优点：模型效果好，输出的特征维度低，容易储存。
缺点：FineTune耗时较大。

3. 模型融合

实现方式：把ImageNet预训练的模型嵌入到类型标签的模型当中，让图像的表示和其他特征的表示同时进行训练。
优点：效果最好，End2End完成最终的上线模型。
缺点：模型训练调参困难，并且耗时巨大。

基于上述3种方式的介绍和分析，我们尝试了1、2两种方式，最终采纳了第2种方式。

模型选择：

图像模型的好坏直接影响到最终提取的图像特征的效果，需要选择一个效果与效率都很高的模型来完成我们的任务，在项目中我们尝试了ResNet50和Xception两个模型，并且最终选择后者，后者在我们的场景中训练、预测耗时接近，Accuracy高3%。

特征融合：

通过上述不同的特征表达方式，每一种特征都被映射为了一个向量，一种好的特征融合方式可以提升表示的整体效果，为此我们尝试了3种方案，并最终采用了LMF模型。

1.Concatenate

顾名思义，这种方式就是将每种表达连接到一起后连接全连接学习整体的表达，这种方式简单，并且能够提供一个不错的基线。

2.CentralNet[6]

该模型借助多任务对每个模态的表达进行约束，以期Fusion后的表达能够获取更好的泛化能力，相对于Concatenate有1%的效果提升，模型示例如下：

3.LMF[7]

LMF(Low-rank Multimodal Fusion)通过将N个模态的外积运算近似等价为内积和按位相乘的运算实现特征的全组合，相对于CentralNet有0.2%的效果提升，模型示例如下：

层次分类模块

下文将首先介绍业界常见层次分类建模方式，然后分享在我们任务中采用的方案。

业界常见建模方式：

对于层次分类，业界常见的有4大类方法。

1.弹珠机模型

分类树的每个非叶子节点都有一个独立的模型，利用分类信息做数据的划分。优点是扩展性好，但是由于仅从样本维度使用层次信息，未能共享特征表达，而且模型数量和层次结构体系对应，在我们的应用场景中，需要数量巨大的独立模型，代表论文[1]。以下图为例，预测过程为：

(1) 模型1预测为影视

(2) 模型2预测为电视剧

(3) 模型3、模型4分别预测为古装和解读

2.级联策略

低层级模型的输出作为高层级模型的特征，仅从分类结果维度使用层次信息，信息利用率低，实验效果不佳。代表论文[2],[3]。

3.正则化约束

通过正则化约束，通过让有上下级关系的分类模型的参数具有符合该正则化约束的相似性，正则化方式通过人工先验知识确定，无法让模型学习，正则化罚项超参也需要人工调整，实验代价大，效果不佳。代表论文[4]。

4.多任务

将各层级分类的多个任务合并，以共享模型参数方式学习模型的层次结构，共享样本信息和模型参数，使用合并的Loss驱动模型调整参数，完成层次结构信息的使用。代表论文[5]。

我们的解决方案：DHMCN

(Dense Hierarchical Multilabel Classification Network)

结合实际应用场景，经过多次迭代升级，形成了最终的解决方案。

V1：上文提到的多任务模型（HMC）：其核心思想可以简化为采用多任务来分别学习一级、叶子的global和local表示。

V2：借鉴DenseNet的思想，尝试让层级间的连接更加的丰富，让模型更加容易收敛，而不会陷入局部最优解。下图是一个可视化的解释：

下图为我们构建的基于多任务的层次分类网络：

其中：

• X是短视频的表达，具体构建方式前文已经介绍

• A_G¹和A_G²分别表示Global的1级和末级分类的隐层表达，P_G表示Global（所有）的分类概率

• A_L¹和A_L²分别表示Local的1级和末级的分类的隐层表达，P_L¹和P_L²分别表示1级和末级分类的概率

• 训练的Loss由P_G，P_L¹和P_L²三者与GroundTruth计算交叉熵得出

• P_F表示合并了Local和Global的最终分类概率

V3：借鉴级联策略，用一级表示形成权重去指导叶子节点的分类，这样叶子节点就只用专注在某一级的内部去分类，相当于把其他无关的分类全mask掉。

这是一个端到端的自动学习，我们通过可视化权重，发现学习到的Reweight Vector符合我们的预期：模型在预测出一级分类为19号分类时发现应该提升该分类对应的叶子分类的置信度（如下图）。

后续工作

1. 对于长度较短的短视频，将引入视频和音频特征，保证线上服务性能的情况下提升分类效果

2. 对于样本较少的分类，将引入用户搜索、推荐Session行为进行训练获取初始化的短视频表达，然后基于该表达继续训练

3. 更加充分的使用视频之间的关系进行训练（同一专辑、剧集、综艺、UP主等）

参考文献

[1] S. Dumais and H. Chen. Hierarchical classification of web content. In ACM SIGIR, 2000.

[2] P.N. Bennett and N. Nguyen. Refined experts: improving classification in large taxonomies. In SIGIR, 2009.

[3] Tengke Xiong and Putra Manggala. Hierarchical Classification with Hierarchical Attention Networks. In KDD, 2018.

[4] Siddharth Gopal and Yiming Yang. 2013. Recursive regularization for large-scale classification with hierarchical and graphical dependencies. In KDD. 257–265.

[5] J. Wehrmann, R. Cerri, and R. C. Barros. Hierarchical multi-label classification networks. Proceedings of the 35th International Conference on Machine Learning (ICML), pages 5075–5084, 2018.

[6] V. Vielzeuf, A. Lechervy, S. Pateux, and F. Jurie. Centralnet: a multilayer approach for multimodal fusion. In ECCV Workshop, 2018.

[7] Zhun Liu, Ying Shen, Varun Bharadhwaj Lakshminarasimhan, Paul Pu Liang, AmirAli Bagher Zadeh, and Louis-Philippe Morency. 2018. Efficient lowrank multimodal fusion with modality-specific factors. In Proceedings of the 56th Annual Meeting of the Associatio

爱奇艺短视频打标签技术解析

Fri, 18 Jan 2019 00:00:00 CST

写在前面

最近几年出现了很多以短视频的创作和分发作为主打的手机应用软件，这极大地丰富了文本和图像之外的信息创作和分发方式。这些短视频应用自从问世以后，便迅速地占领了市场，得到了广大用户的青睐。目前，短视频正逐渐成为互联网上的一种重要的信息传播方式，由此产生了大量的短视频数据。

为了更好地利用短视频数据，提升短视频的创作和分发效果及效率，需要为短视频打上各种有用的标签，这些标签可以作为短视频所记录的内容的概括和总结。以此为基础，推荐系统或搜索引擎就可以利用短视频标签为用户提供精准的短视频推荐或搜索服务了。

为了推动视频理解的技术进展，2016年谷歌发布了目前业内最大的视频数据集YouTube-8M，并基于此在2017年和2018年举办了两届视频理解挑战赛，挑战赛的目标是在谷歌给定的训练数据以及预先提好的音视频特征上设计并训练机器学习模型，以求在测试集上达到最佳的性能。以2018年的挑战赛为例，谷歌发布的视频数据共计600多万条，包含的标签共计3800多个，吸引了来自全球40多个国家和地区的390多支队伍参赛。这个比赛具有很大的挑战性，所有标签的标注都是视频级别的，也就是我们只知道这个视频中有给定的标签，但是，我们并不知道它在视频中出现的具体时间段。我们针对爱奇艺短视频打标签的解决方案便是源于对这两次竞赛自研的神经网络模型。

技术分析

在预先提好的音视频特征基础上设计神经网络模型进行打标签的问题，可以归结为设计一个有效的音频和视频特征聚合模块的问题，这里所谓聚合就是将若干个特征向量组成的矩阵变成一个向量，从而可以输入任意的分类器进行分类。

我们针对音频和视频特征聚合采用了相似的处理流程，并在最后对音频和视频的聚合结果进行融合，然后输入混合专家神经网络进行分类并输出标签。以视频特征聚合为例，视频首先通过采样变成了若干张图像，然后对每张图像提取一个固定长度的特征向量。我们分别考察了特征向量的不同分量的重要性以及不同的特征向量的重要性，提出了基于门控和注意力机制的神经网络聚合模块，简称为门控注意力神经网络，该模块的所有参数可以通过反向传播算法学习得到。

特征向量的不同分量的重要性主要是通过将一个视频的所有特征向量进行时序平均池化生成一个池化向量，并将其输入一个两层的神经网络，第一层的神经元数目小于池化向量的元素数目，这构成了一个瓶颈结构，这个两层的神经网络的输出经过Sigmoid函数激活后逐点地乘以视频的每个特征向量的不同分量，这个结构被称为瓶颈门控，通过学习可以自动地得到特征向量每个分量的重要性。

不同的特征向量的重要性是通过注意力机制实现的，通过引入若干个可学习的注意力向量，对于每个注意力向量我们可以得到每个特征向量的权重，然后将特征向量进行加权平均得到一个池化向量，最后将这些池化向量拼接起来就可以得到视频的所有特征向量的聚合结果。

案例

下面我们给出在姜饼短视频上采用我们研发的模型打标签的结果，如下面的图片所示。这里的每一张图片来自一段15秒的短视频的截图，我们把打出的标签以及置信度叠加到了图片上。我们的打标签模型可以打出实体类标签，比如，宠物和美食；可以打出人物类标签，比如，萌娃；可以打出动作类标签，比如，舞蹈；可以打出时尚类标签，比如，美妆；还可以打出技术流特效这种标签。这里仅举了几个例子，实际上我们的模型可以涵盖姜饼短视频的几十种类型标签。

效果说明

我们研发的单个神经网络模型在2017年YouTube-8M挑战赛的测试集上领先于最佳单模型NetVLAD达到0.9个百分点GAP（Global Average Precision）。2018年的YouTube-8M挑战赛增加了模型大小的限制，要求提交的模型解压缩后小于1GB，并且可以被TensorFlow的API直接读取。我们扩展了针对2017年挑战赛设计的模型，提出了一种多分支特征聚合方法，该方法在2018年的YouTube-8M挑战赛的测试集上领先于两个并列的最佳单模型NeXtVLAD和谷歌最新版本的DBoF达到0.3个百分点GAP，并且是唯一一个GAP超过88%的单模型。

针对上面介绍的模型，我们进一步加入了文本特征，文本特征来自于标题经过神经网络处理后的固定长度的向量。通过融合音视频和文本特征我们的打标签模型的性能可以得到进一步的提升。目前短视频打标签模型已经在公司内部的姜饼短视频、信息流等业务中落地，覆盖上万种高质量内容标签和几十种类型标签，每天持续而稳定地提供短视频打标签服务。

总结/延伸

我们针对弱标注下的短视频打标签这个问题进行了深入研发，得到了几种神经网络模型，取得了业内性能领先的短视频打标签单模型，申请了若干项中国发明专利，并成功地在公司的几个业务中落地。但是现在的技术只输出了视频级别的标签，对于更长的视频可能会有需求希望能够定位到标签出现的具体时间段，未来可以扩展相关技术不仅实现打标签，还要实现标签的时间段定位。

未来规划

短视频应用方兴未艾，可以预见的是未来将会有大量的短视频数据被创造出来并发布到互联网上，将短视频打上标签是活用短视频数据的主要途径之一。我们针对短视频打标签这个问题进行了深入的研发，并取得了一些结果，但是，仍然有很多问题亟待解决。

第一，我们目前的模型只覆盖了上万种高频的标签词，但是，这些标签词只能代表短视频内容的一部分，未来还需要对标签词的数量进行扩展，以覆盖尽可能多的视频内容；

第二，我们研发的模型受限于底层提取音视频和文本特征的神经网络的性能，未来还需要研发性能更好的提取音视频和文本特征的神经网络模型；

第三，我们无法期望仅用一个模型解决所有的短视频打标签问题，未来我们会针对现有模型无法很好处理的标签类型研发更好的短视频打标签模型。

扫一扫下方二维码，更多精彩内容陪伴你！

评审的艺术——谈谈现实中的代码评审

Tue, 15 May 2018 13:30:23 CST

　　曾经写过一点关于代码评审（code review）的文章，比如这篇和这篇，现在觉得关于它的认识又有了不少更新。软件工程的技术和实践分成两部分，一部分是和书本知识一致的，大约占一半，这部分基本上在大学里就可以学，自学只要方法得当、刻苦努力也可是途径；但是第二部分来自于实际团队、经验，内容通常无法从书本当中获得，而且难说对错，不同的人和不同的经历造就了不同的认识。代码评审就是第二部分颇具槽点，可以大加讨论的典型。

　　代码评审是展现个性和性格的途径

　　我本人特别反对一种颇为常见的观点，就是“一个良好运作的项目，不同的人，应该写出一样的代码”。我非常理解这种观点的初衷，一个良好规范约束的团队中，不同的人写出来的代码应当一致。但实际上，能真正这样做的团队，我还根本没有见到过。所谓的一致代码，仔细品味，发现不同的工程师写出来就是不一致。因此“一致”这个词一定是在一定程度内的大体描述而已，并非越一致约好。其实，代码的创造本就是具备个性的。毫无疑问我们应当遵从规约，应当符合习惯，但是一旦试图过度使用它们去约束代码，不但难以落实，而且容易产生无趣、低效和矛盾的氛围。

　　再回到代码评审上。代码评审本身，以及基于评审意见的来回沟通，和代码本身比起来，要更难以，也更不应该要求一致。我见过许多代码评审的风格，有人喜欢挑小毛病，有人喜欢展开观点夸夸其谈，有人喜欢给实际例子来证明自己的看法……无论哪一种风格，我都不觉得有什么大的问题。但是，就我个人而言，我可以谈谈我自己的代码评审风格：

　　我会关注三种问题，需求和业务上的问题、代码结构的问题、代码风格格式的问题。

　　前两种可能存在阻碍我ship代码的“严重”问题（说“ship”就意味着认可代码具备了push到主线分支的条件了）。我已经记不清多少次和代码作者因为这样的问题争论了。争论是个艺术，有时候并不一定能够达成一致，有的人比较容易被说服，有的人则更坚持己见。我不想说哪一种更好，但是确实这是代码评审中展现风格的事实——都是就事论事，但有人害怕或者不喜欢得罪人，就会显得push over一点；有人则不在乎那么多，坚信自己的想法更合适，就会显得defensive一点。我可能属于后者，似乎在职业生涯的各种阶段都会有和我出现代码评审冲突的事例，但是在某些情况下我也会选择disagree and commit（不同意但是执行团队达成的意见）。我相信有些团队会喜欢我的backbone，也会有团队讨厌我的这种风格。下面的内容，也多为基于自己风格的表述。

　　坚定自己的意见，但是委婉地表达

　　关于这一点，我也在努力地改进。可以提及的点很多，技巧也很多，但是老实说，冲突还是不可避免。在我经历的几乎所有的团队中，有时候会有老好人，但是基本上所有的老好人都缺少对于原则的坚持。沟通是门艺术，在代码评审中也一样体现。

最重要的一条，只针对代码，不针对人。这条很简单，都知道对事不对人的重要性，但是要非常小心不能违背。
对于大多数代码风格格式上的问题，我都会标注这个问题是一个picky或者nit的问题（“挑剔的问题”，这是我在Amazon的时候学到的方式）。这样的好处在于，明确告知对方，我虽然提出了这个问题，但是它没有什么大不了的，如果你坚持不改，我也不打算说服你。或者说，我对这个问题持有不同的看法，但是我也并不坚信我的提议更好。
使用也许、或许、可能、似乎这样表示不确定的语气词（包括使用虚拟语气）。这样的好处是，缓和自己观点表达的语气。比如：“这个地方重构一下，去掉这个循环，也许会更好”。
间接地表达质疑。比如说，看到对方用了一个参数3，但是你觉得不对，但又不很确定，可以这样说：“我有一个疑问，为什么这里要使用3而不是其他值？”对方可能会反应过来这个值选取得不够恰当。
放上例子、讨论的链接，以及其它一些辅助材料证明自己的观点，但是不要直接表述观点，让对方来确认这个观点。比如：“下面的讨论是关于这个逻辑的另一种实现方式，不知你觉得是否会稍简洁一些？”
先肯定，再否定。这个我想很多人一直都在用，先摆事实诚恳地说一些同意和正面的话，然后用however一转，说出相反的情况，这样也就在言论中比较了pros和cons，意味着这是经过trade-off得出的结论。
……

　　一些很常见的可以在代码评审中提及的问题

　　这样的问题其实有不少，多数和实现的技术无关，但是又很容易不小心略过。它们多数时候是问题，当然也有时候不是。

比如说，我最痛恨的之一，职责过于宽泛或者职责不清的类或模块。我无数次见过这样的类：Helper，或者Utils（注意，它们都没有模型或者模块前缀）。考虑项目的规模，大多数情况下，这样的类很容易变成一个越吹越大的气球，似乎什么东西都可以往里搁，是个十足的违反单一职责原则的糟糕设计。
比如说，在线程使用，容器使用，连接管理……中，缺乏上限控制的设计，在一些情况下导致资源使用过度膨胀。生产者和消费者的队列设计，一旦消费者挂掉或者跟不上，队列里越堆越多，没有拒绝机制。
再比如说，缺少分包、分层，所有的东西都叠在一起，十几个，甚至几十个类文件并列在同一个文件夹下面。
再再比如说，代码缺乏设计，流水账结构，面条型代码，或者简单铺陈几个过程式的方法，这种修改往往代价还不小，自然修改的落实率低，因而令提出问题的人也颇为头疼。
……

　　避免一次评审提及过多的问题

　　少数情况下，手里拿到一份实在是问题多到令人发指的代码，这时候需要扼制自己想骂人的冲动。先抓问题的主干，不要去挑那些细枝末节的毛病，因为很有可能，这些代码会被改得面目全非，或者重写。写一大堆评审意见，反而容易淹没最重要的问题。

　　说说容易，但是这个度有时候并不好掌握。我的习惯是，在明确代码要解决的问题以后，先快速走读一遍代码，判断我是应该粗略地抓主要矛盾呢，还是应该严格地挑刺呢。我也见过一些别的方式。

　　不一样的评审要求

　　我始终觉得，代码评审的要求不应该完全一致。不要过度追求公平。对于新项目代码，以及新员工写的代码，要适当严格一些。

　　新项目的代码是形成后续风格和质量的模板。我们也许都听说过“破窗户原理”，在一块干干净净的代码田地里，新耕种的代码才容易保持一致，也可以避免一些“为了和现有代码风格保持一致”而导致质量妥协的情况出现。

　　新员工代码的高质量要求则更多地在于对他们良好习惯养成的负责。软件工程师良好职业习惯的养成，代码可以说是最重要一环，而前三个月的影响举足轻重。

　　还不如不做的评审

　　有些情况下，代码评审是非常耗时费力的工作。特别是对业务背景不熟悉，对实现技术不熟悉，或者干脆是对方提交上来一大堆修改，阅读非常费力。我不知道哪一种是最难的，但是如果因为这些原因很难做到良好的评审，我会在评审中说明，或者放弃一些评审的工作，保证评审的质量。

　　代码评审是建立在团队中影响的好方式。一方面是业务逻辑，一方面是代码结构，我反对在两方面都难以给出足够清晰的评审意见的时候，提一堆风格方面的次要问题。否则很容易达成负面影响。

　　先谈到这里，我想还有不少可以涉及的内容，而它们都难以在课堂和书本上学到。争论才有意思，实践出真知大抵如此吧。你有什么一致的看法，或者反驳，欢迎和我讨论。

如何看待艺术家在展览上泄露 34 万武汉人的个人信息？ - 知乎

Sat, 14 Apr 2018 13:29:41 CST

这种包含发动机号/动车票购买的数据怎么看都是公务部门流出来的

说句题外话，有一件很讽刺的事情是，中国驻美国大使馆的电话会被谷歌等自动默认为垃圾／骚扰电话

原因就是一直有诈骗电话通过驻美使馆的电话号打过来且接到电话的都是留美的中国人。诈骗电话模仿号码不要紧，但为何骗子会知道在美国的中国人名单？

具体的技术我不懂，但我自己就接到过...诈骗内容和国内假装公安局一样，说是资料出错，必须支付多少钱来进行调查，否则在美签证会出现问题

关键是号码不是随机的，我身边已经回国的朋友也接到过，这说明这个联系方式是真的，被骚扰以及试图诈骗的人都是来过美国的人...

这些政府采集的个人数据到底是怎么流出去的？以及苹果云的中国服务刚转到运上贵州这种国资就出现个人资料泄露

我个人是支持这位艺术家的，事情不是假装没发生就没发生的，与其开始谈这位艺术家数据来源非法，要不要先社会公布下调查进展？

湖北得伟君尚律师事务所律师曹剑刚表示，艺术家从网上购买公民个人信息，数据来源非法。“公民的信息、隐私受法律保护，法律在民事责任、行政责任、刑事责任方面都有相关规定。违反国家有关规定，向他人出售或提供公民个人信息，窃取或以其他方法非法获取公民个人信息的，造成严重后果的可入刑。”

说实话，前两天看一个美国上市公司的招股书，一家广告科技公司，也让我觉得有点不自在。它家的广告是地理位置数据驱动的广告，即它本身与电信运营商合作，并与无数app合作进行广告推送，通过精确到个人的位置数据，对这个人的品牌（去过的商店，餐馆，etc)进行分析，再进行推送...除此之外，还有个服务叫做geo-conquest，打个比方，大意就是你进了阿迪店，你的位置被获得，于是在你提着商品去结算前，你手机里的各种有广告的app,包括音乐的，搜索的，聊天软件的，开始给你发送对手及广告商客户比如耐克的产品广告，不论是听音乐中途的有声广告嵌入还是屏幕上的，来影响你的决策，让你产生"去隔壁看看吧"的想法来影响销售。很好的策略，但这种"你自己的决策不是你真实独立的决策"的感觉的确让人不自在

数据安全真的是...接近一个临界点了　

[酷工作] [爱奇艺-成都] 招聘：技术总监（算法方向）/算法工程师

Tue, 28 Nov 2017 11:01:11 CST

爱奇艺目前 D 轮啦，研发中心在北京以及上海，目前在成都搭建新的研发中心，欢迎有兴趣的小伙伴来联系我哈。

技术总监（算法方向）
岗位职责:
1.负责 AI 算法团队的管理，研发和建立工作，方向包括计算机视觉、音视频编解码、自然语言处理、机器学习、深度学习、搜索、推荐等方面；
2.基于产品需求和用户场景设计技术方案、包括算法选型、稳定可靠的工程架构，实用性调优等，并根据业务发展做好系统整体容量规划；
3.根据业务发展把握 AI 的重点发展方向、指导工程师的算法研发，组织工程师团队对算法、技术攻关，将创新的技术推向市场；
4.有效带领技术团队，建立并完善公司各项研发规范及流程，培养下属成员，提高团队整体专业技能。
任职要求:
1.计算机及相关专业硕士以上学历，相关领域 5 年以上工作经验；
2.技术能力全面，了解各种主流算法模型，熟悉大数据系统架构和开发框架，对机器学习，算法优化问题有深入的研究和理解的优先；
3.有较强的数据分析和解决问题的能力，组织和沟通能力强，思路清晰，有将复杂问题拆解并实施的能力；
4.扎实的编码能力；
5.有带领算法团队的经验者优先；
6.有三年及以上 20 人+的算法团队管理经验。

算法工程师

特殊说明:人选方向：AI 视频理解、AI 机器学习、搜索算法、广告推荐算法
岗位职责:
1. 用户搜索 query 理解与分析，优化搜索相关性优化；
2. 负责线上推荐算法的设计和实施，个性化推荐算法模型的设计开发和迭代；
3. 挖掘视频相关特征，优化搜索排序模型；基于用户搜索日志，挖掘用户的搜索意图，提升用户搜索满意度；
4. 从端到端跟踪算法的实施效果，从多维度分析线上线下数据，不断优化模型并提高推荐效果；
5. 追踪推荐、NLP 和机器学习领域的前沿技术，参与搭建和实现算法原型。
任职要求:
1. 计算机、数学相关专业本科及以上学历，3 年以上 AI 视频理解、AI 机器学习、搜索算法、广告推荐算法相关工作经验；
2. 了解推荐、广告等算法模型，熟悉大数据系统架构和开发框架，对机器学习，learning to rank，算法优化等方面有深入的研究和理解；
3. 熟悉常用算法和数据结构，熟悉系统架构和设计模式；
4. 有较强的数据分析和解决问题的能力；
5. 组织和沟通能力强，思路清晰，有将复杂问题拆解并实施的能力。

简历请发： fancyfrees@yeah.net
我的微信：fancyfrees

关于青少年艺术教育讲座的文字记录

Thu, 08 Oct 2015 05:10:03 CST

前段时间在微信群上的讲座，原来是语音的，无法保存，所以转换成了文字便于查询。

1 青少年艺术教育起点在哪里? 年龄? 基础是什么?

首先今天我所讲的都是针对的已经考虑以艺术为专业的孩子，而且真正已经开始学正规绘画的这种。所谓的那些儿童绘画训练啊什么的那个就不是今天讲座的主要内容了。毕竟这个儿童绘画和真正的绘画它是有一定距离的。一个是有意识的一个是无意识的，有点像教小孩弹钢琴和教作曲这个区别。所以我们要考虑的就是起码十二岁以后的事吧。

我认为对在美国的孩子来讲，要正规学画画，应该是初中以后比较好，初中开始呢这个时间也比较从容。学画也不用这么紧张。而对于刚开始接触这个基础训练的孩子来讲画画可能是非常枯燥的，所以在前面的阶段我不建议负担太重。一个星期画一个小时就足够了。从我自己女儿的这个经验来看也就是一个星期一个小时，甚至到了暑假我们都是不上课的。就这样不紧不慢地学。如果是小孩子正规学画时年纪比较晚一点，到了高中他的自觉性，他的专注力和他的理解力都比较成熟以后，那么可能一个星期画两小时甚至于更长都是可以考虑的。

对于学艺术的孩子来讲最重要的基础我觉得第一个首先是对绘画发至内心的这种热爱。而这也是我不建议十二岁以前小孩就拉她去学画画的原因之一。因为大部分的孩子十岁之前他都会把绘画当做一个表现自己感情的手法，特别是在他不会写字不会写作之前。每个孩子都是要画画儿的，所以十岁以前的小孩几乎人人都在画。你不能就此认为他是喜欢画画了。只有到大一点以后他还那么喜欢画画，那么我觉得这个时候你才可以真正认为他有这个兴趣，是真的值得培养了。所以我觉得第一是兴趣，而第二个从专业上来讲要学的话还是必须学素描色彩这些很基础的训练。

2 如何选择艺术院校? 美国有哪些? 特点和优缺点?

选择艺术院校我觉得最重要的一个就是不要太关注于排名。因为艺术的这个本身排名它的标准就是非常难以量化的一个问题。所有的排名肯定争论都特别多。当然了美国大概是有这么三十来个特别好的学校。但是大家又是以就是以专业来区分学校的好坏。艺术学院跟很多大学不一样的是大部分人在进大学之前他心里已经很清楚要学什么专业了，这个时候再去按照自己专业的兴趣寻找学校这个是最可靠的。而总的说来就是一定要适合自己的是最好的学校。

所以能进这三十来所艺术院校都是好学校，基本上就不要再考虑这三十个学校之间的排名了。当然每个学校他都有自己的特色，有些学校就是某个专业某一方面是比较强的。所以这个具体的专业排名可以在网上查找，或者问问其他老师。因为每个专业真的都是非常不一样甚至于同一个专业每个学校的侧重点也是非常不一样的。所以很难在这里一下子概括。

3 艺术学院毕业职业前景如何? 建议?

从这个题目听起来的话那就还是家长对艺术学院专业的分配不是太熟悉，因为艺术学院基本上就是什么专业决定你是什么样的就职前景。具体到每个专业都会非常不一样。总体说来呢就是纯艺术专业也就是所谓的绘画雕塑这些是比较困难的。那么设计专业就会好很多。在设计类的话呢最容易就业的目前来看呢可能是网页设计，平面设计，还有游戏设计三维动漫这些专业。也就是说基本上是跟电脑有关的，跟那个internet有关的专业就业前景是比较好。

如果你学这个艺术专业但把就业看得很重要的话呢。那么我就认为应该就最好学跟技术有关的专业他就会比较容易就业。包括网页设计。这个多少得会写一些code。总的说来就是，你又懂艺术又懂技术的人，未来肯定是在这个就业市场上市会占优势的。或者说你又懂设计，又懂marketing这种复合型的人才肯定他都会比较有优势。

4 当代多媒体艺术对艺术教育的影响和变化。

这个当代多媒体艺术对艺术教育的这个影响我觉得首先它就是对我们对艺术的这个基本的概念会有一些革命性的改变，比如说三十年前可能没有人会在电脑里面做出艺术作品来，没有人会认为digital art会成为一个很成熟艺术分支，但是今天就是它都成为一种可能。而且很多靠电脑做出来的电子媒体多媒体的艺术品他的艺术情趣，艺术表现力一点都不会低于这个传统媒体的。所以我认为呢，它首先是在观念上给我们一个全新的这个冲击，第二个那就在表现手法上给了艺术家更丰富的表现力。现在突然多出了那么多种全新的材料和媒体。

那么对于一个教师来说你就必须要跟上这个时代。我知道早年在中国教photoshop这么一个简单的软件的时候居然都是需要两个老师来教。一个是工科的老师他懂软件他就教学生怎么样使用软件。然后又有一个学平面设计的老师来教学生怎么样做设计。那这样的事情在未来就觉得不可能发生了，你这个艺术家本身就对所有的这些软件甚至编程什么的都得会。你必须合二为一甚至于合三为一的。

还有就是现在很多教学已经是以多媒体的形式出现，高效省力。

5 有哪些艺术方面的夏令营适合高中生？

夏令营的话对于的喜欢艺术的学生来讲那肯定就是各个艺术院校自己举办的这些夏令营最合适。一般来讲的他都不叫夏令营，它可能叫 pre college program更为合适一点。因为这些都是已经决定了要把艺术作为专业的学生去上的，这些课所以蛮紧张的不会是轻松混日子的。如果要选择夏令营的话那么我建议你心里面已经有了底想要报考哪个艺术院校以后你就去读它的这个夏令营，这个会对你以后的录取肯定是有很大的优势的。

每个艺术学院的夏令营的价钱应该是都差不多，平均可能一个礼拜要一千或者一千出头的样子。所以在费用差不多的情况下呢，那么就是尽量去申请自己想要读的大学的夏令营。比如说像萨瓦纳艺术学院夏令营还有可能拿得到奖学金。你如果作品好的话有可能是拿得到很多奖学金。第二个我知道如果你平均分在3。2？以上你入学以后还可以算学分，而且如果申请就绝对录取。所以这样的话也觉得挺合算的因为你交了五千块钱但是你可以拿6个学分。

6 喜欢art，但本科把art先作为minor有什么利弊？

好处的当然就是如果觉得自己学不下去这个就是换专业可以很轻松地就换掉了。但是它的坏处就是你要学艺术这个真的是一个非常非常耗精神和时间的，是真的不可能轻轻松松地念出来。因为和其他的专业不一样。你比如说你要学数学，你作业做完了，你这个题目有了一个答案了你就结束了对不对？但作为你搞艺术的人来讲一个作品你可以用无休止的不停地修改，他永远都没有结束的时候。所以你要想花时间的话一张画可以画一个小时，也可以画十个小时，甚至你也可以花一百个小时。所以就看你内心对自己的标准有多高。

所以本科你只是作为minor的话呢我觉得基本上以后就不会把艺术当成那个专业了。因为你不全力以赴的话你是做不好作品。而且艺术跟其他专业还有一个不同的地方就是你的作品就是显而易见的就摆在所有人的面前的，所以他真的是也是很考验一个小孩子的心理素质的。很多孩子在一进学校以后就觉得自己画不好。一两年下来整个心理上完全就溃败了他就完全就放弃了，所以要经常给学艺术的孩子打打气。包括我的老大上了大学一年级也有这样的感觉。你本来是整个高中你画得最好的一个，你信心满满的跑到大学里面一看，结果发现怎么画得好的人那么多。而且不像考试拿个分数大家互相不问也不会知道，你也就没有明显的比较。这个一画画就是叫你们大家这样全部铺开了来看的，所以它是非常显而易见的。如果不是那个很坚强而且很热爱的话真的是很难坚持下来。所以的话呢我就说你喜欢画画就是当着minor, 当一个情趣熏陶也是挺好的，但是真的要作为专业的话还是还是有一定难度。

7 有哪些非纯美术专业适合美术好的孩子学或者说对美术有要求？

其实美术专业好的话对很多很多专业都是非常有帮助的。就包括你是个科学家你做presentation的时候你都可以把它做的很漂亮啊！我觉得学了绘画都不会是浪费的。但是作为专业来说，比如建筑专业。他不算是纯美术的但是它对美术要求其实非常高的。甚至有的就艺术院校就把建筑专业是作为艺术专业来考虑的。所以像建筑啊什么的啊还有做这个动画动作的，我说这个跟做造型的那种动漫还不一样。这个就是专门只是建模只是做动作，那这个一定也是要有美术基础的。

还有就是比较边缘的专业比如网页设计。它可以往那个programming 那边靠也可以朝设计这边靠。你如果懂美术你去再念一个编程专业的话那你肯定做出来的东西就是绝对不一样。我本人就是在做界面设计的，像我们整个IT部门都全部是外包到了印度！但是设计这一块无论如何印度人他就做不下来。他因为他对这个设计的感觉就是差很多，尤其是跟美国公司的审美相差很大的，所以这块儿就是怎么都不肯外包的。

那么前面必须回答的这些问题回答完了。那么我就讲一讲我培养小孩这个经验，还有我接触很多学艺术的孩子和家长的感受。培养孩子学艺术，我觉得其实一个最大的误区就是父母用力过度。很多父母总觉得我要怎么怎么样从小抓起来。其实小的时候根本就不必这么紧张。最最重要的就是你观察自己的孩子是不是真正的热爱？如果他对绘画是真正热爱的话那么一切真的就可以迎刃而解的。那个基础训练呢，这个也非常重要，尤其是入门的时候十二三岁时。有什么样的老师教这个是非常关键的一步。选对老师是非常非常重要的。

还有一个呢对于学艺术的孩子来讲，其实家长就算是不懂但是我觉得你能做的就是经常带小孩子去看看画展了看看博物馆。就这个熏陶，他对艺术有这个鉴赏能力。他知道什么是一个好的艺术品，看的好东西多了他做作品的格调就自然而然会上去。

哦我还要补充一下前面说这个关于用力过猛的问题。因为像我接触好几个中国家长他们的孩子都学艺术已经毕业了，而且现在都做的很好。我就发现的就是这些家长因为反正根本也不懂也就从来没有给他们找任何私人老师。就小孩自己特别喜欢，然后就跟着高中的美术老师学就考上去了。结果还学得挺好的。其实坦率来讲美国的大部分艺术院校是非常容易进去的，但是并不意味着容易念！大部分的艺术院校，可能就只有百分之六十的毕业率，很多人他根本就是读不下来，容易进但是很难出来。艺术院校不好念的，所以就算你进一个就是很容易进去的学校根本也不意味着你能轻松毕业，也不意味着它不是一个好学校。

启蒙老师我还是推崇学院派的。一定是要经过正规训练的老师。这个什么是好老师啊有的时候真的比较难说。因为有些好艺术家他也未必就是一个好老师。这个对我自己来讲因为我懂所以我觉得很容易挑选。但是的确对有的家长真的就会觉得摸不着白。有的老师是老是炫耀他的学生上了这个艺术院校怎么怎么样，但是在美国大部分的艺术学院是很容易进去的。你进了艺术院校也并不意味着你就是能成为一个好的艺术家或者设计师。

8.纽约的服装设计学校有哪些？

服装设计学校两个最好的学校都在纽约，一个是Parsons一个是FIT。Parsons是私立的FIT是公立的。公立的要便宜些。这两个学校不相上下就是有一些争论到底哪个好哪个不好，我觉得都是差不多。

9.电脑上画画用什么软件好？

电脑画画也一般都用photoshop就可以了。photoshop它有很多那个入门的课程呢，我觉得随便随便在网上找一找哪儿都有。像我们这包括法拉盛都有那个华人的补习班，教photoshop。这个倒是挺容易的，很多小孩子一学就会了，看看网上的教程就可以了。不过呢我不主张太小的时候去学用电脑画画因为他没有绘画基础。没有基础的话他不可能画的很好，而且掌握那个电子笔也不是那么容易的。所以他太小的时候你让他用他反而就一下子觉得他掌握不了，反而没兴趣了。

10. 十一年级想学服装设计应该怎么办

他就要赶快去学画这个时装插画。把这些时尚杂志啊什么的拿来看一看，可以把这些图片怎么换成服装效果图儿，要赶快学一学。还有就是要多画人体模特儿，没有模特儿临摹也行，还要学会变成9头身等等。我其实本人本科就是学服装设计的，如果他以后有什么问题你可以继续私信我啊！

11.现在做 portfolio很多用摄影作品吗？

你是指普通专业用摄影作品还是说艺术专业？如果艺术专业的话据我所知除了摄影专业之外其他专业的用摄影作品是不会太多的啊。学校最看重的还是就是你的造型能力，就是你的创作，素描啊色彩啊这些东西啊。应该不会用那么多摄影作品的。

十年级以后就可以参加这个portfolio day ,是一个很重要的一步。到网上一查这个portfolio day 网站就出来了。是全国很多大城市同时搞的。这些艺术学院老师就出去像摆摊一样的给学生看画给你建议。有的学校就是直接录取。这个在我下面那篇文章里面都写得有。

青春就应该这样绽放游戏测试：三国时期谁是你最好的兄弟！！你不得不信的星座秘密

前沿技术是否前沿？爱奇艺首席科学家揭秘视链技术

Thu, 30 Jul 2015 23:05:00 CST

“云视链”CEO 金证济苍

近日一则围绕“ 22岁、6亿估值、秒杀Google”等关键词进行宣传的创业圈新闻在业内引起了广泛讨论。众多互联网媒体瞬间化身“八卦小报”，对话题主角金证济苍，展开了360度无死角的人肉搜索，并爆出Venvy Inc 官网内容造假、高管资料伪造等猛料。也有媒体对于“视链”技术进行了质疑，并称其不过是营销噱头而已，并没有所说的那般前沿。

业内人士对这一技术的探讨热情也丝毫不弱。在雷锋网所在的微信群里，爱奇艺首席科学家王涛就对“视链”技术的现状进行了深入介绍。究竟“前沿科技”是否前沿？我们一起来看看爱奇艺首席科学家王涛作何解读。

在微信群内，王涛简单直接地表示：

“技术很早以前就开始做了，在技术上并不新鲜。爱奇艺从2010就开始上线视链功能”。

究竟视链技术是一种怎样的技术？

所谓“视链”功能，是通过对影视剧中内容进行注释，并链接至有关的信息介绍页面，为用户提供更立体化的观映体验。目前的视链技术主要应用于视频广告。

国内市场上，爱奇艺、优酷、土豆、PPTV、腾讯视频、搜狐视频、乐视等多家视频网站都陆续开始支持视链技术。以爱奇艺自家的“随视购”为例，随视购分为剧名相关、场景相关，物品相关，同款等不同的类型和级别。在影视视频中，常用的主要是物品和场景识别。物品识别是强关联，例如视频中出现的同款商品，主要是3C、汽车、服饰。场景识别则是弱关联，例如视频画面是在商场儿童区，那就可以推送儿童玩具广告，不一定是视频出现的具体物品。

是否会影响用户的观影体验？

视链作为视频内容的补充部分，不可避免地会对用户观看视频造成一定的影响。

据王涛介绍，植入视链功能的广告都是短暂地弹出（持续10秒）。植入形式类似各个电视台的角标图片，常用小尺寸、半透明的设计素材，在整体观感上对用户的干扰较小。一般来说，视链广告与视频内容部分都有很强的相关性，不会突兀地进行推送，所以广告也可理解为内容的一部分。比如你是一个韩剧迷，推送视频剧中明星的同款衣服，相信你还是会很感兴趣的。

另外，不少视频网站也开始尝试多种风格的角标广告，确保不打扰用户观看视频。

那为何“视链技术” 没有大范围的应用？技术门槛在哪？

大家对于视链技术有两个方面的误解：

1、视链技术目前并没有大范围的应用。

2、视链是一个技术门槛很高的技术功能。

对于第一个误解，主要是由于视链技术针对的都是广告商，所以普通的消费者不会有很强烈的感知。根据目前支持的视频网站数量来看，视链技术已经有非常普及的应用。对于第二个问题，视链其实对技术的要求并不高，这也是为什么爱奇艺在2010年就已经开始视链技术的应用。

相比之下，视链对于“资源”的需求有更高的要求。为了实现“智能化”推荐功能，必须要实现 “视频、商品和用户”三者之间的精准对接，从而需要三方面都拥有海量的数据做支持。对于视频网站而言，其除了视频内容之外，还需要有丰富的产品图片、电商产品信息以及内容审核的技术支持。

视链技术的基础是图片识别，所以海量资源的图片库必不可少。这一点上，百度和Google很早就开始布局图片业务，作为百度旗下视频业务，爱奇艺也具备“近水楼台”的优势。有图片做基础素材，视频广告需要接入足够多的电商商品样本，才能训练分类器更准确地识别众多商品，从而提升广告商品的识别精度。目前，爱奇艺随视购广告接入的客户主要包括电商平台，如京东和苏宁，也有店铺、商家进行广告投放。

在商品识别精度方面，王涛表示，国际图像识别最大的数据库imageNet的图片库，对于产品的识别效果其实也并不理想，而且很多产品的标注也不够准确。为此，爱奇艺使用了京东等电商网页上的关键字标签和剧照，来反向识别出对应视频剧集的点位，来增加同款商品识别的点位。目前，国际上图像分类的top5 识别精度能达到95%，物体识别的精度就只有50%多。

另外，海量数据的匹配需要进行内容信息标注。目前的标注方式有人工和机器识别。对于手工匹配完成不了的，需要通过人工智能、计算机视觉、大数据分析等技术来给予支持。相比人工智能识别，手工匹配适合于项目初期，可以实现投入可控。但是想要把规模做得更大，就不能全部依赖人工标记。目前，常用的是半自动的筛选方式。例如，首先使用深度学习的分类器，自动识别出3C，服饰等商品，以及厨房，卧室，办公室等场景。然后人工审核标签，得到视频中插入随视购角标广告的点位。

视链技术的广告效果如何？

在广告植入上，爱奇艺的随视购功能一集只出现最多2个点位，未来最多安排3~5个点位（每隔15分钟左右一个）。广告投放效果方面，据调查，如果能够做到同款相关，点击率会比传统广告高5~10倍以上。随视购功能上线半年之后，从展示效果来看，已经能够覆盖5亿以上的用户。至于更多的广告效果数据，爱奇艺方面表示属于商业机密，暂时未对外公布。

总而言之，视链技术作为一种新的交互广告形式，在技术上并没有新闻稿中写的那么高深，阻碍小厂商涉足的门槛其实是背后所需的庞大“资源”积累。作为一个小的创业团队，想要挑战固有的市场、技术诚然勇气可嘉，但利用媒体资源进行“过分地夸大宣传”，对创业来说却不一定有帮助，毕竟检验产品的最终还是市场！

申请艺术院校的10个建议-By Lucy Xue

Fri, 26 Sep 2014 01:01:53 CST

这是大女儿给世界日报写的一篇约稿. 希望对申请美国艺术学院的学生家长有点用.

TEN TIPS FOR APPLYING TO ART SCHOOLS

1.Don’t ask “What is the best art school?” Ask “What is the best art school for what I want to do and the kind of person I am?” 不要问哪个艺术学校是最好, 要问哪个学校最适合我未来发展的方向?

2. Every art school looks for something different—some look for technical skills, some look for abstract, conceptual ideas. Do your research ahead of time. 每个学校招收的学生都不一样, 有些喜欢招有技巧的学生, 有些看中有抽象思维能力的学生. 先做好你的案头工作.

3. Visit National Portfolio Day, a nation-wide event where representatives from most major art schools will review your portfolio and give you advice on how to tailor your work to fit their tastes. 参加全国作品日活动, 全美重要的艺术学院在那一天都会排老师审阅学生的作品集, 他们会为你的作品怎样更符合其学校的要求提出很好的建议.

4. Your portfolio should have 10-20 pictures in it, although the exact number varies from school-to-school. Remember to only show your BEST work. It is better to show less than more. 你的作品集应该有10-20张作品, 尽管每个学校的要求不尽相同. 记住只拿出你 最好最棒的作品, 宁缺勿滥.

5. There are mostly 2 types of art schools: one is more oriented towards generating creative students (better suited for fine-artists and those who want more creative freedom) and one is more industry-oriented (well suited for getting into mainstream industries, such as animation or video games). 大致说来有两大类艺术学院, 一类是产生艺术家的(主要适合画家等需要更多创作自由的纯艺术类人才), 另一类是比较商业化的 (主要培养主流商业化设计师, 比如动漫或者游戏设计)

6. Draw from life. Try to take a figure-drawing course, if possible. Other good exercises include sketching at cafes and zoos, doing still life studies, and plain air paintings. The skills here will benefit you no matter what field of art you go into. The key is that you are training your ability to OBSERVE, not necessarily your technique. 尽量画写生. 如果有可能,最好上一些人体写生课程. 其他有益的练习包括在咖啡馆和动物园画速写, 静物写生. 这些技巧不管你以后学什么专业都会受益. 最重要的是训练你的 观察能力, 不一定就是你的技巧.

7. Join online forums, such as conceptart.org. Many schools also have Facebook groups created specifically for incoming freshman. These are great places to interact with current students, make friends, ask questions, and see how well you will fit in with the community. 参加网上艺术论坛, 比如conceptart.org. 很多学校为新生设有有脸书页面. 这是和被录取学生交流的最好场合, 和他们交朋友, 问问题, 感觉一下自己和他们是否合得来.

8. Many art schools have pre-college programs, where you can enroll in summer courses as a high school student. These are great opportunities to get familiar with the school campus, surrounding geographical location, and the professors.

很多艺术学院有针对备考生的夏令营, 高中阶段不妨去修一些课. 这也是一个对学校校园, 地理位置和环境, 甚至教授全面熟悉的好机会.

9. Contact current students and alumni and ask them about their experiences and if they have tips on getting accepted. If they are alumni, ask them about how well they have been after graduating and if they thought their education was worth it. Most artists nowadays keep blogs and are easy to find if you know where to look. 和在校学生以及毕业生联系, 看看他们有没有什么录取方面的经验和建议. 如果是校友, 询问他们毕业以后的发展怎么样, 是否觉得他们在该校所受的教育物有所值. 现在大多数的艺术家都有博客, 多搜索一下就很容易找到他们的下落.

10. On the flip side, try contacting employers as well, and asking them what kind of schools they recruit from and what schools they recommend for specific fields. 另外一方面也和雇主接触一下, 询问他们一般从哪些学校招人, 在某个专业里他们会推荐哪些学校.

青春就应该这样绽放游戏测试：三国时期谁是你最好的兄弟！！你不得不信的星座秘密

如何通过几张穿着暴露艺术照片，找到当事人和拍摄地点？

Thu, 19 Dec 2013 23:49:23 CST

真心请大家不要再求种了！虽说发图不发种，菊花万人捅，但真的不能让隐秘信息从我这里泄露。。。。

首先需要声明的是，撸主并非技术宅或者技侦的爱好者。

只是机缘巧合，在撸主并未特别渴望获取相关图片等资源的情况下，撸主得到了两个艺术照片的压缩包（两个加起来月850MB）下载地址。

请相信我，撸主绝对是奔着其散发出的浓厚艺术气息，才决定下载的！

下载后解压缩，撸主丝毫没有被女主角曼妙的身材、坚挺的双峰、修长的美腿所打动，更没注意到木耳是黑色的等等细节！

为了网络和谐，为了文章不被和谐，过于不和谐的照片我就不放了。这几组照片的尺度绝对比从网黄老师放出来的要大得多。好吧，其实是已经不能更大了。

同时为了保护当事人，我把照片进行了处理。。

在撸主撸了一管，心满意足之后，突然有了思考人生的冲动：照片拍的这么好，不知道拍射者用的是何方神器？

于是撸主打开查看了照片属性：

我擦嘞！居然用的是我大iPhone5！

一看拍摄时间，2013年8月！

那时5s还没上市有木有！

能用起5的都是土豪有木有！

撸主向来喜欢和土豪做朋友，有木有！

此时一管刚完，一管又起。但撸主压制了自己撸管的冲动，决定继续发掘一点有用的信息。

各位土豪应该都知道，苹果手机有个功能，就是在拍照的时候给照片增加地理位置信息，这个功能可以让用户查看自己到底在哪拍过那些年不穿衣服的女孩。

好吧，请无视撸主手机里没有照片这一事实，�丝没有不穿衣服的女孩可拍，当然拍了也不会公然放在手机里。

于是乎，撸主继续把照片信息往下翻。

卧槽，居然看到了这样重要的信息！

亮度！白平衡！

这个信息太重要了！虽不明但觉厉啊！

请摄影专家来给大家科普一下！

于是撸主继续往下看！

我了个大去！！

果然让我找到了GPS位置信息有木有！

请原谅我再次隐藏了这个重要信息，为了保护当事人。

但，撸主不是GPS，并不能直接把这些数字转化成我能理解的地理位置。。

但撸主有一颗常人无法企及的聪明大脑：导入手机！

很可惜。。撸主的手机并不能显示导入照片的地理信息。。。照片都是我自己拍的。。

但！这可难不住撸主。。

各位想到了什么？

没错！神器GOOGLE EARTH！

打开神器，在添加地标里输入对应的经纬度，奇迹出现了！

这是中国中南某省某城市某区的某个普通的住宅小区。

在几组照片中，还有另外一个拍摄地点，

请无视最后几位的误差。。民用版本的GPS位置信息，有几十米的误差，是非常正常的。。。。

接下来，就需要用一点分析了：

用iphone5拍摄，说明两点，①是当事人不是像从网的黄老师那样专业拍私房照，②是双方对彼此有足够的信任。从很多更亲密的举动也可以佐证这一点。

而10组照片的拍摄时间，从8月初到10月末，历时大约三个月，但只有这两个拍摄地点。拍摄时间有白天有半夜，同时地点又是住宅小区，那我我有理由相信，所以很可能这两个地点就是当事人的居住地。

至此，假如我是个不法之人，准备拿着照片要挟一把，或者提出一些其他的诸如金钱等要求，完全可以去两个小区守株待兔！请注意，照片中女方的面容完全没有进行处理！

至此，我的故事讲完了。

我想说的是，随着手机功能越来越强大，大家经常喜欢把美好的事物记录下来，这本事件好事儿。

但是大家一定要注意自己的隐私。。像我这样的非技术人员，都可以按图索骥找到这么精确的信息，如果是真的技术员。。。。

经我测试，上传至人人网、q空间的照片，被下载后地理位置信息已经被擦除，目前看相对是安全的，但也许是因为我的能力不足。。

所以，提醒大家， 拍照有风险，上传需谨慎！

在这里告诉大家两个方法，除了加马赛克之外的处理照片内的敏感信息。

一，如果只有一两张照片，那么用windows自带的画图工具打开照片，然后另存为其他格式的照片，这个时候照片的exif信息都会被删除。

二，如果有很多照片要处理，那么可以安装这个免费的小工具（英文版的） Easy Exif Delete（点击打开百度盘）对照片的exif信息进行批量删除。

使用方法很简单，下载——解压缩——安装——运行软件

①进入软件后（如下图）先单击左侧“Select Images"，在弹出的对话框中选中需要处理的照片，如果照片含有GPS位置、拍照时间等信息，那么会看到 “Exif Found”

②在下面列表中，【 选中】需要处理的照片（单击选中一张，或者在选中一张后，用shift键+左键点击另一张，会批量选中），然后点击“Delete Exif”。处理完成后，会显示“Not Found”。如图。

当然，最好的不留位置信息的办法是，在拍照之前，请把GPS功能关闭！

最后提醒照片当事人：如果你们能看到我的帖子，赶紧搬家吧。。。。你们的信息不会从我这里外泄。。但是网络下载是开放的。。我能得到你们的照片。。别人也可以。。。

本文链接： http://www.yixieshi.com/youqu/15320.html

如何独处是一门艺术

Mon, 02 Sep 2013 10:12:08 CST

如何独处是一门艺术

佚名

（图片来自网络）

朱迪·福特是《单身：满足、充实和独立的艺术》的作者，她是一个异数：“我们独自出生，独自死亡；灵魂深处，我们都是独自一人，”她在给我的一封电邮里如此写道，开头就引用了这些大多数人难以面对的普世真理。

她补充道：“周末独自一人，内心如翻江倒海般千千结；当众演讲的恐惧和这个比起来简直就是愉快了。”福特还说，“比起独自在餐厅用餐，人们去看牙医更勇敢一些”。这点老少通用——她说，很多老人觉得孤独，是“因为他们不再提升内心生活了”。

她为克服寂寞提出了一些实际方法：发挥创造性；鼓励自己“做一些以前从未做过的事情”；对别人承认自己的孤独感，“在空窗期，保持自得”，各个计划之间有空隙，并且提醒自己：“孤独不会杀了我。”她认为：“要完整，得先体会孤寂。”

提及幸福，Rubin写了一本关于此话题的书——她是《时代》杂志畅销书《幸福规划》的作者，并且采取了略微不同的视角。她的着重点并非学习如何快乐独处，而是要明白哪种层面上的社交让你最快乐——这个问题千人千面：“可能没有恋人，但身边围绕着很多人，会让你更快乐，即使你期盼能有一个恋人，”她告诉我，“我觉得，有时候，人们并不是很清楚自己有多需要别人在身边”。

她说：“不要等着环境发生变化后，才追寻自己想要的生活。如果你想去法国，就不要想着‘哦，等我有了男朋友，我就去法国’，或者‘只要结婚，我就修整公寓’，尽享眼下的生活。”这不是让人搁置生活，也不是让人忽略现在拥有的事物。“就像电力，一停电，你就想，‘哦，老天，要是来电，我可太高兴了！’但这并不意味着有电，每天狂喜得手舞足蹈。”

一位社会学家说，人们的不自在很大程度上来自社会期许。“社会观念认可一个人可以做某些事情，如一个人去咖啡厅；但是一个人去高级餐厅就餐或者看演出，就觉得怪怪的。”我们下意识地认为独自做这些事情，等同绝望；由此，自然而然地会产生怪异感。

两年前，塔尼亚·大维斯是视频《如何单身》的主笔，她还写了关于独自“自由”的诗歌——就餐、跳舞、阅读、远足，这些内容开始流传。视频的点击量超过450万：显而易见，她那些贴心和简单的建议在人群中产生了共鸣。正如她在4分钟视频中说的：“社会害怕孤独：好像孤独的心要在地下室里浪费一般；好像人们有一段时间没有约会，就是有毛病一样。但孤独意味着一种自由，轻松呼吸，没有负担；而且，如果会把握，孤独具有疗愈作用。”

独处还要寻找建议，将是一件非常奇怪的事情。如同福特笔下优雅和忧伤的文字：我们独自出生，独自死去，而且“灵魂深处，独自生活”——但这也是生活中诸多诗意反讽之一：只有独处时，我们才是最完整的。

本文来自意林杂志2013年第9期

--------------------------------

意林客户端二维码意林微信二维码

想和意林近距离沟通吗？快加意林微信吧！搜索账号：yilinzazhi，或扫描上方二维码。我们在这里等你哦！

--------------------------------------------------------------------------------------------------

青春就应该这样绽放游戏测试：三国时期谁是你最好的兄弟！！你不得不信的星座秘密

领导力是一门艺术，管理是稳固领导力的方法

Wed, 18 Sep 2013 00:08:51 CST

　　 编者注： Peter Levine 是 Andreessen Horowitz的合伙人，本文是他同美国中尉 John Vines 聊天过后，分享的几个可能对企业家有帮助的观点。

　　 1. 领导能力和管理能力有别

　　“直到最后还愿意帮你做事的，都是信任你或受你启发的人。”伟大的领导者靠的是领导力和直觉。当遇到挑战时，伟大的领导者知道该采取如何的对策，及其对应的后果。

　　Vines 强调说，管理能力和领导能力，尽管相关，但是这两者其实是有很大不同的。领导力是一门艺术，而管理是用来稳固领导力的方法。“领导者通过将自己的判断、方法和智慧运用到所掌握的信息之上来赚钱。如果只是一个纯数据驱动的机构，那直接输入各种算法，等系统自动反馈给你结果就好了。”

　　伟大的管理者不一定能成为伟大的领导者，这个概念引起我深深的共鸣。一个伟大的领导者能够让团队为了共同的目标和信仰随着他出生入死。伟大的领导者也知道如何利用手头的资源产出最好的结果。

　　 2. 自我认知

　　“无论是机构还是个人，要真正认清自己几乎是不可能的。”

　　Vines 描述了他过去的经历，并举例说明无论是个人和机构，要真正的了解自己是非常困难的。他的团队花了大量的时间来了解来自外部的威胁和对手的情况，但对自己却没有一个实时且清晰的了解。因此，他做了大量且痛苦的改变，以确保自己和团队能够竟可能的对自己的有个实时且清楚的认知。

　　领导者要对自己和公司有一个清晰的认知，这一点对于优秀的领导者来说至关重要。我经常会看到一些活在自己空气里的 CEO 和领导者，领导者需要不断的提高自我意识，对个人以及公司的全局有个清晰和准确的了解。

　　 3. 预判风险能够防范于未然，但你很难做到面面俱到

　　Vines 表示曾经为了一个任务花了非常多时间来评估风险。只是要考虑到所有情况是很难的，有时候花了很多时间做计划，结果碰到一个突发事件，然后接下的事情都会跟着改变。

　　这种现象现象在公司中也非常普遍，他们通常喜欢不断的在办公室里做着各种计划，但因为突发事件，之后又不得不做出改变。如此，之前所投入的时间和人力都付诸东流。做计划自然没错，但领导者要时刻准备着应对突发的问题。

　　 4. 机构越大越复杂，领导者需要花”人“身上的时间就应该越多

　　随着机构越来越大，Vines 能够同每个人在一起的时间也就越少。尽管如此，他还是会将大部分的时间花在同其他领导层的交流沟通上，确保所有人都拥有共同的愿景和目标。

　　“我认为领导力应该是“时刻关注，但不要插手”(eyes on, hands off)”。因此，Vines 经常会召开高层视频会议，讨论宏观层面的方向和战略。他表示：“只要一个机构有了明确的目标，中层的人便会想出对应的实践策略。”而一旦他们理解了行动背后的想法和逻辑，命令其实不用一级一级传达。

　　作为一个企业家，你的直觉可能是：在公司壮大时，你需要花更多的时间做自己擅长的事情。但我的建议是，与其话时间在自己的擅长的方面有所建树，倒不如花更多的时间在所有团队身上，帮助他们都变得更好。花更多的时间同你的员工一起，反过来，你在员工和公司心中也会变成一个伟大的领导者，而不局限于做一个微观的管理者。

　　 自重与自责

　　我同 Vines 呆在一起的时间，让我对企业家和军人身上的相似的领袖气质有了更加清晰的认识。Vines 最后说：“如果你每天对着镜子，能够对自己说：' 我已经竭尽权利将风险降到最低了 '，你就不会感到内疚和自责。但如果出了什么茬子，纯粹是因为你懒、不够认真，那你也要为自己的过失付出代价。”

本文链接： http://www.yixieshi.com/zhichang/14490.html

iOS特辑：那些精美优雅的艺术品应用（上）

Thu, 20 Dec 2012 14:49:50 CST

在这个信息泛滥的资讯时代里，相信苹果商店里的那些应用程序都已经被报道得差不多了，比如说《几大实用APP》、《热门游戏排行榜》，包括之前咱们最科技还报道过《2012年苹果应用商店精选榜》。今天小编就从一个很别致的角度筛选出众多应用里隐藏的艺术品，看看那些精美优雅惹人爱的玲珑应用。

这里的“精美”和“优雅”应该是指整体的感受，这种感受既包括视觉，也包括功能和整个交互流程。另外，iOS是一个整体非常注重设计且设计质量非常高的平台，所以在这样一个平台上判定优秀的标准也应该更高（仅仅以界面设计来评判似乎已经没有结果了）。

Path

iOS特辑：那些精美优雅的艺术品应用（上）

手机端熟人社交应用 Path设计出众UI精美，获过豌豆荚设计奖，貌似也成为了最近”被借鉴”最多的手机应用。所谓熟人社交，就是限制好友数量，让你不得不拒绝一些不那么亲密的人。旨在为用户提供一款在密友之间进行照片、心情、地址等信息分享的手机应用，让您体验这款非传统社交应用带来的乐趣，全新、易用并且极炫的交互方式得到各种类型玩家的赞叹，再次刮起社交应用的创新之风。

看点：精美的界面设计，创新的交互方式和独特的产品理念，创造了一批非常忠实的用户。

Twitter for iPad

Twitter for iPad应用利用iPad平板电脑的流体触摸界面，让用户无需打开、关闭窗口，也无需点击按键，就可以自然、快速的获得大量信息。Twitter for iPad应用将允许Twitter用户发送和接收Twitter信息，并打开有关网络内容的链接。除此之外，其还允许用户手写输入信息，并能在单独窗口收看任意相关内容。

看点：非常精美的界面（在iOS上你会发现“精美的界面”是一件如此平常的事情），创新的左右折叠层级关系和交互方式。

Convertbot

iOS特辑：那些精美优雅的艺术品应用（上）

Convertbot是一款iPhone/iPod Touch上的单位转换程序。类似的程序有很多，功能上大致类似，包括长度，重量，体积，货币等等不同单位之间的换算圆盘的转动触控可以从列表中进行快速地选择，相比上下或者左右按键来不知要方便迅捷多少。另外按键的布置呈圆周排列，仅用一个大拇指便可以用最短的移动距离来实现所有的操控，实属经典。

看点：把易用性设计的标准发挥的淋漓尽致，外观优雅，功能简易，操作人性化所采用的圆盘式触控设计更加别具匠心。

Piictu

Piictu的主界面包含三个标签：跟随的主题、热门主题、最新主题，其本质是用图片聊天，作为一款图片分享软件，Piictu于其他同类软件不同点在于，Piictu通过一个特定的主题和一系列对话来进行照片分享。在相应主题下进行互动，其实也就是将照片的主题分类，让用户有选择性的发布图片。

看点：连谷歌都要Copy的精美界面设计，创新的界面元素，创新的图片分享模式，很好的前景。

Weightbot

iOS特辑：那些精美优雅的艺术品应用（上）

Weightbot是一个适用于iPhone和iPod Touch的简单小软件，也可称为称“重量跟踪机器人”。Weightbot可以用来长时间跟踪用户的体重，其用户界面相当漂亮，整个使用过程也很愉快。所以尽管时时关注自己的体重是一件很乏味的事情，但是Weightbot却可以令这件事变得更加有趣而炫酷，实在有化腐朽为神奇之功效。

看点：非常简单、有效且有益于管理自己体重，自动汇集成图表样式，让使用者有一个直观的了解。

Gowalla

Gowalla提供基于地理位置的服务，让用户知道自己朋友的所在位置，用户可以与朋友、家人分享所见所闻，发现新的地方、活动和旅行线路。另外Gowalla还提供商家、竞选和组织以独特的方式赢得忠诚度，拓展受众面，并建立难忘的体验。

看点：界面风格大胆，每一个界面元素都非常精美，交互过程流畅，教科书级别的色彩运用。

本文由最科技邬云连整编，转载请注明出处： http://www.zuitech.com/22606.html

最科技为你推荐：
盘点2012年最值得报道的那些iOS应用	为iOS 6准备的5大地图应用程序	苹果发布iOS 6.0.2升级修复Wi-Fi问题	iOS Cheddar：傲视一切任务管理应用	iOS应用程序：让我们跟“分数”说“so easy”
无觅

网络视觉艺术大观

Thu, 28 Feb 2013 16:07:30 CST

1822年查尔斯·巴比奇（Charles Babbage）发明了第一台计算机（差分机），宣告了新一轮信息革命的开始。也许连巴比奇自己都没想到，计算机的问世会如狂风暴雨一般，几乎改变了未来200年间人们的生活方式。到如今，计算机已成为了人们工作、学习、生活等方面不可或缺的工具，如同人类的左膀右臂一般，舍之不去。

艺术，作为人类的高级情感需求，几乎充斥着世界的每个角落，从古至今皆是如此，计算机也不例外。从计算机图形操作界面发明那天起，网络视觉艺术便随之诞生，并在之后的几十年间一直伴其左右，不断变化，不断发展。如同其他艺术流派一样，网络视觉艺术有他自己的轨迹，也有属于他自己的发展历史。艺术的发展跟时代的发展是密不可分的，网络视觉艺术的每一次创新也几乎都伴随着一次计算机技术的变革，每一种艺术风格也都是应时代而生，因此必然有其适用环境和局限性。网络视觉设计师在应用每一种风格的时候，必须了解风格的前世今生以及其背后的故事，只有这样，艺术与功能才能相得益彰，而不至让视觉沦为表面，变得平庸。

一、网络视觉艺术发展史概览

200年，让美国从荒蛮土著变成了世界霸主，也让计算机从原始萌芽发展到如日中天。历史总是让人兴奋而感慨，兴奋每一件新事物的崛起，感慨万物终将衰亡。想来我们是无缘见到互联网技术的终点了，庆幸的是我们经历了他的成长与繁华，同样，我们也见证了网络视觉艺术的发展。而作为设计师，我们正书写着网络视觉艺术的历史，既是要创造未来，那便得先了解过去。

1.1 网络视觉艺术的起源

如前面所说，网络视觉艺术的每一次变革都是起源于技术的变革。对于PC业界来说，最重要的一项发明也许是1981年IBM PC的推出，但对于网络视觉艺术来说，最具革命性的一次创新应该是1984年苹果Macintosh的发布，因为Macintosh首次实现了图形界面操作系统，并且第一次让个人计算机具备了多媒体处理能力，这为网络视觉艺术设计提供了最基础的平台。

图1.1.1：Apple Macintosh

另一个具有同样划时代意义的发明是Internet，这个萌生于1969年美国军方（Arpanet）、90年代初普及到全世界的网络，让我们今天做的一切成为可能。也正是基于图形界面和Internet，网络视觉艺术才真正产生。

然而网络视觉艺术对于当时的设计师来说仍然只是一块看得见、吃不着的饼，虽然平台已经成型，但是缺少设计的工具和技术支持，所以很多当时的界面在如今看来显得比较粗糙。1991年8月，Tim Berners-Lee发布了史上第一个网站，这个网站是由纯文本构成的，目的是试图告诉人们什么是互联网。

图1.1.2：第一个网页（1992）

1994年，万维网联盟形成（W3C），他们将html确立为网页的标准标记语言。早期的Html能够实现一些基本的标签，如标题（<h1>，<h2>…）、段落（<p>）以及图片（<img>）等，这些标签能够让网页展示基本的信息，也能实现基本的排版布局。值得一提的是，当时的页面虽然简陋粗糙，但却总是能清晰地提供给用户有价值的信息。尽管如今的设计华丽而多变，尽管我们每天高呼用户体验，但很多人却总是连这些最基本的设计宗旨都不遵守。

图1.1.3：Yahoo!（1996）

图1.1.4：Altavista（1996）

随后表格（Table）布局的出现让设计有了较大的进步，同时期一些所见即所得的设计软件的出现也让这项技术变得相对容易。

图1.1.5：Yahoo!（2002）

图1.1.6：Altavista（2002）

从某种程度上来说，这个时期是网络艺术设计与功能结合的较好的一个时期，通过表格布局，设计师能够实现比较漂亮和规整的布局，同时限于当时的技术，不会有太多的视觉元素干扰内容，信息的可读性非常强。著名用户体验书籍《don’t make me think》就是Steve Krug于2000年编写的，这本书里讲到的设计理念直到今天仍然非常适用。

从第一张网页的诞生到表格布局的风靡，这个阶段我们可以认为是网络视觉艺术的萌芽期或者发源期，网络视觉的基础和核心在这个阶段基本成型。接下来的几年间，网络视觉艺术的发展速度则有些超乎想象，风起云涌的江湖时代正在来临。

1.2 网络视觉艺术的发展

在这个群雄争霸的时期，首先崛起的当是Flash技术，Flash出生于1996年，最初被称为 FutureSplash Animator，然后是 Macromedia Flash，后来被Adobe公司收购，改名 Adobe Flash。Flash让动态交互网页成为可能，一时间各种网页动画效果五花八门，层出不穷，设计师们憋了好久的创意集体爆发，且这一潮流经久不衰。

到21世纪初，flash的一大竞争对手登上了舞台，它就是CSS（Cascading Style Sheet），其实CSS 1早在1996年就诞生了，只是一直被忽视，直到21世纪初才真正被人们了解和接受。CSS2.x具备太多flash所不具备的优势，比如内容与表现分离、网页文件体积小等，因此很快被世人青睐。而2004年web2.0的诞生无疑让CSS更加炙手可热，一时间，以HTML+CSS为核心表现手段的web2.0风格风生水起，同时期Javascript脚本语言等弥补了CSS在动态交互方面的不足，让这场战局变得更加有趣。让我们一起来欣赏一下以Flash、Html4.01/XHtml+CSS2、Javascript等技术为核心的网页作品：

Flash篇

图1.2.1 2Advanced

知名交互设计公司2Advanced的网站首页，相信很多人都知道这个设计团队，他们每一次首页的改版都设计的非常炫，而且细节十足，绝对是flash设计师参考学习的典范。

图1.2.2 苹果树下

还记得那些年的苹果树下吗？精致的场景，可爱的画风也可谓风靡一时。

图1.2.3

图1.2.4

使用flash做虚拟现实场景也是非常流行的表现手法，设计师精细的场景表现，几乎可以以假乱真。

CSS篇

图1.2.5 CSS ZEN GARDEN

你可以不记得所有CSS网站，唯独不能忘记CSS ZEN GARDEN,这个网站为用户架构了一个完美符合W3C标准的html结构，设计师可以自己设计CSS文件来修改样式，100%做到内容与表现分离。相信这个网站一定帮到了不少人，至少在很大程度上帮助到了笔者。

图1.2.6 博客风潮

你是否拥有或者曾经拥有一个属于自己的blog？作为web2.0的完美诠释者，博客风靡了相当长一段时间，而强大的博客程序Wordpress也为广大blogger提供了一个非常好的平台，可以说WP成就了一个独立的CSS风格。直到twitter的出现，博客的统治地位才被掀翻。

图1.2.7 水晶图标

这张图是否能让你想起一个时代，一个水晶的时代？21世纪初的几年间，伴随着flash的日趋强大，水晶风格的设计相当流行，不过没过多久，人们就腻味了这种过于华丽的风格，随即将其打入冷宫。

这就是Flash与CSS2.x时期的主流设计，是否有种华丽丽的感觉？然而人们没有注意到的是，在这种繁华的背后，一股暗流正在悄然涌动，那就是移动互联（Mobile Internet），当时的人们可能做梦也没想到，移动互联将在未来短短的几年间颠覆互联网的格局。这一变化发生在2007-2008年，当时3G技术开始流行，各家手机生厂商陆续投入3G手机的研发。2007年6月29日，第一代iPhone上市，Apple发布的这款手机让手机行业发生了天翻地覆的变化，甚至让曾经风风火火的Motorola最后不得不投靠google。

图1.2.8 iphone 5

伴随着3G技术和3G设备的成熟，一种被称为UI风格的设计形式日趋主流，这种风格最初是用于移动界面或者电脑软件，后来被迁移到了Web端。

图1.2.9 手机UI界面

图1.2.10 软件UI界面

图1.2.10 UI风格Web界面

UI风格主要是通过很强列的质感来表现内容，这对触摸界面来说非常有优势，能带给用户很好的指尖操作体验。

2001-2010这十年网络视觉的江湖风生水起，群雄争霸，这个时期可以归结为网络视觉艺术的发展期，相信我们多多少少都有亲身经历，而我们正在谱写的，则是网络视觉艺术的第三个阶段。

1.3 网络视觉艺术的现状

一段喧嚣过后总是一段平静，经历了这么长时间的浮华，人们渐渐累了，于是简约成了大多数人的追求，人们开始思考哪些是必须的，哪些是完全不必要的？有没有更简单的表达问题的方法？

人们再也受不了曾经UI风格、水晶风格、写实风格以及酷炫flash的华丽，那种甜到腻的感觉让大家开始反胃。因此设计师们开始做减法，首先创造了微质感风格，微质感是对之前时期的良好过渡，让人们对即将到来的其他风格有一个缓冲过程。

图1.3.1 微质感风格web界面

顾名思义，微质感是对质感轻微的表现，一方面保留了质感纹理，另一方面弱化了视觉对内容的干扰。很快，微质感就取代了之前的设计形式，成为主流风格。

2008年1月22日，html5草案发布，配合Css3，让世人眼前一亮，不少人甚至认为html5+css3直接宣判了flash的死刑。事实没那么严重，最多也是个死缓，但是其对flash的冲击是相当巨大的，因为html5+css3可以实现很多复杂的动画效果，而且符合W3C标准。在众多html5动画效果里面，有一个表现的特别抢眼，它叫Parallax Scrolling（视觉滚差），它通过控制不同内容的滚动速度，营造出假3D的感觉，刚好赶上当年3D电影流行，因此很快被人们奉为神物。

图1.3.2 Parallax Scrolling页面设计

让人意想不到的是，parallax的流行同时带动了另一个视觉风格的发展，那就是全屏背景设计。Parallax技术通常都会通过全屏效果来表现，以产生更强的冲击力，久而久之，人们发现这种风格不仅能产生很强的冲击力，而且能够用很简洁的方式清晰地表达内容，特别是用在对产品的表现上。因此全屏背景风格成为了近两年的主流风格之一，不论是全屏图片还是全屏色彩，都相当流行。

图1.3.3 全屏图片背景

人们继续寻找着简洁的表达方式，大胆的Microsoft创造了一种极具风险和创新性的风格，叫做Metro，Metro的核心是平面化，将所有页面元素都以平面色块的形式表达出来，摒弃除色彩与内容之外的一切装饰。

图1.3.4 Window Metro界面

Metro的诞生引领了一个新的设计风潮叫做扁平化设计，在经历了微质感的过渡后，扁平化设计很快就被人们接受并成为主流，扁平化设计的优势在于它既能保留较强的表现力，又能有效地降低装饰元素对主题内容的干扰，让用户更好地接收到主体。

图1.3.5 扁平化的QQ网购首页

以上介绍的就是从互联网诞生到现今的主要视觉风格及发展过程，很难想象这么复杂的变迁过程居然就发生在短短的20年时间里，互联网的发展速度实在是有些快的惊人。

二、网络视觉艺术发展规律

2.1 简-繁-简的规律

世间万物的发展都有其特定的规律，网络视觉艺术也不例外，细细看来，我们会发现网络视觉艺术基本上是沿着“简-繁-简”的路径在发展。

在网络视觉艺术发展的初期，由于技术和硬件的局限，网页设计基本停留于“满足功能需求”的阶段，因此我们看到当时的网页都是非常简陋和粗糙的。但随着人们认知的不断发展，审美的需求也在不断提高，人们受够了这些“简单而丑陋”的页面，他们开始想：如果网页能动起来多好？如果我能做一个虚拟的城市多好？…商家也在想，如果我能满足他们这些需求，利润岂可估量？于是乎，开发者们不得不想尽办法来满足人们这些“苛刻”需求。终于有一天，他们做到了，他们带来了flash、css、javascript等先进技术，让人们的梦想成为现实。那一刻，人们先前所预谋的各种场景都接二连三地被表现了出来，设计师们充分发挥着自己的想象力，把网页设计的尽可能复杂，尽可能炫目，尽可能与众不同。苛刻的人们充分体会到了设计师们的强大表现力，这甚至带动了整个设计师行业的飞速发展，一时间，各种网页设计培训班、flash培训班等如雨后春笋般发展起来，盛况空前。然而渐渐地，就像吃巧克力一样，人们腻味了，他们开始反思：我一定要用一个金碧辉煌的3D大厅设计来体现我们酒店的高档吗？我一定要用一个交互复杂，酷炫夺目的动画来体现我的专业吗？…是否有更简单的办法？设计师们开始简化，开始沉淀，那些华而不实的元素渐渐被抛弃，而那些关键核心的元素则得以保留并强化，有些人强化了质感，有些人强化了内容，有些人强化了交互，这些设计方法共同筑成了一个风格简约、表现力强的时期，也就是我们现在正在经历的时期。

到此，网络视觉艺术“简-繁-简”的发展路径基本形成，有人可能会问，那网络视觉今后会沿着怎样一个路径发展呢？我们先来分析两个相似的例子。

2.2 不仅仅是网络视觉艺术的规律

“简-繁-简“的发展规律不仅仅适用于网络视觉艺术，纵观整个世界艺术发展史，我们会发现古今艺术的发展同样符合这一规律。在艺术发展的初期（从人类史前时期到古埃及时期），绘画或雕塑都非常粗糙简陋，因为当时人们做这些“艺术创作”的初衷只是为了实现某些功能，比如教育、祭祀等，没有考虑太多美学层面的东西。

图2.2.1 法国拉斯科洞窟岩画

图2.2.2 阿门哈特的石碑

到古典时期，雕塑和绘画开始被赋予更多美学的含义，这一时期的艺术品都是精雕细琢，非常精致。限于当时人们的认知，艺术作品基本上都是以现实为参考。

图2.2.3 拉奥孔

这一创作理念在接下来的文艺复兴时期得到了进一步升华，为了让作品更加拟真，大师们开始研究材质、比例、色彩等等，以达芬奇、米开朗琪罗和拉斐尔为代表的文艺复兴艺术家开创了古典艺术最辉煌的时期。

图2.2.4 蒙娜丽莎的微笑

到16世纪后期，文艺复兴的古典风格仍然备受世人尊崇，样式主义（学院派、卡拉瓦乔主义、巴洛克）主要也是对文艺复兴的传承。

图2.2.5 宫女

真正将古典风格变得“甜到腻”的当属洛可可风格，洛可可主要表现当时上流社会的享乐、奢华及爱欲交织，而在表现元素上则过多使用曲线，因此作品展现出来的效果是浮华、繁琐和矫揉造作。

图2.2.6 洛可可建筑

洛可可的糜烂终究是引起了反感，新古典主义的产生就是对洛可可的终结，在表现形式上，新古典主义很接近古典主义，从另一个角度也可以说是对洛可可的简化表现。

图2.2.7 赫拉斯的宣誓

以洛可可为分界，往下的艺术流派开始变化和沉淀，一方面是古典艺术已经无法超越，艺术家必须朝另外的方向发展，另一方面由于当时工商业的发展，社会节奏变快，人们对复杂事物的接受度在降低，但最重要的一点原因，是摄影技术的发明，这几乎宣判了古典艺术的死刑。在这时期众多艺术流派中，以塞尚、梵高、高更为代表的后印象主义是最具历史意义的，因为他们不光是在表现手法上创新，更重要的是在创作思想上颠覆了以往所有的流派。他们不再重点表现绘画内容的思想，而是表现创作者的思想。

图2.2.8 星夜

再往后的艺术流派变得异常繁多，艺术家们从各个角度去尝试变化，如抽象主义、立体主义、极简主义和波普艺术等，艺术的元素被分离，有的保留色彩，有的保留形体，但艺术终归变得纯粹而简约，经过几千年的发展沉淀，最终留下的，是艺术中最精华的部分。

图2.2.9 毕加索作品

图2.2.10 蒙德里安作品

图2.2.11 极简风格海报

纵观世界艺术发展史，简-繁-简的思路非常明晰，而如果我们放眼世间万物，会发现这个规律无处不在，比如说人一生的发展，婴幼儿时期对世界处于未知状态，因此行为思想很简单，到童年、青年时期，我们对世界的了解程度加深，好奇心变强，因此行为表现会很丰富，喜欢挑战，喜欢冒险、尝试新事物，等到中年时期，我们渐渐厌倦、疲惫和经验丰富，不再像年轻时候那么冲动，我们遇事三思而后行，行为冷静，我们在这个时期会渐渐沉淀，一直到老年，看尽世间繁华，内心归于平淡，回归简单的生活。

但是这个过程中有一点要搞清楚，那就是前期的简跟后期的简虽然很像，但是却有本质的区别，比如我们婴儿时期每天的生活是吃饭睡觉，老年时期也是吃饭睡觉，但前者是因为我们只会吃饭睡觉，而后者是因为我们只想吃饭睡觉，后者是经过多年的沉淀之后，找到一种最适合自己的生活方式。网页视觉也是如此，早期的简可以说是简陋，而后期的简是简约，每个人都能设计出简陋的东西，但很少人能真正做出简约的东西。只有对设计艺术很熟悉，尝试过很多不同的设计方式的大家，才知道如何从众多网页设计元素中提炼出最核心、最本质的部分，设计出真正简约的作品。

三、从规律中得到的启示

启示一简约、沉淀—未来几年的趋势

当前的网络视觉艺术已经从简陋经过繁华发展到了沉淀、简约的阶段，结合国内用户的平均认知水平，这个阶段应该还会持续很久，直到某天用户能够接受极简风格。我理解的极简风格就是页面里除了内容本身外没有多余的元素，通过很好的版式布局，达到内容突出、情感丰富、品牌风格明显的效果。因此要实现极简风格，除了用户认知以外，内容本身的表现力和感染力也很重要，目前国内网络视觉普遍还达不到这个要求，现阶段还需借助一些辅助元素，比如色彩、质感等来加强表现力。

启示二简约非是一蹴而就

刚刚讲到了网络视觉艺术的发展规律，讲到简陋和简约的区别，那我们在学习的时候也需要注意，用岳不群的话说，所谓凡事欲速则不达,练武之人讲究循序渐进…如果设计师不去接触、学习各种表现手法，不去了解历史，不去经历“繁”的环节，是不可能做出简约的作品的，往往最终表现出来的只是简陋而已。

启示三因地制宜，不要对流行趋之若鹜

经常接触到一些人，他们只管目前流行什么风格，就搬到自己的平台上，根本不顾这种风格跟自己的产品、用户是否相符。一方面，流行的东西我们确实应该敏感，不然我们的作品就容易落伍，变得老土，但另一方面，我们在使用流行元素时一定要分析自己的定位、自己当前的发展阶段，综合考虑，才能做出真正优秀的作品。

简简单单几千字，写的不尽周到详实，只是希望通过对网络视觉艺术的终结和简单分析，能够给予大家以启发，时间仓促，若有不实之处，欢迎批评指正。

网友纠错及补充:

来自Kinsey____(微博: http://weibo.com/536850568):

纠正一段历史：图形界面最早不是苹果发明的，而是施乐的产品奥托（Alto），以下引用

“这仍然是一个非常经典的故事。20多年前，在Macintosh和Windows PC都没有诞生之前，甚至连MITS Altair都没有问世，便有了首台基于图形界面的个人电脑Alto。这台电脑由施乐帕罗奥多研究中心(Xerox PARC)开发，不仅提供鼠标和以太网，并且已经配备了“所见即所得”的文本处理器。但在1973年，个人电脑市场还并不存在，所以施乐并不知道应当如何处理Alto。施乐生产了几千台Alto并将其分发到各大高校。据说，乔布斯于1979年造访施乐帕罗奥多研究中心时看到了Alto，并将Alto的许多功能整合到了苹果Lisa和Mac电脑中。不久后，施乐意识到自己的错误，并开始推广Xerox Star，这是一款基于Alto的技术开发而来的图形化工作站。但推广力度不大，且为时已晚。”

另外，Kinsey____提出网络视觉的发展是一个”一直追求接近现实的拟物设计”的过程,”由于技术的限制人们以前见不到那么写实的风格而现在的显示技术早已完全能够满足这种极致拟物的要求人们见的多了就腻了于是微软开始追求另一种极致即极简”，这种表述比我文章里的“繁”更加精确一些，感谢Kinsey____的指正。

赞！web设计之路！网络视觉艺术发展史概览

Thu, 28 Feb 2013 18:56:01 CST

“作为设计师，这篇文章一定要看看，非常棒的总结！帮您理清web视觉的发展历程，强力推荐！”
1822年查尔斯·巴比奇（Charles Babbage）发明了第一台计算机（差分机），宣告了新一轮信息革命的开始。也许连巴比奇自己都没想到，计算机的问世会如狂风暴雨一般，几乎改变了未来 200年间人们的生活方式。到如今，计算机已成为了人们工作、学习、生活等方面不可或缺的工具，如同人类的左膀右臂一般，舍之不去。

推荐关注作者微博 @TANX_谭雄原文： http://tanxdesign.com/?p=84

一、网络视觉艺术发展史概览

1.1 网络视觉艺术的起源

图1.1.1：Apple Macintosh

图1.1.2：第一个网页（1992）

图1.1.3：Yahoo!（1996）

图1.1.4：Altavista（1996）

随后表格（Table）布局的出现让设计有了较大的进步，同时期一些所见即所得的设计软件的出现也让这项技术变得相对容易。

图1.1.5：Yahoo!（2002）

图1.1.6：Altavista（2002）

1.2 网络视觉艺术的发展

到21世纪初，flash的一大竞争对手登上了舞台，它就是CSS（Cascading Style Sheet），其实CSS 1早在1996年就诞生了，只是一直被忽视，直到21世纪初才真正被人们了解和接受。CSS2.x具备太多flash所不具备的优势，比如内容与表现分离、网页文件体积小等，因此很快被世人青睐。而2004年web2.0的诞生无疑让CSS更加炙手可热，一时间，以HTML+CSS为核心表现手段的 web2.0风格风生水起，同时期Javascript脚本语言等弥补了CSS在动态交互方面的不足，让这场战局变得更加有趣。让我们一起来欣赏一下以 Flash、Html4.01/XHtml+CSS2、Javascript等技术为核心的网页作品：

Flash篇

图1.2.1 2Advanced

图1.2.2 苹果树下

还记得那些年的苹果树下吗？精致的场景，可爱的画风也可谓风靡一时。

图1.2.3

图1.2.4

使用flash做虚拟现实场景也是非常流行的表现手法，设计师精细的场景表现，几乎可以以假乱真。

CSS篇

图1.2.5 CSS ZEN GARDEN

图1.2.6 博客风潮

图1.2.7 水晶图标

图1.2.8 iphone 5

伴随着3G技术和3G设备的成熟，一种被称为UI风格的设计形式日趋主流，这种风格最初是用于移动界面或者电脑软件，后来被迁移到了Web端。

图1.2.9 手机UI界面

图1.2.10 软件UI界面

图1.2.10 UI风格Web界面

UI风格主要是通过很强列的质感来表现内容，这对触摸界面来说非常有优势，能带给用户很好的指尖操作体验。

1.3 网络视觉艺术的现状

图1.3.1 微质感风格web界面

2008年1月22日，html5草案发布，配合Css3，让世人眼前一亮，不少人甚至认为html5+css3直接宣判了flash的死刑。事实没那么严重，最多也是个死缓，但是其对flash的冲击是相当巨大的，因为html5+css3可以实现很多复杂的动画效果，而且符合W3C标准。在众多 html5动画效果里面，有一个表现的特别抢眼，它叫Parallax Scrolling（视觉滚差），它通过控制不同内容的滚动速度，营造出假3D的感觉，刚好赶上当年3D电影流行，因此很快被人们奉为神物。

图1.3.2 Parallax Scrolling页面设计

图1.3.3 全屏图片背景

图1.3.4 Window Metro界面

图1.3.5 扁平化的QQ网购首页

二、网络视觉艺术发展规律

2.1 简-繁-简的规律

世间万物的发展都有其特定的规律，网络视觉艺术也不例外，细细看来，我们会发现网络视觉艺术基本上是沿着“简-繁-简”的路径在发展。

到此，网络视觉艺术“简-繁-简”的发展路径基本形成，有人可能会问，那网络视觉今后会沿着怎样一个路径发展呢？我们先来分析两个相似的例子。

2.2 不仅仅是网络视觉艺术的规律

图2.2.1 法国拉斯科洞窟岩画

图2.2.2 阿门哈特的石碑

图2.2.3 拉奥孔

图2.2.4 蒙娜丽莎的微笑

到16世纪后期，文艺复兴的古典风格仍然备受世人尊崇，样式主义（学院派、卡拉瓦乔主义、巴洛克）主要也是对文艺复兴的传承。

图2.2.5 宫女

图2.2.6 洛可可建筑

图2.2.7 赫拉斯的宣誓

图2.2.8 星夜

图2.2.9 毕加索作品

图2.2.10 蒙德里安作品

图2.2.11 极简风格海报

三、从规律中得到的启示

启示一简约、沉淀—未来几年的趋势

启示二简约非是一蹴而就

启示三因地制宜，不要对流行趋之若鹜

本文系作者： tanxdesign辛苦原创，转载请注明出处

优设哥向您推荐：
推荐：响应式网页设计与应用	WEB设计中的排版	如何在设计中建立良好的视觉层级	界面设计中需要注意的小细节	产品设计流程
无觅

编码指南：寻找科学中的艺术

Sun, 05 Jan 2014 08:25:36 CST

本文翻译自《Coding Guidelines: Finding the Art in the Science》

作者
Robert Green, Henry Ledgard

日期
2011/11/02

好代码和伟大的代码的区别是什么？

计算机科学既是科学也是艺术。
它科学的一面涵盖了从计算理论、算法研究到代码设计和编程架构。
然而，当提及实现时，艺术的光芒、微妙的风格以及高超的技艺组合将好代码和伟大的代码区分开来。

像艺术一样，代码同时是主观的和非主观的。
编码非主观的方面就包括一些创建好代码必须遵循的“硬”规范：设计模式，项目结构，公共库的使用等等。
虽然这些概念奠定了高质量、可维护代码的基础，但正是程序员间不同的技术与工具的细微差别——对齐方式、命名、空格使用、语境利用、语法高亮和IDE的选择——真正使代码清晰、可维护和容易理解，同时也使得代码更好的表达了其意图、功能和用法。

不错的代码和伟大的代码有所区别，是因为每个人都有基于他（或她）自己好（或坏）的习惯形成的特定的编码风格喜好。
任何人都可以遵循设计模式或其他一些“硬”规范来编写代码，但伟大的程序员会以自己的方式来填充代码的细节，使代码变得清晰、简洁、易懂。
这很重要，正如每个人都可以从一件艺术品中体会到独一无二的意义，不管代码的架构和设计怎样，每个开发者或代码阅读者可能也会从代码的命名和其他约定习俗中推断出不同的含义。

从另一个角度来看，编程可能也可以被看作是一种“加密”形式。
程序员以各种方式设计问题的解决方案并且将它们加密为程序及其附属文件。
数月或数年后，需要改变时，一个新的程序员必须解密当时解决方案。
这可不是一个让人羡慕的任务，因为它总被归咎于在项目“加密”时期没有清晰的表达。
当必要的关键信息存在时解密信息其实很简单，所以特别关注代码自身的表达是理解旧代码的关键。

为了解决这个问题，有些作品定义了针对整个编程语言的单一编码标准，而另一些则勉强接受了一些命名约定，只要这些约定保持一致。
通常来说，漂亮的代码被定义为：易读、聚焦、可测试和优雅的。
更极端的例子是整个语言的发明建立在一系列完美的理念上，例如 Ruby 或 Python。
Ruby 强调简洁、简单、灵活及平衡。
Python 背后的原则在《The Zen of Python》一书中有清晰的描述，它聚焦在漂亮、简单、可读和可靠性。

我们针对这个问题的解决办法是开发了一套编码指南系统。
虽然这些指南来自学术界，但是它们对从业者同样有用。
这些指南基于一些广泛的原则，这些原则体现了表达沟通的基本原理，并将编码惯例的观念提到了更高的高度。
应用这些惯例有助于提升代码库的可持续性。
本文就着眼于这些基本原则。

这里有一个没有考虑的方面是语法高亮和IDE。
一方面使得代码更容易阅读（因为语法高亮，代码折叠等）同时更容易管理（例如，快速查找，重构函数、变量等），我们的指南是相对语法颜色和IDE中立的。
它们反应了在任意的设定下写代码的基本且重要的原则。
虽然，IDE能以某种形式帮助提升可读性和可理解性，但是基于这些工具的功能并不是标准的（例如，想想Visual Studio、Eclipse、和VIM下的这些不同功能）。
同样的，语法高亮的环境差异很大，而且可以很容易的改变以适应个人偏好。
下列原则的目标是建立一个独立于IDE的良好编程的基础。

1. 将一段程序当作一个表格
在最近的 ACM Queue 发表的文章上，Poul-Henning Kamp 提出了一个迷人观点：很多编程语言的风格源自于 ASCII 字符集和基于打字机的终端。
编程语言没有利用现代设备的图形属性和选项。
虽然代码是按照清晰的英语语法格式编写的，但它并不是英文句子。
事实上，它更像数学和表格。

这是一个影响深远的原则。
首先，它谈及的是字体的使用。
对于程序代码不要使用可变宽（比例）字体，因为代码不是文本。
定宽字体（例如，Courier 和 Data Gothic）看起来更好且更容易对齐代码。
变宽字体妨碍代码对齐，更重要的是，它让代码看起来更不像代码。

接下来我们进一步思考程序是一系列动作的组合序列，或者是一种高层次的算法，每一段代码都可以被认为是一种图、表和菜单。
下图1、2、3使用了垂直对齐来表现对称性。
这是一种有力的表达沟通方式。

当一行长代码溢出到多行时，我们建议打破并重排代码。如下：

  
participant newEntry = new participant (id, name, address1, address2, city,
state, zip, phone, email);

使用下面的方式替代

  
participant newEntry = new participant (id, name, address1, address2,
    city, state, zip, phone, email);
    
participant newEntry = new participant(id, name, address1, address2, city,
    state, zip, phone, email);

2. 让简单的英语成为你的向导
程序员为某样东西创造了一个名字，名字包含了其使用的全部知识，通常许多名字只在人们知道其代表的含义时才有意义。
然而，程序员有这样一个问题：基于概念来创造名字。
但真正的挑战正好相反：从名字推导出概念！
这正是程序阅读者遭遇的问题。

考虑这个来自公共 C++ 头文件<iostream.h>的简单变量名 sputn。
一个缺乏经验或不熟悉的程序员可能就会遭遇一系列的困惑，例如：这是一个整数？还是个指针？一个数组或结构体？一个方法或变量
是否 sp 表示一个保存指针（saved pointer）？是否 sput 表示一个操作执行 n 次？
你是读作 sputn 或 s-putn 或 sput-n 或 s-put-n？

我们提倡命名基于传统的英语用法——特别是，简单、正式、缩略的英语用法。
考虑下面一些更具体的指南：
- 变量和类应是名词或名词短语。
- 类名像是集合名词。
- 变量名像是专有名词。
- 过程名应是动词或动词短语。
- 方法的返回值通常应是名词或名词短语。
- 布尔值应是形容词。
- 对于复合名，保留传统的英语语法。
- 尽量让名字可发音。
以上原则的一些例子如图4所示：

如下这个例子，有一个小而有趣的问题：

  
numFiles = countFiles(directory);

countFiles 是一个不错的名字，但却不是最理想的名字，因为它是一个动词。
动词被保留用作针对变量无副作用的过程调用。
对于针对变量无副作用的函数调用采用名词或名词短语。
人们通常不说：

  
Y = computeSine(X); 
milesDriven = computeDistance(location1, location2);

而是

  
Y = sine(X); or
milesDriven = Distance(location1, location2);

因此我们建议采用 fileCount 来稍稍改进。

  
numFiles = fileCount(directory);

更重要的是，这强制了一个通用的原则：动词表示过程，名词或形容词表示函数。

3. 依赖上下文来简化代码
如果其他一切相同，那么更短的代码通常更好。
例如，用作索引值的本地变量通常被命名为 i、j、k 等。
用在循环中每一行的数组索引没有比 i 更合适的。
使用 index 或 elementNumber 这样额外描述的变量掩盖了计算的细节。
一个很少使用的变量可能更值得一个长的名字：例如，MaxPhysicalAddr。
当一个变量名很长而又到处出现，很快就变得很难搞明白到底发生了什么。
一个变量的名字通常可以通过其使用的上下文来缩短——例如，在一个栈的实现中，使用变量 Store 而非 StackStore。

4. 使用空白表现结构
在书面和口头沟通时可能达到了高层次的清晰，但若没有非言语的亲身接触和倾向性的暗示则常常缺乏想要表达的含义。
一个人的身体语言有助于阐明他们说出的话。
类似的场景下，程序员则依赖代码间的空白——间接来说——来表达逻辑、意图和理解。

一个例子是在不同概念的代码段之间使用空白行。
空白行可以提升可读性，是因为它们从逻辑上将代码的不同部分区分开来，并且提供了文学写作上段落分行的等价物。
适合使用空白行的地方有：
- 当从预处理指令到代码时
- 类和结构体声明附近
- 一定长度的函数定义附近
- 一定长度的一组逻辑上相互关联的语句附近
- 在声明和可执行语句之间

考虑下图6中的代码列表。
在单独一行语句中，单独的空白也应当被用来展示逻辑结构。
在一行中，有策略的使用空白简化了人们阅读分析代码的难度。
至少，空白应该用在参数列表的逗号之后和赋值操作符 "=" 以及重定向操作符 ">>" "<<"两边。

另一方面，空白不应当用于一元操作符，例如：一元减"-"，地址符 "&"，间接运算符 "*"，成员访问 "."，递增 "++"，递减"--"。

另外，如果是有意义的话，把两到三个语句放在一行。
此类实践有简化代码的效果，但必须谨慎使用，只有当这样做是明智时才使用它。

5. 让决策结构自我表达
图1所示的 case 语句用法带来一个普遍的观点：非常简单的决策语句可以很简洁的表达，如图7所示的替代代码表现简单，如果可能的话，不要使用括号。

相互互斥的简单条件创建了一种通用形式的 case 语句，这种情况并不少见。
按通常做法，这些语句被写成链式形式，如图8所示。

当然，这些结构可能确实是嵌套的，因而你必须要么使用嵌套的间距或者函数，二中选一。
然而，普遍的观点是：让结构驱动布局，而非编程语言的语法。

在括号之战中，如图9所示的几种风格偏好中，我们不表示强烈支持某一种，但是我们确实强烈的感觉到缩进才是关键，因为正是缩进表达了结构。

6. 聚焦于代码，而非注释
沟通的能力显然是人类经历的方方方面都面临的一个问题。
程序员在编写代码时必须达到清晰、持续和优美的层次。
这意味着专注于代码的清晰性，平衡性，对称性，而不在其长度或注释。
当然这个理念并不意味着支持删除注释或者否定它们的使用以及在适当条件下的重要性，它建议程序员必须明智而审慎的使用注释。
大部分时候，应当专注于开发代码，清楚的传达意图和功能。
这种做法自会减少很多不必要的注释。

7. 讨论
虽然这里给出的指导方针用于教育，它们对工业界也有价值。
使用这些指导方针教出来的学生当其入行后，最有可能使用它们（或类似的）。
为了演示，我们开发了一个例子，针对两种完全不同的风格应用这些指南。
第一种是 Unix 风格。
它非常简洁，常常使用元音删除，在实际的应用中常看到，如操作系统代码。
这并不意味着所有或大多数系统程序员使用这种风格，仅仅是比较常见。
图10展示了一个这种风格的小示例。

我们所说的第二种风格是教科书风格，如图11所示。
再次，这并不是意味着所有或大多数教科书使用这种方式，只是示例中的风格比较常见。
这种风格的重点是学习。
这意味着频繁的注释以及代码很好的展开。
为学习的目的和理解语言的细节，这种风格是很好的。
从实践的角度以及有一定规模的程序角度来看，这种风格并不好，它阻碍使用或阅读。
此外，这种方式使得它很难看到总体设计，如被一棵树挡住而看不到整片森林。

如图12是图10和11所示函数的重构，使用了这里所讨论的指南实现了从学术代码到实际代码之间平滑变迁。
图12中展示了两种代码风格的平衡，更直接的依赖代码自身来清晰的表达意图和功能。
与教科书代码相比，最终的代码更简短紧凑，同时也清晰的传达出了代码的意思、意图和功能。
与 Unix 风格的代码相比，显得稍微长一点，但是代码的意思、意图和功能显得更清晰。

图13在其他环境下举例说明了这些指导原则。
这是一个来自一段复杂程序的函数（10000行），该程序与PHEVs（充电式混合动力车）的动力系统可靠性和能源利用相关。
这个程序就电动汽车当前的输电系统和传动系统之间的关联效应进行了大量的计算。
它尝试使用蒙特卡洛模拟方法（Monte Carlo simulation）来开发一种可靠性评估模型来评估动力系统的可靠性。

如上例所示展示了这些指导原则的价值，有人会反驳说这些指南要求保持代码风格的完整性很耗时，特别是当使用了版本控制系统后。
当面对一些时间很敏感的项目或者是将来不大可能去更新或维护的项目时，这种努力并不值得。
典型的例子如：课业项目、博士论文或者一些临时应用。

然而，如果谈及的代码库有很长的生命周期或者会被其他人更新和维护（例如：一个操作系统、服务器、交互网站或其他有用的应用），那么任何提升代码可读性的改变都很重要，应该花时间来确保代码的可读性和可维护性。
这应是一件值得骄傲的事，和必不可少的功能一样。

参考
略...

致谢
略...

作者：mindfloating 发表于2014-1-5 0:25:36 原文链接

阅读：132 评论：1 查看评论

兰花的欺骗艺术

Sun, 30 Oct 2011 09:56:11 CST

一说到兰花，总能让人想到“高雅、清幽、暗香浮动”，总之是什么好词都往它的脸上贴。不过，你知不知道，在全世界现存的20000多种兰科植物中，有1/3都干着坑蒙拐骗的事情。它们从来不遵守，“我出花蜜，你传粉”这个动物植物社会的经营规范，而是利用靓丽多姿的色彩，或是香甜诱虫的气味将昆虫勾引过来。这些可怜的虫子不仅要帮兰花完成传播花粉的工作，还拿不到分毫工钱。

更让人诧异的是，有些兰花的骗术伎俩在我们看来非常简单，甚至可以用粗劣来形容，但是它们的效果都不错，诱使无数昆虫为兰花义务劳动。这样的结果很难用一般的合作竞争来解释，以至于我们的进化生物学鼻祖——达尔文老先生怎么都不相信兰科植物中混有骗子。

兰科植物究竟有哪些花招能引诱病迫使昆虫就范，这些传粉昆虫是不长记性的糊涂蛋吗？进行欺骗传粉的揽客植物，难道只是为了少给昆虫一点点口粮？如果，昆虫都不上当，这些欺骗性植物又该如何应对呢？随着研究的深入，这些问题的答案都在慢慢地浮出水面。

食色诱饵

“入芝兰之室，久而不闻其香”，我想这间屋子里摆放的肯定不是蕙兰。那种浓烈的香气不管闻多久，仍旧会重重地撞击你的嗅觉神经。

记得一次同我的导师罗毅波先生出野外去贵州考察时，刚走到一座石山的山脚，他就说，“这山上有蕙兰在开花呢”。可是环顾四周，那里有蕙兰的影子。结果，当我们爬到山顶时，果然有一丛绽放的蕙兰，用香甜的气味牵住我们的鼻子。不过，这种香甜的味道显然不是为取悦人类准备的。蕙兰的香气中包含了乙酸乙酯等花朵香气的常用成分，它们是中华蜜蜂寻找食物的常用路标，只是蕙兰的。在随后的观察中，每每发现受到气味引诱的中华蜜蜂像受到酒香勾引的醉汉一样摇摆着冲向蕙兰的花朵。

不过，香味并不是一个精确的信号，怎样让被引诱的蜜蜂乖乖地上勾呢？蕙兰还伪造了酒店的招牌。就是花瓣上那些栗红色的斑点，在我们看来影响花朵美容的斑点却是蜜蜂等昆虫的最爱，因为它们就代表有食物。

[蕙兰 (Cymbidium faberi Rolfe )]

如果你觉得百合花上的斑点有碍纯洁，那就错了，毫不夸张的说，这些斑点的存在才招来了采集花蜜的蜜蜂，完成了传播花粉的过程，促成了百合花的爱情姻缘，这么看来，叫它们爱情斑点也不过分。

于是，这个通用的花蜜标志被蕙兰盗用过来。你可能会想，这样的盗用标志就不会被蜜蜂识破？通常工蜂的生命只有五六个月，每天还要完成高强度的花粉花蜜采集工作，在这种情况下，很难有机会去学会识别复杂的信号。迅速找到食物是蜜蜂生存的根本，连分辨真假的时间都没有，还好大多数植物都会给传粉蜜蜂提供一些花蜜和花粉作为回报。每每看到蜜蜂精准地降落在蕙兰的花瓣上，然后悻悻离去，真是感慨蕙兰手法高明，同情蜜蜂的生活不易。

受骗的不只是中华蜜蜂，在贵州的喀斯特石山上你会碰见同样吝啬的小叶兜兰。它只有一个手法就是颜色-亮黄色的退化雄蕊分外醒目，没有香气，没有斑点，仅仅是黄色就足够了。如同我们看到红色广告牌上大写的“M”(最近被换成黑底了)，就知道有吃的。红色和黄色是人类食物的主色调，而黄色则是成年食蚜蝇(幼虫是吃蚜虫的)的最爱，这带表了花粉的颜色。特别是雌性食蚜蝇对黄色情有独钟，因为它们要从花粉中补充足够的蛋白质才能生儿育女。甚至是涂成黄色的实验圆盘对它们也有强大的吸引力。

[小叶兜兰（Paphiopedilum barbigerum）]

小叶兜兰显然深黯此道，在颜色骗术上做到了极致，只有一个硕大的黄色雄蕊，没有多余的颜色和气味标志了。看到了这个标志的食蚜蝇自然是执着地上前拥抱了，也就心甘情愿地为小叶兜兰做苦力了。

比起这些简单的食物诱惑，性的诱惑似乎更加强烈，也更专业细致一些，毕竟挑选伴侣要比吃喝更挑剔。眉兰将自己的花朵伪装成雌性胡蜂，连胡蜂身上的根根绒毛都在花瓣上伪装了出来。不仅如此，眉兰还在花上“抹”上雌性胡蜂的体香，更让那些来求爱的家伙神魂颠倒，甚至不惜把精液都贡献在了花瓣上。更绝的是，成功受粉的眉兰直接变了一种让胡蜂不爽的气味，从少女体香变成了老奶奶味道，闭门谢客了。

[角蜂眉兰(Ophrys speculum)]

把苦力骗来了，还不算完，一不小心露出马脚，昆虫肯定会头也不回地飞走。骗子兰花早就想到了这点，专门配备了强迫昆虫苦力传粉的装置。

在纹瓣兰的花瓣上会有一些纵向的纵向的条纹向花内延伸。在蜜蜂看来，这些条纹就是将它们引向花蜜的路标，顺着路标走准没错。可惜最终也尝不到一丝甘甜，当它们悻悻离开的时候发现问题来了，本来唇瓣在它们降落时被压下来，寻蜜通道的入口会变得很宽松，随着蜜蜂向前拱，重心位置改变后的花瓣微微抬了起来，把蜜蜂紧紧地夹在唇瓣和蕊柱之间，这时花粉块就会借助粘盘紧紧地贴到它们背上。在经过一番激烈的七扭八歪之后，蜜蜂终于逃出了变狭窄的通道，只是背上已经多了一件货物。在纹瓣兰开花的季节，我们经常能看到背着花粉块的苦力在这骗子花朵间飞来飞去，寻找那口虚无的甘甜。只要它们执着地拱下去，纹瓣兰就没事偷着乐去了。

[纹瓣兰（Cymbidium aloifolium）]

比起纹瓣兰，小叶兜兰的陷阱设计得更为精致。说是陷阱一点都不过分，这个帽盔一样的唇瓣就是为食蚜蝇量身定制的，刚刚不能展开翅膀，也刚刚好不能够到陷阱的边缘。还好这个陷阱里面没有消化液。小叶兜兰不像猪笼草那样血口大开。它要做的只是让食蚜蝇搬运花粉。

如果是把你关在一个有天窗的屋子里，你会怎么想呢？当然是从天窗夺路而逃了。食蚜蝇也是这么想的。这个天窗就在陷阱的背面，当然小叶兜兰是不会让食蚜蝇白白逃走，它们在天窗通道里安装了花粉和柱头，每个从此处逃出的食蚜都要将在上一朵花上装载的花粉抹在柱头上，再从雄蕊处装上新的才能获得自由。有了这些机关，即使骗术略显拙劣，骗子兰花也能搞到传粉的苦力。

不过，拙劣的骗术总有被戳穿的时候。昆虫都精明了，兰花该如何应对呢？

高风险，高收益？！

跟很多传粉生物学家一样，我经常在想，这些招摇撞骗的兰花究竟能得到什么好处呢？难道仅仅是为了省下生产花蜜所需的能量吗？

在后来的观察中，我逐渐发现“节省”并不是一个解释兰花行骗的好理由，毕竟欺骗也是需要代价的。这完全是个赌徒行为，虫子总归会识别出那些有花蜜的植物，何况就像上文提到的，有些兰花的骗术着实低级，昆虫很容易被分辨出来，只要上过一次当，就会远离兰花，珍爱生命去了。每次看见那些，从兜兰里钻出来的食蚜蝇或者熊蜂都顾不上喘口气，只是清理一下翅膀，迅速地逃离这个是非之地了。正是这个原因，干着欺骗活动的兰科植物的结实率都很低，大部分都在10%上下，特别是杓兰（Cypripedium calceolus）的结实率只有2%。

[杓兰（Cypripedium calceolus）]

有的研究人员认为，为了弥补拙劣骗术的不足，欺骗性兰花只能多开花，开大花了——把圈套设得密集一些、醒目一些，总归是要有糊涂虫撞上来的。可是开花也是一件奢侈的事情，就拿硬叶兜兰来说，一个山头可能分布有上千棵植株，但是一年能开花只有百八十朵；即使是在温室里面，好水好土伺候，隔年能开花就已经很不错了，对植物来说开花可是要消耗大量养分的，甚至可以说是“伤筋动骨”的活动。反过来看，杓兰为了2%的结实，让其余98%的花朵来陪着走过场，这也过于大手笔了吧。

在广西北部见到带叶兜兰的密集的花朵瀑布之后，更加深了我对“节约资源说”的怀疑。为了节省花蜜，浪费如此数量的花朵，于情于理都说不过去。这些骗子兰花的身后似乎另有隐情。

要知道，2/3的兰科植物还是选择了给传粉者提供好处。

云南石仙桃就是这样的一种兰花，它们与带叶兜兰和纹瓣兰比邻而居，当然，蜜蜂们更喜欢在云南石仙桃上面的活动很长时间，尽可能地吸掉最后一滴花蜜，它们会在一串花上（一个花序）来回寻觅。表面上看起来，“忠诚”（对花蜜的忠诚）忙碌蜜蜂能更多地为植物传递花粉，传宗接待，云南石仙桃的花蜜也没有白出。然而，事情也并非总是那么愉快。这些在一个花序上来回吮吸的蜜蜂很可能只是把一朵花的花粉从一朵搬到同一花序另一朵上，结果就是造成了石仙桃的“近亲结婚”。如同人类近亲结婚会提高生育畸形后代的风险一样，近亲授粉的花朵产生的后代大多也是孱弱的。而骗子兰花在这点上似乎更加精明。

如果你能仔细观察到一只从从兜兰里钻出来的食蚜蝇或者熊蜂只是清理一下翅膀，迅速地逃离这个是非之地了，就能体会到这些兰花比省去花蜜更远大的谋略。那些带着花粉慌张逃离的昆虫恐怕要飞出不短的距离，才能“捂着胸口”安下心来歇歇脚。如果还有下一次被骗的可能，只能把花粉贡献给距离第一次上当很远很远地方的那株兰花了。于是，狡黠的兰花得到了莫大的好处，长距离的远缘杂交获得了高质量后代。虽然，杂交种子的适应性和生活力还有待进一步检验，目前已经有证据显示，同提供好处的兰花相比，欺骗性兰花的种群之间确实存在更强的基因交流，而那些添加了花蜜的欺骗性兰花则面临着更多地同株授粉，这至少可以比那些在一个花序上自交的兰花有更多地组合的机会。更多的组合意味着更多地选择希望。

看到这里，肯定有读者会问，杂交是好，可是面对2%的结实率，骗子兰花也需要有个艰难的抉择吧，稍有闪失不就全军附魔了。为了提高后代的质量而冒断子绝孙的风险，那可就划不来了。

这个不用担心，兰科植物之所以能选择骗术，很重要的一点就是它有特殊的生殖构造，首先是花粉被打包成块，这样被骗的昆虫在花朵上活动的时候，就会带走大量的花粉，里面的精子足够同相当卵子约会。更让人叫绝的是，兰花会利用黏液、粘盘之类的东西把花粉牢牢地固定在传粉昆虫的背上、头上等“无法挠到的后背处”，这些传粉昆虫想打这些花粉的主意根本没门。当然，等待这些精子的是子房中数量相当的胚珠，两者结合自然会产生海量的种子，一般来说每个成熟的兰花果实里都有上万粒种子。看到这，你大概明白了吧了，骗子兰花就是在进行一场场豪赌，这中间失败很多，但是一旦中彩，开出的往往就是“五百万大奖”了。

进化：骗术升级还是选择“从良”

从传粉者的角度看，同欺骗性兰花打交道可是个高危行为。在野外观察中，我经常看到那些误入带叶兜兰和小叶兜兰陷阱食蚜蝇被活生生地卡死在出口处。也许，它们在生命的最后时刻，也像卖火柴的小女孩那样，眼前飘荡着喷香的花粉和甘甜的花蜜吧。自然界的生存是残酷的，不能精准地识别陷阱，可是有性命之忧的。于是，笨的虫被卡死，从而被自然选择的力量清除了，昆虫群体的识别能力的提高。骗子兰花又该如何应对呢？

最简单的解决办法就是从良，回过头来给传粉者提供花蜜。在进化历史上，这样的情况并不鲜见，比如南非Disa属植物中就有很多这样摇摆的成员。通过分子系统学研究发现，在进化历程中既有从有花蜜变成无花蜜的种类，也有从无花蜜再度提供花蜜的种类。

也有研究者认为，兰花拙劣的骗术，本身就是一种对自身的保护。那些数量有限的几次欺骗，不会让那些呆瓜传粉者灭绝，并且只要能成功骗几次就足够了。于是，像春兰、蕙兰、硬叶兜兰这样的兰花都选择在早春或者冬季开花，先来跟那些无花可采的年轻昆虫亲热一下，也不至于影响呆瓜昆虫的繁殖。从这点来看，这些骗子兰花也算得上是张弛有度了。

当然，也有些骗子兰花要一门心思走到黑了。我们再把目光投向兜兰。像硬叶兜兰和小叶兜兰这样依靠食物信号来欺骗昆虫的种类，得手的机会毕竟有限，结实一般都不会超过20%。于是乎，有些兜兰开发出了更强的损招，那些一个个貌似蚜虫的黑色突起，甚至连根根黑毛都长全了。食蚜蝇妈妈可以拒绝花粉花蜜的诱惑，但是它们却无法抗拒下一代的食物对它们的吸引，每个食蚜蝇妈妈都想为孩子准备好足够的蚜虫，让它们一孵化出来就有足够的蚜虫大吃大嚼。结果就是，很多食蚜蝇妈妈都中了长瓣兜兰的圈套。而长瓣兜兰以90%的结实率傲视由同种食蚜蝇传粉的小叶兜兰。至此，虫和花没有和解，它们的争斗依然要继续下去。

[长瓣兜兰（Paphiopedilum dianthum）]

如果把欺骗性兰科植物发到进化的历史上进行评论，我真不知道该说它是先进，还是落后。毕竟，它们的风险和收益都存在很大的不确定性。当然，我也不是说那些老实本分的兰花就是低等的懦夫，它们的生存技能一样强悍。可以肯定的只有一点，那就是在这个自然界中，并没有十全十美的生存方案，只有适应环境的制胜妙招。

Less is More，简化的插画艺术

Sat, 29 Oct 2011 11:50:15 CST

美国阿肯色州小石城的艺术总监 Matt Owen 除了是个疯狂的电影迷之外，也是一位情迷于“简化”的艺术家，他所创作的一系列电影海报同样也有“Less is More”的化繁为简的魅力。看到这些海报，是否与你的电影印象相一致呢？

点击这里访问他的个人网站。

Susan Kare：为 Mac 设计图标的艺术家

Fri, 25 Nov 2011 20:33:21 CST

1968 年，斯坦福研究所的 Doug Engelbart 演示了计算机图形界面（图标、鼠标和位图图像）的核心概念。这次演示被称为“所有演示之母”。 Engelbart 革命性的观念在 Xerox PARC 获得了进一步的发展。

1979 年，24 岁的乔布斯拜访了 Xerox PARC。这次拜访使他确信图形界面代表着计算机的未来。乔布斯以苹果部分股票换取了 Xerox Alto 图形界面技术的授权。

（乔布斯，1983）

当时，Mac 团队已经看到了家用电脑的巨大市场，艺术家、音乐家、作家和其它有创造力的怪才们并不乐意去掌握复杂的指令，或花费大量金钱去购买工作站。

制造这样的电脑，他们需要一个某天会真正会购买的人参与其中。在团队早期的招聘中，有一位年轻的艺术家加入了。她就是 Susan Kare 。

Susan Kare 幼时就开始学习绘画，后来在纽约大学主修美术学，并获得博士学位。毕业后，Susan Kare 来到加州海湾地区，在旧金山的 Fine Arts Museum 找到了一份工作，但是她真正渴望的是有自己的工作室。有一次，Akansas 博物馆给了她一个雕刻任务。她在 Palo Alto 的车库里开始了这份工作，这时候她接到了一个高中同学的电话。这个人是 Andy Hertzfeld，负责 Mac 操作系统的软件工程。

Susan Kare 在 Mac 团队的第一份工作是为 Mac OS 设计字体。她设计的字体使 Mac 上的文字显示如同书本页面上一样自然。字体原来以费城附近的车站——Rosemont、Ardmore 命名，乔布斯将命名改为世界级的大都市：Geneva，Chicago，和 New York。

由于当时设计图标的工具尚未编写，Susan Kare 买了一个 2.5 美元的速写本。在速写本上，她开始为一种全新的、用户友好的计算界面构建原型。速写本的每一个四方格对应屏幕上的一个像素。

Kare 首先画出的是一个指向的手指，代表着“粘贴”命令。

然后她画出了一个画笔，上面带有油墨。

她画出了一个代表“剪切”命令的剪刀。

她画出了一个“平面的手”，如今的一些软件上你也可以看到类似的图标，用于拖动纸张。

她画出了“停止”的图标。

一个代表“危险”的图标。当 Mac 团队悬挂海盗旗的时候，Susan Kare 为他们画了一个同样的图标。

一对苹果图标

她也画过一些古怪的图标，比如这个“自动缩进”的图标

两个被称为“jump”的程序指令

她还画出了一个术语“debug”,当程序员们奋力赶上乔布斯定下的最后期限，经常用到这个词。

这个图标是”boot“

当绘制图标的软件开发出来之后，Susan Kare 开始了数字领域的头脑风暴。她的主意来自所有地方：亚洲艺术史、很 Geek 的设备，同事的玩具，甚至包括大萧条时代流浪汉们在墙上指路的涂鸦。她所设计的 command 键上的图标，如今仍在使用。

图标的形状像是一个从上面看下去的城堡，广泛用于瑞典营地，代表着一个有趣的观光地点。

Kare 为 Mac 设计的视觉词汇非常诱人和直观。她不是将图标视为实际物体的缩小版。她的目的是使图标如同交通标志一样能够被人立刻理解。

Kare 的设计如她本人一样具有谦逊的品格，带有一种难以言传的安全感，使你放弃戒心。对于那些 90 年代的创造者来说，她的图标好像在说：不要为科技而愁眉苦脸了。来吧，跳进来吧。

《好主意来自哪里？》（Where Good Ideas Come From）的作者 Steven Johnson 最近在华尔街日报描述了他第一次看到 Mac 的惊喜：“这里有一个计算机，它将字体视为艺术，而不是一堆像素。图形界面使屏幕看起来像是一个你想要居住于其中的地方，想要拥有的地方……Mac 是一个你想要生活与其中的机器。”

对于 Susan Kare 来说，苹果的经历只是她职业生涯的第一个里程碑，多年来，她为 Windows 和 IBM OS/2 设计过图标，为 Windows 版的空头接龙设计过虚拟牌桌，为初创公司设计过 Logo 。成千上万的 Facebook 用户每日交换虚拟的生日蛋糕、结婚戒指、玫瑰和迪斯科厅的大滚球，从不知道这些设计都是出自 Susan Kare。她的 Happy Mac 曾站在新世界的门口欢迎过一代人。

当问到在为苹果设计图标时是否预料今日的影响，她说，“你可以着手去作画，但是你不能着手去做伟大的画。如果你看着一个空白的画布说，我现在要创造一个杰作，那只是愚蠢。你只需要尽己所能做出最好的图画，如果你幸运的话，人们会理解你要传达的意思。“

本文素材来自 Plos Blog

积木

The bulk of all patents are crap. Spending time reading them is stupid. It’s up to the patent owner to do so, and to enforce them (by Linus Torvalds)

邮箱 Twitter Facebook 新浪微博 Google+

[原]程序员编程艺术第二十三~四章：杨氏矩阵查找，倒排索引提取关键词

Mon, 19 Dec 2011 21:23:08 CST

第二十三、四章：杨氏矩阵查找，倒排索引提取关键词

作者：July。
出处：结构之法算法之道。

引言

本文先来回答一个何谓编程，何谓算法的问题（同时，本文会少许论述编程与算法的关系）。所谓编程，就是把心中的想法用程序实现；所谓算法，就是思考如何把心中的想法更好地实现。只有先把心中的想法实现了以后，才会去考虑如何更好地实现，才会去考虑效率，改进，优化。正所谓，还没学会走，如何跑？所以，学算法是学如何编程的晋升阶段，先学编程，再学算法。

编程是个细活儿，是个经验活，非一朝一夕所能炼成，不得有半点马虎，半点浮躁，半点急功近利。OK，有任何问题，也欢迎随时交流或批评指正。谢谢。

第二十三章、杨氏矩阵查找

有一些朋友是由于要进大公司准备面试而学的算法，那么面试考察的算法难么？或者是否有必要因要准备大公司的面试而大张旗鼓的去学算法呢？OK，举个简单的例子：

杨氏矩阵查找

先看一个来自剑指offer一书的编程（面试）题：

在一个二维数组中，每一行都按照从左到右递增的顺序排序，每一列都按照从上到下递增的顺序排序。请完成一个函数，输入这样的一个二维数组和一个整数，判断数组中是否含有该整数。
例如下面的二维数组就是每行、每列都递增排序。如果在这个数组中查找数字6，则返回true；如果查找数字5，由于数组不含有该数字，则返回false。

前面说了，学算法就是多思考，下面，解法有二（如查找数字6）：

1、分治法，分为四个矩形，配以二分查找，如果要找的数是6介于对角线上相邻的两个数4、10，可以排除掉左上和右下的两个矩形，而递归在左下和右上的两个矩形继续找，如下图所示：

2、首先直接定位到最右上角的元素，再配以二分查找，比要找的数（6）大就往左走，比要找数（6）的小就往下走，直到找到要找的数字（6）为止，如下图所示：

试问，上述算法复杂么？不复杂，只要稍微动点脑筋便能想到（何海涛先生一书剑指offer中收集了此题，感兴趣的朋友也可以去看看）。

而后，你也自会意识到，完全没有必要因为要准备大公司的面试而大张旗鼓的去学算法，算法只能作为一种工作需求，一种兴趣，而非助你取得offer的功利性工具。

第二十四章、倒排索引提取关键词

本章咱们来看一个可能实际工作中会遇的从索引中提取关键词的问题，我会摒弃其中复杂的原理与步骤，尽量用最简单易懂的语言阐述：

我们知道，搜索引擎的关键步骤就是建立倒排索引，所谓倒排索引一般表示为一个关键词，然后是它的频度（出现的次数），位置（出现在哪一篇文章或网页中，及有关的日期，作者等信息），它相当于为互联网上几千亿页网页做了一个索引，好比一本书的目录、标签一般。读者想看哪一个主题相关的章节，直接根据目录即可找到相关的页面。不必再从书的第一页到最后一页，一页一页的查找。

接下来，再次阐述下正排索引与倒排索引的区别：

一般索引（正排索引）

正排表是以文档的ID为关键字，表中记录文档中每个字的位置信息，查找时扫描表中每个文档中字的信息直到找出所有包含查询关键字的文档。正排表结构如图1所示，这种组织方法在建立索引的时候结构比较简单，建立比较方便且易于维护;因为索引是基于文档建立的，若是有新的文档假如，直接为该文档建立一个新的索引块，挂接在原来索引文件的后面。若是有文档删除，则直接找到该文档号文档对因的索引信息，将其直接删除。但是在查询的时候需对所有的文档进行扫描以确保没有遗漏，这样就使得检索时间大大延长，检索效率低下。

尽管正排表的工作原理非常的简单，但是由于其检索效率太低，几乎没有什么实用价值。

倒排索引

倒排表以字或词为关键字进行索引，表中关键字所对应的记录表项记录了出现这个字或词的所有文档，一个表项就是一个字表段，它记录该文档的ID和字符在该文档中出现的位置情况。由于每个字或词对应的文档数量在动态变化，所以倒排表的建立和维护都较为复杂，但是在查询的时候由于可以一次得到查询关键字所对应的所有文档，所以效率高于正排表。在全文检索中，检索的快速响应是一个最为关键的性能，而索引建立由于在后台进行，尽管效率相对低一些，但不会影响整个搜索引擎的效率。

倒排表的结构图如图2：

倒排表的索引信息保存的是字或词后继数组模型、互关联后继数组模型条在文档内的位置，在同一篇文档内相邻的字或词条的前后关系没有被保存到索引文件内。

从倒排索引文件中提取关键词

倒排索引是搜索引擎之基石。建成了倒排索引后，用户要查找某个query，如在搜索框输入某个关键词：“结构之法”后，搜索引擎不会再次使用爬虫又一个一个去抓取每一个网页，从上到下扫描网页，看这个网页有没有出现这个关键词，而是会在它预先生成的倒排索引文件中查找和匹配包含这个关键词“结构之法”的所有网页。找到了之后，再按相关性度排序，最终把排序后的结果显示给用户。

如下，即是一个倒排索引文件（不全），每一较短的，不包含有“#####”符号的便是某个关键词，及这个关键词的出现次数。我现在要你从这个大索引文件中提取出这些关键词，--Firelf--，-Winter-，007，007：天降杀机，02Chan..如何做到呢？一行一行的扫描整个索引文件么？当然不是，请读者自行思考。

--Firelf--（关键词） 8（出现次数）

提示一下：通过查找#####便可判断某一行出现的词是不是关键词，但如果这样做的话，便要扫描整个索引文件的每一行，代价实在巨大。如何提高速度呢？对了，关键词后面的那个出现次数为我们问题的解决起到了很好的作用，如下注释所示：

// 本身没有##### 的行判定为关键词行，后跟这个关键词的行数N
// 接下来，截取关键词--Firelf--，然后读取后面关键词的行数N
// 再跳过N行（滤过和避免扫描中间无用信息）
// 读取下一个关键词..

读者是否有更好地办法？欢迎随时交流。

后记

编程是个细活儿，但求循序渐进，算法是个脑力活，但求多多思考。他们之间的关系就是：算法只是服务于编程的一个工具而已。总而言之，先学如何编程，提高编程能力，再去学算法。

最后，基于本blog的分为程序语言，数据结构，算法讨论，面试题库，编程技巧五大板块交流的论坛正在加紧建设当中（总负责人：scott && yinhex && 网络骑士），相信不久以后便会与大家见面。完。

作者：v_JULY_v 发表于2011-12-19 21:23:08 原文链接

阅读：183 评论：1 查看评论

程序员房屋粉刷匠而非艺术家

Fri, 17 Feb 2012 13:09:08 CST

编者按：管理顾问Tim Bryce 说“计算机编程中极少人是真正的艺术家，大多数人充其量不过是房屋粉刷匠而已。”我想，对于刚入职或者即将入职的程序员，这也算是从另一个角度来诠释，什么样的程序员才是合格的程序员。

Tim Bryce 不喜欢程序员，而许多程序员也不喜欢他。Tim Bryce 在他发布过一篇名为《P理论：管理程序员的哲学》的文章中谈及

Tim Bryce 对程序员的看法

● 程序员都是故弄玄虚，妄自尊大的家伙。

● 与其它大学程度的工作者相比，普通程序员的智商要低。

● 程序员总显得邋里邋遢，精神涣散。互联网的一些事

● 程序员做事杂乱无章，因此很难评估他们工作的进度，其技术也尽显不足之处。

● 程序员的典型表现是常常埋怨自己工作过量，薪酬过低，所受的重视过少。

● 程序员自诩对科技发展怀有无比的好奇心。然而，好奇心是需要通过管理慎重培养的，因为信息过多很可能会导致程序员在工作时分心。

在对 Bryce 先生文章的回复中，有很多优秀观点，指出了他看法有失偏颇的原因。但是我想谈谈他兴许正确的几点看法。我还想去了解为什么一些入行 30 多年的管理顾问会持有这样的看法?当然，我否认费络伊德观点论所说的 Bryce 先生在童年时被某个无名的程序员伤害过。[主要的原因是当时世上只有为数不多的程序员，并且全都极负盛名。]

我对Bryce 言论的解析

Bryce 先生的目标听众不是程序员，而是 IT 管理者和企业决策者[不管怎么说，程序员的低智商很可能会妨碍他们理解P理论]。 P 理论的根本前提是：“对程序员的管理越有效，我们就越能充分利用系统来支持企业的信息需要。”这一理论并不是针对活生生的人，而是针对讲究实效的企业。人们应当从企业的角度来看待这一理论。因此，Bryce 先生的以下三点看法看来并非全错。

1. 程序员不是“软件工程师”，而是翻译。

我同意这种说法。程序员确确实实是翻译。不过我并不认可他们翻译的内容。 Bryce 先生写道说：“程序员将人类可理解的指令翻译成计算机指令。” 实际上，程序员翻译的是人类模糊隐晦的需求和想法，而不仅仅是不清不楚的指令。有时候这两者间的差别与毕加索化人类情感为艺术和房屋粉刷匠化顾客需求为斑斓墙面的差别无异。

如果客户和程序员间的思想交流不足，蹩脚的翻译及低劣的软件将随之产生，而程序员本身也会看起来很糟糕。那么，Bryce 先生的看法就言之有理了。 (系统思维除外)

2. 许多程序员并非“系统分析师”。

不幸的是，在许多情况下确实如此。 Bryce 先生写道：“真正的‘系统工程师或系统分析师’会去了解业务需求，确定和开展能够满足这一需求的业务流程，并明确需要程序员实现的软件要求。遗憾的是，担当这一重任的人极少。因此，这样的重任只能托付于那些不能胜任这项任务的程序员。

我确实认识很多不擅长去了解业务需求的程序员，或者说他们压根儿就不愿意去了解。然而，与 Bryce 先生不同，我认为程序员必须学会使用商业语言，学会与客户进行直接交流并了解他们的需要。程序员真正的工作不仅仅是编写计算机程序，专业的程序员还应当熟练地将复杂的精神理念翻译成软件。

如若不然，业务理念的错翻将会导致软件低劣，也会因此抹黑程序员。而 Bryce 先生的看法又将成为事实。

3. 程序员追求新兴技术方案，而不是实用的解决方案。

Bryce 先生写道：“要解决错误问题，简单的方案是没用的。” 学会从业务的角度去验证程序员自己的技术推荐十分重要。

的确，许多程序员对脱离业务理念的技术方案，甚至是新兴的技术方案更感兴趣。究其原因，是因为技术通常是程序员可以发挥才智与创造的唯一领域?还是因为程序员没能参与企业决策并了解客户需求?亦或是因为程序员素来脱离企业真正的需求和项目目标?

过度设计的解决方案是很糟糕的，它打着新兴技术的幌子却没有实际的需要。但是，如果能够实现前面的两点，即：1、程序员直接和客户一同工作。2、程序员了解客户需要并将其需求转换为软件，那么程序员就不会有时间和心思去理会天马行空的技术解决方案了，而是会努力寻求实用的方案，倾向并关注于那些重视客户价值的解决方案。

再看Bryce 的P理论

Bryce 先生认为程序员是一群我行我素的极客，他们需要强而有力的监督管理。管理员应当想方设法控制程序员怠惰无常，伪知识的天性。同时，软件项目需要大批可以缜密分析业务需求的分析人员(低智商显然不利于程序员直接获取这一需要)，当然，也迫切需要像 Bryce 先生这样的管理顾问，他可以告诉你如何正确看待程序员及他们行为。

另一种方法，就是相信程序员是负责任的群体，允许他们直接与客户一同工作并参与大部分的项目决策。由于管理者和程序员现有的思维定式，要转换观念并非易事。但对完美软件公司而言，一切皆有可能。

转载文章来自： cnbeta

移动游戏的架构艺术

Fri, 03 Feb 2012 18:05:11 CST

游戏是一门综合的艺术，作者以铸剑为喻，形象地展示了移动游戏架构的艺术之美。

艺术是人的知识、情感、理想、意念综合心理活动的有机产物，是人们现实生活和精神世界的形象表现。文学可以是艺术，雕塑可以是艺术，音乐可以是艺术，电影可以是艺术……那么游戏呢？

游戏是一门综合的艺术

无论是单机游戏还是网络游戏、PC游戏还是手机游戏，都需经过如图1所示的逐步进化的过程。

图1 游戏研发的流程

任何一款游戏，都有故事情节、人物、场景、音乐和音效等内容，因此其中每一部分内容都需要追求以艺术化的手段，将游戏的意象情景更生动地展现给用户。作为程序员的我们，之前可能只是以为只有策划人员需要通过艺术来表达游戏的内容、测试人员需要带着艺术去欣赏并完善游戏的体验，那么程序员对游戏的架构和艺术之间又是怎么挂上钩的呢？

用程序语言铸造艺术之剑

从古至今，有不少人热衷于铸剑，而铸出的剑是否称得上艺术作品，关键就在于它是否能表达出铸剑人的情感和用心所在。那么对于游戏程序的架构来说，也需要能体现出架构师对游戏的整体架构和每一个模块的把握，以及赋予它们的“神力”；同时，好的架构还将贯穿于游戏开发的整个过程。简单的测试一下，你是否也会遇到以下这些问题呢？

感觉游戏框架非常混乱，毫无条理？
开发完成后出现大量Bug，并且不知从何下手去解决？
出现很多难以重现的致命Bug？
添加某个功能或模块非常困难？
经过频繁的修改之后，出现大量冗余代码？

如果出现上述问题，那么说明我们所使用的这把架构之剑并不锋利，可能没有将“力”用在剑刃上吧。这也从另一方面体现出铸剑过程（也就是游戏的架构）的重要性。如果带着这些问题继续锤炼，那么终将铸成一把绝世宝剑。

架构是一个看不到也摸不着的虚幻东西，因此，我们还是结合具体的实例来分析如何将架构艺术化，通过代码来表达架构思想。假设现在有一套策划案，并且美术人员能够为我们准备所需要的资源。

“采矿”是铸剑之根本

有了铸剑的意念，就需要去选择各种高品质的玄铁矿石。同样，对于游戏的架构来说，就需要对游戏的各个功能模块进行分析，针对每个模块需要实现的功能和特殊属性进行抽象，概括出各个模块所需要定义的数据结构和接口以及各模块之间的关系。然后，再根据策划文档整理出适合编写程序的流程图、关系图、结构图等。最后，根据这些文档资料配合游戏的运行环境（比如游戏运行的平台）对实现技术进行需求分析，该分析主要针对功能和性能进行。下面我们以Android和iPhone两大平台为例进行分析。

在Android平台上，从效率的角度考虑，可以选择C/C++作为开发语言、OpenGL|ES作为图形库；从简单方便的角度考虑，可以选择Java作为开发语言、Skia作为图形库。

而在iPhone平台上，从跨平台的角度考虑，可以选择C/C++作为开发语言、OpenGL|ES作为图形库；从开发的难易程度考虑，可以选择Objective-C作为开发语言、Quartz2D作为图形库。这里我们没有考虑3D的特殊问题，如果进行3D游戏开发，必然会选择OpenGL|ES。另外，在iPhone平台上使用Quartz2D作为图形库开发游戏的比较少。

如果要做的是一个跨平台的游戏，我们还需要分析各平台的跨平台能力和特性（包括开发语言、渲染库、资源管理、内存管理等），例如iPhone中内存管理采用了引用计数的机制，那么可以考虑通过C++来实现一个类似的机制，这样就可以保证其他平台也都可以通用该机制。

这里我们也没有刻意地对某个语言和库进行比较，因为它们通常都有各自的优势，需要根据具体的游戏需求进行选择。准备好铸剑的玄铁之后，下一步我们开始铸剑（编写代码）了吗？

“剑范”决定“剑气”

“剑范”即铸剑所用的模型，“剑气”即剑品的气势，因此，铸剑所用的模型将最终决定宝剑的“主题”。

“剑范”的打造对应于游戏架构中负责全局范围的核心框架，该框架是否合理，将决定整个架构的成败。说到框架，不得不说说大家可能都比较熟悉的MVC框架，作为程序员，应该没有谁不知道MVC的定义，但是关键在于如何从更深层次去学习它，理解它，运行它。曾经一位朋友问我：“你们通常采用什么框架？什么框架会比较好呢？”我回答：“MVC框架啊！”看着他一脸吃惊的表情和一句“也很普通的框架！”的回答，我真不知道说什么好！MVC框架的确很普通，也很简单，而如何让它发挥出其本身的功效却是关键！例如，在iPhone开发中，苹果公司就推荐采用该框架，具体描述如下：

视图（V）：由UIView类的子类及其相关的UIView-Controller类来提供；
控制器（C）：控制器行为通过主要由委托、目标操作、通知来实现；
模型（M）：通过数据库和数据含义等协议提供逻辑模型，由控制器进行管理。

另外，就连目前红遍整个互联网的Android系统来说，Google官方也同样推荐使用MVC框架来开发和维护应用程序，具体描述如下：

视图（V）：由View和SurfaceView（或者自定义的视图）提供用户的界面，采用XML格式进行布局；
控制器（C）：由Activity来管理视图和逻辑模型；
模型（M）：向视图提供逻辑模型，由控制器来触发，比如各种Adapter接口。

根据切身的经历，我得出了下面的观点： “如果不能保证将其他的设计模式运用好，就不如选择类似于MVC这类的简约而不简单的框架来完成，可能结果会更精彩！”

由此可见游戏架构中框架的重要性。如果你还觉得不够，那么我建议应该向众多的Android和iPhone开发者询问答案，苹果和 Google的文档将是你最好的学习资料！相信你已经跟着我们的脚步，打造出了适合你自己的 “剑范”了，现在是时候开始铸剑了！

真金不怕火炼

宝剑品质的好坏在于使用的原材料，如何检验矿石的材质？还得看准备的火力是否强劲。现在让我们回到游戏架构的话题。

首先，尽管通常游戏中可能会存在多个视图、多个模型甚至多个控制器，我们还是将一款游戏分为三个大的模块，即MVC的控制器、视图、逻辑模型。图2为我当前正在开发的一款Android游戏的框架。

由图2可以看出，程序从入口Activity进入，通过setContentView()函数设置显示一个视图类MainView时，游戏的主线程已经开始Loop了；而游戏要显示的具体场景则由控制器Control类根据游戏状态等信息通过getCurScene()函数得到，得到的场景实际上是抽象场景SceneInterface类的子类（如SceneA）；在SceneInterface中包括各个场景的公共接口，以便在Control.control()中能直接控制当前显示的场景，需要注意的是，在控制器中一般需要先通过SceneInterface.reCycle()来对上一个界面产生的垃圾进行回收，同时对逻辑模型类Model中的数据进行处理。

图2 MVC游戏框架

由于图片大小的原因，我没有列出全部类结构，这些类包括在SceneInterface中定义一个界面事件的公共接口或者对Model采用“实体—对象—类”的方式进行扩展以及所需的工具类。

铸剑的最高境界—指导练剑之人

好的宝剑通常可以提高用剑之人的剑术！Google和苹果所铸造的Android、iPhone这两把宝剑，指导了无数的开发者。我们又何不学习学习Google和苹果这两位铸剑人的技艺呢？

下面继续分析Android可能会如何指导“练剑人”。在做Android应用开发时，Google推荐通过XML文件来布局界面，从而让UI界面和程序逻辑分离，方便维护；实际上Google对XML文件以及其他资源都进行了优化，这样做可以提高程序的运行效率。下面我们也将学习这一招，通过XML文件来布局游戏场景。

首先，将一个游戏场景（SceneA）中需要显示的内容分为UI界面（如按钮、菜单等）和游戏对象（如精灵）两部分；其次，UI界面和游戏对象可能都需要动画；最后，既然要使用XML文件来布局，就需要一个专门的解析器。稍作整理，现在我们所需要的模块如图3所示。

图3 游戏场景架构

图3描述了一个场景的元素架构与解析，其中UI界面、游戏对象、动画模块都将使用一个或多个XML文件来完成，通过XML的解析，最终将XML文件的内容输出到SceneA中。整个过程首先需要构建一个XML解析器，然后根据游戏的需要构建各种UI控件、游戏对象、动画等类。目前工程中用到的类包括：

UI控件：UIText、UIProgress、UITexture、UIList、UIClick、UICheckBox
游戏对象：GameObj、EffectObj、Bullet、Enemy
游戏动画：PosAnimation、ColorAnima-tion、FrameAnimation

每一个类中都有其所需要的成员变量，下面我们可以根据解析器的实现来使用XML文件布局游戏场景了。根据游戏的需要，可以将XML文件扩展到支持多级子节点，然后在游戏中获取XML中定义的元素，进行操作即可。同样需要将界面和程序进行分析，方便修改和维护。整个过程的完整流程如图4所示。

图4 XML布局流程

实际上我正在进行的项目除封装了上面所说的三个模块外，还将整个游戏架构都进行了封装，包括图2中所展示的控制器、主线程、模型，整个框架都能通过XML文件直接编写。到这里，你所铸造的宝剑也应该出世了，带上宝剑，冲向游戏世界吧。

作者： 杨丰盛，轻灵数码研发部经理，精通Java、C/C++等语言及J2ME、BREW、MTK、Android、iPhone等平台。曾领导和参与《三国群英传》、《大航海传奇》等游戏的开发。著有《Android应用开发揭秘》。

（本文来自《程序员》杂志11年01期，转自：http://www.programmer.com.cn/5223/）

转：编程的艺术：漂亮的代码和漂亮的软件

Thu, 23 Feb 2012 19:13:00 CST

最近在转一些装波一文，发发牢骚而已。现实中除了那些API和一些开源软件，真的很少看得到漂亮的代码，不过有一天帅朱给我看过一段代码，不错。。。Sun也能我看过一些，也不错。看看自己写的，一泡污啊

原文来自：http://kb.cnblogs.com/page/132236/

　　英文原文： Beautiful Code and Beautiful Software
译者：legendsland

　　2007-10-29

　　编程很有意思，是因为我可以做一些很酷的东西，但是实际上让我着迷的却是那一行行代码的语法和语义。保持对好代码和坏代码之间差异的敏感相当激励人，同时，去寻找编写高效、自文档化和经过深思熟虑良好组织的代码的方法将会永远吸引着我。这便是我对所在领域钟爱的原因 —— 编程的艺术 —— 这种奇妙的复杂物(complex craft)将会让你花费一生的时间去成为大师。

　　续Ruby之后，我学习了Java和Objective-C，我开始享受到底层软件开发的乐趣。我是在一个讨厌繁缛语言开发的社区（Rails 社区）成长起来的，但是当我第一次接触这类语言之后，发现我喜欢上了它们。它们（和Ruby比较起来）是不同的语言，但仍然具有它们特有的乐趣。以 Java 里面的for循环为例，当以我的高级程序语言的背景，编写了一些这样的基础代码后，发现这种代码可以更好地帮助我理解面向对象的一些实践，但同时我也对 for循环本身产生了兴趣。这不仅仅是优美的语言吸引了我，也是语法背后的逻辑和不同语法形式让我着迷。计算机语言，以及它们之间的差异，本身就极具魅力。

　　当这学期我在学校学汇编语言的时候，获得了相同的满足感。汇编很繁琐，有时相当痛苦，但是让我去思考使用这种新的方式去实现基本的程序功能，跟痛苦相比，是完全值得的。当然，意识到自己编写的代码如此底层，也让我享受到了极客(Geek)的快感。

　　情况变得更糟了！在今年的早些时候，当我读到Wolf的程序员不喜欢编码时，我经历了一个很不错的自我发现过程。我确实是喜欢在编码过程中解决问题，进行优雅地创造，以及通过编码来学习，但实际上我意识到我也是因为喜欢编码而编码。至少，这就是我享受CSS和XHTML的方式。我拥有大量的Web前端开发经验，并且最近没怎么碰到新的问题（事实上，难搞的问题和我从没有见过的 Bug会让我异常兴奋）。尽管如此，我仍然喜欢这些东西。比如，整理一下我完全理解的代码让它变得好看点，就像是在我的笔记本上重复地画一些卡通猫，或者是坐在钢琴前重复地弹三个相同的音调一样，这让我感到放松。甚至仅仅去阅读漂亮的CSS（我自己写的CSS），上面每一样东西都整齐有序、缩进良好，并且进行了正确的层叠（CSS里面很重要的一种技术）而感到心情舒畅；相反，当我看到某些论坛的样式表里面混乱的缩进、多余的空行、被注掉的一些老代码，以及通过故意使用错误的属性名来屏蔽掉的样式的时候，我感到难受，就像是生病了一样。

　　当你可以如此轻易地被激起兴趣，就是上面这个结果。仅仅是墙上的影子就足够让你继续生活下去（译注：看来，她对柏拉图很有兴趣）。你得不断地重新审视自己的敏感度，以便让你的声色品味与你口袋里的钞票相匹配。（你对代码或者软件的品味来自于你自己的能力水平）

　　这样来讲吧，这些天我一直在思考（整个）软件开发中的软件部分。特别是软件中的用户界面设计。今年在BARcamp，我喜欢Aza Raskin的一个实验，他让所有的开发人员举起手，然后是设计人员，接着他说那些第一次举手的人在第二次也应该举手。所有的开发人员必须是设计人员。至少，幸运的是，所有的开发人员在他们的工作中可以对软件设计发表自己的意见。

　　我越来越对软件开发中设计部分的重要性感到兴奋，尤其是当我反思我对过去所做的事情在不同方面的热情与心得的时候。在Web应用领域，开发和设计一般是分离的。有时候，设计部分的工作在项目中被最少化了，这是因为客户是为软件的特性买单，而不会为漂亮的设计付帐。在一个项目中，我同时扮演了开发和设计的角色，回想起来，我对只分配了两天时间来完成可视化的设计感到耿耿于怀。这决不是两天的事情。这是一个很复杂的应用软件，需要花上几周的时间与客户交流和迭代设计。不幸的是，客户并不会因此而买单。相反，客户对我花了几个小时的原型感到无比满意，就这样，我们有了这个产品的第一个版本。

　　在今年的C4上我有了另一次觉悟。好像很多Mac下的开发人员都在（私下）做自己的产品。这样，他们真的必须既是设计师又是开发人员。事实上，设计是最重要的部分，并且用户体验和制造了不起的产品看起来要比代码本身更具有热情。在C4的一个晚上，有人在向我描述他的工作的时候，无意中帮助我看到了这一点：编码这个基本要素是最容易的部分。那仅仅需要几周而已。真正困难和耗费时间的是搞定UI的规格。

　　哇噢，我在想，为什么这看起来如此正确？为什么对我而言是这么的酷？哦，是的，那是因为我是从设计人员开始的。我享受开发、设计和艺术的方式绝然不同，这就导致了这三种享受之间巨大的差别。我一直在尝试整合开发和艺术（这两个方面），但是我其实应该整合这三个方面。

　　毕竟，我的天啊！我们想要漂亮的代码或者是漂亮的软件吗？我生活中的另一个观点是：由于我的思想极具开放性和强吸收性，我发现我自己可以接受各种相互矛盾的观点，有时候甚至是相反的观点。这种问题目前不会困扰我，因为我正处在探索模式的阶段，而不是在只接受我所相信的阶段，但是，当然啦，为了保持我思想自身的一致性，当它们有点头绪的时候必须要好好的整理一下。

　　所以，为了后续的考虑，我按照软件开发给人们带来的由内至外的收获，简单地列出了这个清单。我没有选择其他一些极好的介质，比如社区、开源和挑战等等，是因为这些都很难按顺序列到里面去，不过我相信你可以领会到其中的要点。这个顺序对我而言是极度重要的，因为心理学家讲过，内因的力量更为强大，更能让你坚持。比如，一个为了想从击打和踢腿中感觉到力量和兴奋而参加空手道训练的人，肯定要比仅仅为了健康的人更容易达到黑段水平。

　　编程也是如此吗？

　　* 代码感（译者：还记得圣斗士里面的第六感吗？）
* 编码的知识
* 享受计算机逻辑
* 享受计算机语言
* 优雅的语法
* 优美的语义
* 学习代码
* 问题求解
* 了解问题
* 获得可用性
* 完成一个产品
* 优雅的软件
* 解决人的问题
* 解决商业的问题
* 满足市场需求
* 赚钱
* 有一个稳定的职业

　　哪个是最能持续激励人的收获？更重要的是，哪种动机可以制造出最好的软件？有时候我很想在这个话题上做一个很正式的研究，当我们希望软件既满足可用，又具备可维护性，同时还叫买，而且还要满足一些其他的目标的时候，我很确信这个答案就是清单上面各种条目之间健康的平衡。我同时还很确信这种平衡性是因情况和人而异的。现在，我已经勾画出了一条钟形曲线（正态分布），那些可以促成最佳的软件的动机位于曲线的中间部分；但是，我想实际上所有的动机在某些方面都是有益的，并且当程序员有她自己的优先级的时候，动机自然是越多越好。

　　我们领域的悲哀在于大多数程序员并不会欣赏上面大部分的收获，尤其是那些更为重要的。这个清单很有用，因为大多数编程的工作无法满足那些关心所有这些事情的人。同样地，我很好奇，如果我们每个人都从内心关心我们做的东西，并且不会有人为了稳定的工作而去选择计算机科学者个专业，那么这个（软件）领域将会成为什么样子呢？我好奇这样会对整个世界产生什么影响？

　　我想我每年都应该反思一下这种问题，以便成为一个更好的软件开发人员。尽管如此，我还是觉得我的信念已经固定下来了：越是成长，就越希望能够在一个足够自由的环境里面创造美妙的东西。值得注意的是，美妙和自由都是模糊和主观的概念，可以任意地去理解。我只知道，在大多数的编程工作中对代码之美和软件设计之美的妥协永远会让我感到不满。如果到最后，我选择成为一个自由开发者去做Web设计，以满足这种自我的生活风格，我不会对此感到意外。

　　最终我会从计算机上面退休，并且用我剩下的时间在国外美丽的农场里面画画。或者是，过上在街头涂涂抹抹和牢房之间互动的感性城市生活。想象一下，当我觉得技术玩完了的时候，接下来要去哪里将是很有趣的。但愿永远不要发生这种事情，因为我希望成为一个酷酷的guru奶奶，到时候给孩子们上一些编程的必修课呢！(Fantastic guru girl !!)

----------

看完到最后的时候，我在想guru是什么，有道告诉我，这是专家的意思。哦，

图解的艺术――信息可视化运用

Wed, 17 Apr 2013 10:53:08 CST

　　图解的艺术——信息可视化运用信息爆炸的今天人们身边挤满着各类数据，可视化的方式能在这堆容易被忽视的繁杂数据油田里挖掘出故事告诉大家。这就是信息可视化的魅力所在。信息可视化，最早源于数据可视化，也就是我们熟悉的那些饼图、直方图、散点图、柱状图等最原始的统计图表。这里不细讲历史理论和纠结专业术语，再此贴一篇来自UCDchina关于信息可视化的介绍博文，有兴趣理清概念的可浏览。

　　以前信息可视化在大众们听起来异常高深莫测，涉及着制图学，图形绘制设计，数据采集，统计学，图解技术等等等。而近几年，因为世上的可爱设计师们，把这样一个原本冷酷而机械的科学类图解变成平易近人而极具吸引力的“艺术品”，这也是最近信息可视化流行起来的原因。今天咱们聊的，就是这些运用信息可视化思维制作的“艺术品”。

　　 在此把信息可视化分成两种常用的设计类型，一是呈现数据，二是陈述观点。

　　 1:呈现数据
设计师用直观而极具美感的视觉表现方式把数据呈现出来，读者在观赏这件“艺术品”的时候自然读到里面蕴含着一些有趣的故事。 (就例如看facebook用户连接数的可视化，能看到连线再美也连不进中国版图。)

　　Facebook全球用户连接数：

　　qq的实时在线人数的可视化：

　　除了上述的两个基于地图的可视化，各种将传统统计图表经过再设计，图形美化，形象化的可视化都属于这种类型。

　　各种呈现数据类型可视化：

　　互动式数据呈现

　　在数据呈现类的可视化项目中，设计师工作是要吸引读者能自发挖掘数据里的故事，所以除了数据的视觉美化外，还会考虑读图体验的设计，也就是常用可交互方式来呈现整个可视化。

　　这里分享个案例：《university-autonomy》

　　university-autonomy网站主要让读者清晰快速对比欧洲各国大学的自治状态，偏向阅读功能性。网站分别把四类自制状态配以不同颜色：组织自治(橙色)，金融配置(红色)，教职任免(紫红色)以及学术自制(深紫色)。并且都有各自小图标表示，为降低阅读成本，每个代表国家也在地图上呈现。浏览时可以点某一国家浏览数据，也可以直接点击四类其中一类来观看各国的对比。例如点开英国，圆型的国旗图标周围散布着四类颜色的点，某一色条上点的多与少表示某一项自治得分多寡。如此对比其他国家，英国在组织自制度上是第一位的，包括自由决定自治组织，各方面的选拔，决定任期以及设定院系内部结构等等。这种互动式的可视化更重要是优化了数据的阅读体验，想知道数据里的哪些方面由读者自行决定，设计师提供了一个舒适的可视化阅读环境。

　　 2：陈述观点

　　观点陈述类的可视化，就是设计师先对数据分析，把挖掘到的观点直接告诉读者。

　　最常见的就是信息图表和图示视频：

　　a：信息图表

　　例如“人间胸器”的信息图里所说的一些和我们息息相关却没细细研究过的数据，直接告诉读者设计师挖掘到的观点。 “女性正常状态的乳头高度只发挥了3/8的高度。平均扩张后高达五个25美分币高度。”(是不是有点要找硬币试叠的感觉?)

　　人间胸器：

　　此类可视化相比数据呈现类有个明显的优势，就是对于读者来说接受信息更加“简单粗暴”，而且设计起来也较为简便。

　　最近很多游戏在宣传上也尝试了这种可视化方式

　　就例如DNF阿拉德秘史项目

　　结合DNF玩家分析和项目组想要宣传的东西和相应的玩家数据寻求一些观点，例如玩家喜欢讨论天空套，那就挖掘瞎天空套的相关数据，哪些人买了，什么身份，所在城市，这些构成了哪些好玩的观点，并结合观点加入情感化画面表现，以互动网站形式展现。

　　阿拉德秘史第二期——boss的辛酸故事：

　　b：图示视频

　　对比起信息图表来说，图示视频主要是表现手法的不同，对读者的吸引程度也不一样，但这需要一个好的“导演”。

　　这里展示一个Pinterest的可视化视频：Pinterest Statistics Facts

　　Pinterest Statistics Facts:

　　视频设计上非常细腻，包括整体色调和图形动态，细心可以发现里面展示的信息图表设计非常形象，包括pinterest男女用户比例的图表直接拉大女生形象来对比，年龄层的图标用生日蛋糕的蜡烛灯火来做条形图等等，满满有爱的细节耐人寻味。

　　相比信息图表，图示视频会有个优势，就是好的动态演示加上配音，可以弥补视觉设计上的不足，例如这段《5分钟，让你了解自己都交了哪些税》里提取的观点非常切合民情，观点异常犀利，即使视觉设计一般也能让大家产生共鸣。

　　 可视化设计方法——对比和比喻

　　无论是数据呈现还是观点陈述，对比和比喻是都是可视化设计中最常用的手法。

　　a：对比——有对比就能催生故事。

　　就像Goldstar啤酒广告，设计师把男女上洗手间的整个行为用流程图表可视化出来，因为有了男女对比而让故事耐人寻味。从而让目标受众了解一个观点“感谢上帝你是个男的!”

　　Goldstar啤酒广告：

　　还有上面提到的university-autonomy网站也是让读者对比各国大学数据从而读出观点。

　　b：比喻——把陌生的变熟悉

　　数据给到我们的都是陌生而繁杂的感觉，没人会对一大堆烦躁的数据感兴趣，设计师在数据呈现类可视化设计的时候，多会用比喻的手法，把读者感觉陌生的数据转化为他们熟悉或者有认知度的东西呈现给他们以达到共鸣。

　　This Exquisite Forest是Chris Milk在英国的一个艺术项目

　　先请一批艺术家绘制一个小短片，然后其他参与者可以在网站上不断做上一个短片的接龙。(在此不细讲整个艺术项目，有相关介绍有兴趣可以看看项目介绍视频)

　　这里主要介绍的是设计师利用了比喻手法做的一个可视化网站，把所有艺术家的起始视频比喻为树的根部，往后每个参与者接龙就会生出一支叶子，最终整个网站的视觉由参与者共同生成的，而且很直观能看到那些小短片的接龙者特别多(枝繁叶茂)。

　　This Exquisite Forest:

　　用类似手法的还有这个类比宇宙的音乐操作界面，这里有相关介绍视频

　　它把所有的音乐数据比喻成一个宇宙，音乐播放时长比喻成星球运行轨迹，同样是比喻手法的信息可视化。

　　结语：

　　其实信息可视化是个跨学科领域需要庞大知识体系支撑的研究方向，但并不等于就是离我们如此遥不可及，我们无非是学习一种信息可视化的思维方式，创建那些以直观方式传达抽象信息的手段和方法，用我们设计师独特的视角，从可信的数据油田中挖掘大家喜闻乐见的故事!

本文链接： http://www.yixieshi.com/it/13475.html

iOS 上有哪些精美、优雅到艺术品水平的应用

Sat, 06 Oct 2012 21:45:21 CST

这里的「精美」和「优雅」应该是指整体的感受，这种感受既包括视觉，也包括功能和整个交互流程。另外，iOS是一个整体非常注重设计且设计质量非常高的平台，所以在这样一个平台上判定优秀的标准也应该更高（仅仅以界面设计来评判似乎已经没有结果了）。

列一些我个人比较爱的（不包括游戏），一时总结不全，大家继续补充：

Path
异常精美的界面设计，创新的交互方式和独特的产品理念，创造了一批非常忠实的用户。

Piictu
异常精美的界面设计，创新的界面元素，创新的图片分享模式，很好的前景。

Tweetie（现在的Twitter for iPhone）
精美&清爽的界面，重新发明了RT，创新的下拉刷新交互方式（目前已成为iOS上的标准交互了）。

Twitter for iPad
非常精美的界面（在iOS上你会发现「精美的界面」是一件如此平常的事情），创新的左右折叠层级关系和交互方式。

Tweetbot（其他几个Tapbots的产品都可以上榜，比如Convertbot、Weightbot等）
号称史上最精细的Twitter第三方客户端，完全自定义了iOS所有控件，整个应用切图的数量达到700－800张，精确到每一个细节。

Gowalla
界面风格大胆，每一个界面元素都非常精美，交互过程流畅，教科书级别的色彩运用。

Flipboard
作为阅读器，它拥有教科书级别的「平面设计与界面设计融合」，同时也是「界面设计与交互设计融合」的典范，创新的社交网站阅读聚合模式。

Yobongo
精美、清爽的界面，创新的模式（LBS＋群聊），流畅的交互和操作。

Voicemod
界面非常酷，创新的交互和玩法。

Things（iPhone & iPad）
非常著名的以精美设计著称的应用，曾赢得Apple Design Award 2009，清爽的界面元素以及精简实用的功能。

Camera Genius
著名的设计团队Artua出品，写实的界面风格，精美到极致的界面元素，丰富的功能。

Yoritsuki

日本著名设计工作室Hybridworks出品，无需多说，这货就是件纯艺术品，是Hybridworks的炫技作品之一。

Bjork的 Biophilia： itunes.apple.com/hk/app/bjork-...
女外星人的最新专辑，以app形式推出，宇宙，距离，光，歌。牛逼美。

Ringier的 the Collection： itunes.apple.com/us/app/the-co...
我见过的最好的交互内容呈现形式。牛逼美。

The Elements： itunes.apple.com/us/app/the-el...
像看艺术展一样看元素周期表。装逼美。

Weather HD： itunes.apple.com/us/app/weathe...
简单，直观，自然。装逼美。

iOrgel： itunes.apple.com/us/app/iorgel...
精密，直观。真诚美。

MoMA的 AB EX NY： itunes.apple.com/us/app/moma-a...
本来就是艺术品，不可能不美。

还有这个设计师的作品： cargocollective.com/jonaseri...

无法评论。

前往星光社阅读

星光社首页关于我们背单词三国演义阅读记单词书籍阅读

编写可读代码的艺术

Thu, 21 Mar 2013 07:49:19 CST

这是《The Art of Readable Code》的读书笔记，再加一点自己的认识。强烈推荐此书：

英文版：《The Art of Readable Code》
中文版：编写可读代码的艺术

代码为什么要易于理解

“Code should be written to minimize the time it would take for someone else to understand it.”

日常工作的事实是：

写代码前的思考和看代码的时间远大于真正写的时间
读代码是很平常的事情，不论是别人的，还是自己的，半年前写的可认为是别人的代码
代码可读性高，很快就可以理解程序的逻辑，进入工作状态
行数少的代码不一定就容易理解
代码的可读性与程序的效率、架构、易于测试一点也不冲突

整本书都围绕“如何让代码的可读性更高”这个目标来写。这也是好代码的重要标准之一。

如何命名

变量名中应包含更多信息

使用含义明确的词，比如用 `download`而不是 `get`，参考以下替换方案：

   send -> deliver, dispatch, announce, distribute, route
 find -> search, extract, locate, recover
start -> lanuch, create, begin, open
 make -> create,set up, build, generate, compose, add, new

避免通用的词

像 tmp和 retval这样词，除了说明是临时变量和返回值之外，没有任何意义。但是给他加一些有意义的词，就会很明确：

  tmp_file = tempfile.NamedTemporaryFile() 
...
SaveData(tmp_file, ...)

不使用retval而使用变量真正代表的意义：

  sum_squares += v[i]; // Where's the "square" that we're summing? Bug!

嵌套的for循环中, i、 j也有同样让人困惑的时候：

  for (int i = 0; i < clubs.size(); i++)
    for (int j = 0; j < clubs[i].members.size(); j++)
        for (int k = 0; k < users.size(); k++) if (clubs[i].members[k] == users[j])
            cout << "user[" << j << "] is in club[" << i << "]" << endl;

换一种写法就会清晰很多：

   if (clubs[ci].members[mi] == users[ui])  # OK. First letters match.

所以，当使用一些通用的词，要有充分的理由才可以。

使用具体的名字

CanListenOnPort就比 ServerCanStart好，can start比较含糊，而listen on port确切的说明了这个方法将要做什么。

--run_locally就不如 --extra_logging来的明确。

增加重要的细节，比如变量的单位 `_ms`，对原始字符串加 `_raw`

如果一个变量很重要，那么在名字上多加一些额外的字就会更加易读，比如将 string id; // Example: "af84ef845cd8"换成 string hex_id;。

               Start(int delay)  -->  delay → delay_secs
        CreateCache(int size)  -->  size → size_mb
ThrottleDownload(float limit)  -->  limit → max_kbps
          Rotate(float angle)  -->  angle → degrees_cw

更多例子：

  password  ->  plaintext_password
 comment  ->  unescaped_comment
    html  ->  html_utf8
    data  ->  data_urlenc

对于作用域大的变量使用较长的名字

在比较小的作用域内，可以使用较短的变量名，在较大的作用域内使用的变量，最好用长一点的名字，编辑器的自动补全都可以很好的减少键盘输入。对于一些缩写前缀，尽量选择众所周知的(如str)，一个判断标准是，当新成员加入时，是否可以无需他人帮助而明白前缀代表什么。

合理使用 `_`、 `-`等符号，比如对私有变量加 `_`前缀。

  var x = new DatePicker(); // DatePicker() 是类的"构造"函数，大写开始
var y = pageHeight(); // pageHeight() 是一个普通函数

var $all_images = $("img"); // $all_images 是jQuery对象
var height = 250; // height不是

//id和class的写法分开
<div id="middle_column" class="main-content"> ...

命名不能有歧义

命名的时候可以先想一下，我要用的这个词是否有别的含义。举个例子：

  results = Database.all_objects.filter("year <= 2011")

现在的结果到底是包含2011年之前的呢还是不包含呢？

使用 `min`、 `max`代替 `limit`

  CART_TOO_BIG_LIMIT = 10
    if shopping_cart.num_items() >= CART_TOO_BIG_LIMIT:
        Error("Too many items in cart.")

MAX_ITEMS_IN_CART = 10
    if shopping_cart.num_items() > MAX_ITEMS_IN_CART:
     Error("Too many items in cart.")

对比上例中 CART_TOO_BIG_LIMIT和 MAX_ITEMS_IN_CART，想想哪个更好呢？

使用 `first`和 `last`来表示闭区间

  print integer_range(start=2, stop=4)
# Does this print [2,3] or [2,3,4] (or something else)?

set.PrintKeys(first="Bart", last="Maggie")

first和 last含义明确，适宜表示闭区间。

使用 `beigin`和 `end`表示前闭后开(2,9))区间

  PrintEventsInRange("OCT 16 12:00am", "OCT 17 12:00am")

PrintEventsInRange("OCT 16 12:00am", "OCT 16 11:59:59.9999pm")

上面一种写法就比下面的舒服多了。

Boolean型变量命名

  bool read_password = true;

这是一个很危险的命名，到底是需要读取密码呢，还是密码已经被读取呢，不知道，所以这个变量可以使用 user_is_authenticated代替。通常，给Boolean型变量添加 is、 has、 can、 should可以让含义更清晰，比如：

               SpaceLeft()  -->  hasSpaceLeft()
bool disable_ssl = false  -->  bool use_ssl = true

符合预期

  public class StatisticsCollector {
    public void addSample(double x) { ... }
    public double getMean() {
        // Iterate through all samples and return total / num_samples
    }
    ...
}

在这个例子中， getMean方法遍历了所有的样本，返回总额，所以并不是普通意义上轻量的 get方法，所以应该取名 computeMean比较合适。

漂亮的格式

写出来漂亮的格式，充满美感，读起来自然也会舒服很多，对比下面两个例子：

  class StatsKeeper {
   public:
   // A class for keeping track of a series of doubles
      void Add(double d);  // and methods for quick statistics about them
     private:   int count;        /* how many so    far
   */ public:
           double Average();
   private:   double minimum;
   list<double>
     past_items
         ;double maximum;
};

什么是充满美感的呢：

  // A class for keeping track of a series of doubles
// and methods for quick statistics about them.
class StatsKeeper {
  public:
    void Add(double d);
    double Average();
  private:
    list<double> past_items;
    int count;  // how many so far
    double minimum;
    double maximum;
};

考虑断行的连续性和简洁

这段代码需要断行，来满足不超过一行80个字符的要求，参数也需要注释说明：

  public class PerformanceTester {
    public static final TcpConnectionSimulator wifi = new TcpConnectionSimulator(
        500, /* Kbps */
        80, /* millisecs latency */
        200, /* jitter */
        1 /* packet loss % */);

    public static final TcpConnectionSimulator t3_fiber = new TcpConnectionSimulator(
        45000, /* Kbps */
        10, /* millisecs latency */
        0, /* jitter */
        0 /* packet loss % */);

    public static final TcpConnectionSimulator cell = new TcpConnectionSimulator(
        100, /* Kbps */
        400, /* millisecs latency */
        250, /* jitter */
        5 /* packet loss % */);
}

考虑到代码的连贯性，先优化成这样：

  public class PerformanceTester {
    public static final TcpConnectionSimulator wifi =
        new TcpConnectionSimulator(
            500, /* Kbps */
            80, /* millisecs latency */ 200, /* jitter */
            1 /* packet loss % */);

    public static final TcpConnectionSimulator t3_fiber =
        new TcpConnectionSimulator(
            45000, /* Kbps */
            10,    /* millisecs latency */
            0,     /* jitter */
            0      /* packet loss % */);

    public static final TcpConnectionSimulator cell =
        new TcpConnectionSimulator(
            100,   /* Kbps */
            400,   /* millisecs latency */
            250,   /* jitter */
            5      /* packet loss % */);
}

连贯性好一点，但还是太罗嗦，额外占用很多空间：

  public class PerformanceTester {
    // TcpConnectionSimulator(throughput, latency, jitter, packet_loss)
    //                            [Kbps]   [ms]    [ms]    [percent]
    public static final TcpConnectionSimulator wifi =
        new TcpConnectionSimulator(500,    80,     200,     1);

    public static final TcpConnectionSimulator t3_fiber =
        new TcpConnectionSimulator(45000,  10,     0,       0);

    public static final TcpConnectionSimulator cell =
        new TcpConnectionSimulator(100,    400,    250,     5);
}

用函数封装

  // Turn a partial_name like "Doug Adams" into "Mr. Douglas Adams".
// If not possible, 'error' is filled with an explanation.
string ExpandFullName(DatabaseConnection dc, string partial_name, string* error);

DatabaseConnection database_connection;
string error;
assert(ExpandFullName(database_connection, "Doug Adams", &error)
        == "Mr. Douglas Adams");
assert(error == "");
assert(ExpandFullName(database_connection, " Jake Brown ", &error)
        == "Mr. Jacob Brown III");
assert(error == "");
assert(ExpandFullName(database_connection, "No Such Guy", &error) == "");
assert(error == "no match found");
assert(ExpandFullName(database_connection, "John", &error) == "");
assert(error == "more than one result");

上面这段代码看起来很脏乱，很多重复性的东西，可以用函数封装：

  CheckFullName("Doug Adams", "Mr. Douglas Adams", "");
CheckFullName(" Jake Brown ", "Mr. Jake Brown III", "");
CheckFullName("No Such Guy", "", "no match found");
CheckFullName("John", "", "more than one result");

void CheckFullName(string partial_name,
                   string expected_full_name,
                   string expected_error) {
    // database_connection is now a class member
    string error;
    string full_name = ExpandFullName(database_connection, partial_name, &error);
    assert(error == expected_error);
    assert(full_name == expected_full_name);
}

列对齐

列对齐可以让代码段看起来更舒适：

  CheckFullName("Doug Adams"   , "Mr. Douglas Adams" , "");
CheckFullName(" Jake  Brown ", "Mr. Jake Brown III", "");
CheckFullName("No Such Guy"  , ""                  , "no match found");
CheckFullName("John"         , ""                  , "more than one result");

commands[] = {
    ...
    { "timeout"      , NULL              , cmd_spec_timeout},
    { "timestamping" , &opt.timestamping , cmd_boolean},
    { "tries"        , &opt.ntry         , cmd_number_inf},
    { "useproxy"     , &opt.use_proxy    , cmd_boolean},
    { "useragent"    , NULL              , cmd_spec_useragent},
    ...
};

代码用块区分

  class FrontendServer {
    public:
        FrontendServer();
        void ViewProfile(HttpRequest* request);
        void OpenDatabase(string location, string user);
        void SaveProfile(HttpRequest* request);
        string ExtractQueryParam(HttpRequest* request, string param);
        void ReplyOK(HttpRequest* request, string html);
        void FindFriends(HttpRequest* request);
        void ReplyNotFound(HttpRequest* request, string error);
        void CloseDatabase(string location);
        ~FrontendServer();
};

上面这一段虽然能看，不过还有优化空间：

  class FrontendServer {
    public:
        FrontendServer();
        ~FrontendServer();
        // Handlers
        void ViewProfile(HttpRequest* request);
        void SaveProfile(HttpRequest* request);
        void FindFriends(HttpRequest* request);

        // Request/Reply Utilities
        string ExtractQueryParam(HttpRequest* request, string param);
        void ReplyOK(HttpRequest* request, string html);
        void ReplyNotFound(HttpRequest* request, string error);

        // Database Helpers
        void OpenDatabase(string location, string user);
        void CloseDatabase(string location);
};

再来看一段代码：

  # Import the user's email contacts, and match them to users in our system.
# Then display a list of those users that he/she isn't already friends with.
def suggest_new_friends(user, email_password):
    friends = user.friends()
    friend_emails = set(f.email for f in friends)
    contacts = import_contacts(user.email, email_password)
    contact_emails = set(c.email for c in contacts)
    non_friend_emails = contact_emails - friend_emails
    suggested_friends = User.objects.select(email__in=non_friend_emails)
    display['user'] = user
    display['friends'] = friends
    display['suggested_friends'] = suggested_friends
    return render("suggested_friends.html", display)

全都混在一起，视觉压力相当大，按功能化块：

  def suggest_new_friends(user, email_password):
    # Get the user's friends' email addresses.
    friends = user.friends()
    friend_emails = set(f.email for f in friends)

    # Import all email addresses from this user's email account.
    contacts = import_contacts(user.email, email_password)
    contact_emails = set(c.email for c in contacts)

    # Find matching users that they aren't already friends with.
    non_friend_emails = contact_emails - friend_emails
    suggested_friends = User.objects.select(email__in=non_friend_emails)

    # Display these lists on the page. display['user'] = user
    display['friends'] = friends
    display['suggested_friends'] = suggested_friends

    return render("suggested_friends.html", display)

让代码看起来更舒服，需要在写的过程中多注意，培养一些好的习惯，尤其当团队合作的时候，代码风格比如大括号的位置并没有对错，但是不遵循团队规范那就是错的。

如何写注释

当你写代码的时候，你会思考很多，但是最终呈现给读者的就只剩代码本身了，额外的信息丢失了，所以注释的目的就是让读者了解更多的信息。

应该注释什么

不应该注释什么

这样的注释毫无价值：

  // The class definition for Account
class Account {
    public:
        // Constructor
        Account();
        // Set the profit member to a new value
        void SetProfit(double profit);
        // Return the profit from this Account
        double GetProfit();
};

不要像下面这样为了注释而注释：

  // Find a Node with the given 'name' or return NULL.
// If depth <= 0, only 'subtree' is inspected.
// If depth == N, only 'subtree' and N levels below are inspected.
Node* FindNodeInSubtree(Node* subtree, string name, int depth);

不要给烂取名注释

  // Enforce limits on the Reply as stated in the Request,
// such as the number of items returned, or total byte size, etc. 
void CleanReply(Request request, Reply reply);

注释的大部分都在解释clean是什么意思，那不如换个正确的名字：

  // Make sure 'reply' meets the count/byte/etc. limits from the 'request' 
void EnforceLimitsFromRequest(Request request, Reply reply);

记录你的想法

我们讨论了不该注释什么，那么应该注释什么呢？注释应该记录你思考代码怎么写的结果，比如像下面这些：

  // Surprisingly, a binary tree was 40% faster than a hash table for this data.
// The cost of computing a hash was more than the left/right comparisons.

// This heuristic might miss a few words. That's OK; solving this 100% is hard.

// This class is getting messy. Maybe we should create a 'ResourceNode' subclass to
// help organize things.

也可以用来记录流程和常量：

  // TODO: use a faster algorithm
// TODO(dustin): handle other image formats besides JPEG

NUM_THREADS = 8 # as long as it's >= 2 * num_processors, that's good enough.

// Impose a reasonable limit - no human can read that much anyway.
const int MAX_RSS_SUBSCRIPTIONS = 1000;

可用的词有：

  TODO  : Stuff I haven't gotten around to yet
FIXME : Known-broken code here
HACK  : Adimittedly inelegant solution to a problem
XXX   : Danger! Major problem here

站在读者的角度去思考

当别人读你的代码时，让他们产生疑问的部分，就是你应该注释的地方。

  struct Recorder {
    vector<float> data;
    ...
    void Clear() {
        vector<float>().swap(data); // Huh? Why not just data.clear()? 
    }
};

很多C++的程序员啊看到这里，可能会想为什么不用 data.clear()来代替 vector.swap，所以那个地方应该加上注释：

  // Force vector to relinquish its memory (look up "STL swap trick")
vector<float>().swap(data);

说明可能陷阱

你在写代码的过程中，可能用到一些hack，或者有其他需要读代码的人知道的陷阱，这时候就应该注释：

  void SendEmail(string to, string subject, string body);

而实际上这个发送邮件的函数是调用别的服务，有超时设置，所以需要注释：

  // Calls an external service to deliver email.  (Times out after 1 minute.)
void SendEmail(string to, string subject, string body);

全景的注释

有时候为了更清楚说明，需要给整个文件加注释，让读者有个总体的概念：

  // This file contains helper functions that provide a more convenient interface to our
// file system. It handles file permissions and other nitty-gritty details.

总结性的注释

即使是在函数内部，也可以有类似文件注释那样的说明注释：

  # Find all the items that customers purchased for themselves.
for customer_id in all_customers:
    for sale in all_sales[customer_id].sales:
        if sale.recipient == customer_id:
            ...

或者按照函数的步进，写一些注释：

  def GenerateUserReport():
    # Acquire a lock for this user
    ...
    # Read user's info from the database
    ...
    # Write info to a file
    ...
    # Release the lock for this user

很多人不愿意写注释，确实，要写好注释也不是一件简单的事情，也可以在文件专门的地方，留个写注释的区域，可以写下你任何想说的东西。

注释应简明准确

前一个小节讨论了注释应该写什么，这一节来讨论应该怎么写，因为注释很重要，所以要写的精确，注释也占据屏幕空间，所以要简洁。

精简注释

  // The int is the CategoryType.
// The first float in the inner pair is the 'score',
// the second is the 'weight'.
typedef hash_map<int, pair<float, float> > ScoreMap;

这样写太罗嗦了，尽量精简压缩成这样：

  // CategoryType -> (score, weight)
typedef hash_map<int, pair<float, float> > ScoreMap;

避免有歧义的代词

  // Insert the data into the cache, but check if it's too big first.

这里的 it's有歧义，不知道所指的是 data还是 cache，改成如下：

  // Insert the data into the cache, but check if the data is too big first.

还有更好的解决办法，这里的 it就有明确所指：

  // If the data is small enough, insert it into the cache.

语句要精简准确

  # Depending on whether we've already crawled this URL before, give it a different priority.

这句话理解起来太费劲，改成如下就好理解很多：

  # Give higher priority to URLs we've never crawled before.

精确描述函数的目的

  // Return the number of lines in this file.
int CountLines(string filename) { ... }

这样的一个函数，用起来可能会一头雾水，因为他可以有很多歧义：

”” 一个空文件，是0行还是1行？
“hello” 只有一行，那么返回值是0还是1？
“hello\n” 这种情况返回1还是2？
“hello\n world” 返回1还是2？
“hello\n\r cruel\n world\r” 返回2、3、4哪一个呢？

所以注释应该这样写：

  // Count how many newline bytes ('\n') are in the file.
int CountLines(string filename) { ... }

用实例说明边界情况

  // Rearrange 'v' so that elements < pivot come before those >= pivot;
// Then return the largest 'i' for which v[i] < pivot (or -1 if none are < pivot)
int Partition(vector<int>* v, int pivot);

这个描述很精确，但是如果再加入一个例子，就更好了：

  // ...
// Example: Partition([8 5 9 8 2], 8) might result in [5 2 | 8 9 8] and return 1
int Partition(vector<int>* v, int pivot);

说明你的代码的真正目的

  void DisplayProducts(list<Product> products) {
    products.sort(CompareProductByPrice);
    // Iterate through the list in reverse order
    for (list<Product>::reverse_iterator it = products.rbegin(); it != products.rend();
            ++it)
        DisplayPrice(it->price);
    ... 
}

这里的注释说明了倒序排列，单还不够准确，应该改成这样：

  // Display each price, from highest to lowest
for (list<Product>::reverse_iterator it = products.rbegin(); ... )

函数调用时的注释

看见这样的一个函数调用，肯定会一头雾水：

  Connect(10, false);

如果加上这样的注释，读起来就清楚多了：

  def Connect(timeout, use_encryption):  ...

# Call the function using named parameters
Connect(timeout = 10, use_encryption = False)

使用信息含量丰富的词

  // This class contains a number of members that store the same information as in the
// database, but are stored here for speed. When this class is read from later, those
// members are checked first to see if they exist, and if so are returned; otherwise the
// database is read from and that data stored in those fields for next time.

上面这一大段注释，解释的很清楚，如果换一个词来代替，也不会有什么疑惑：

  // This class acts as a caching layer to the database.

简化循环和逻辑

流程控制要简单

让条件语句、循环以及其他控制流程的代码尽可能自然，让读者在阅读过程中不需要停顿思考或者在回头查找，是这一节的目的。

条件语句中参数的位置

对比下面两种条件的写法：

  if (length >= 10)
while (bytes_received < bytes_expected)

if (10 <= length)
while (bytes_expected > bytes_received)

到底是应该按照大于小于的顺序来呢，还是有其他的准则？是的，应该按照参数的意义来

运算符左边：通常是需要被检查的变量，也就是会经常变化的
运算符右边：通常是被比对的样本，一定程度上的常量

这就解释了为什么 bytes_received < bytes_expected比反过来更好理解。

if/else的顺序

通常， if/else的顺序你可以自由选择，下面这两种都可以：

  if (a == b) {
    // Case One ...
} else {
    // Case Two ...
}

if (a != b) {
    // Case Two ...
} else {
    // Case One ...
}

或许对此你也没有仔细斟酌过，但在有些时候，一种顺序确实好过另一种：

正向的逻辑在前，比如 if(debug)就比 if(!debug)好
简单逻辑的在前，这样 if和 else就可以在一个屏幕显示 - 有趣、清晰的逻辑在前

举个例子来看：

  if (!url.HasQueryParameter("expand_all")) {
    response.Render(items);
    ...
} else {
    for (int i = 0; i < items.size(); i++) {
        items[i].Expand();
    }
    ... 
}

看到 if你首先想到的是 expand_all，就好像告诉你“不要想大象”，你会忍不住去想它，所以产生了一点点迷惑，最好写成：

  if (url.HasQueryParameter("expand_all")) {
    for (int i = 0; i < items.size(); i++) {
        items[i].Expand();
    }
    ... 
} else {
    response.Render(items);
    ... 
}

三目运算符(?:)

  time_str += (hour >= 12) ? "pm" : "am";

Avoiding the ternary operator, you might write:
    if (hour >= 12) {
        time_str += "pm";
    } else {
        time_str += "am";
}

使用三目运算符可以减少代码行数，上例就是一个很好的例证，但是我们的真正目的是减少读代码的时间，所以下面的情况并不适合用三目运算符：

  return exponent >= 0 ? mantissa * (1 << exponent) : mantissa / (1 << -exponent);

if (exponent >= 0) {
    return mantissa * (1 << exponent);
} else {
    return mantissa / (1 << -exponent);
}

所以只在简单表达式的地方用。

避免使用do/while表达式

  do {
    continue;
} while (false);

这段代码会执行几遍呢，需要时间思考一下， do/while完全可以用别的方法代替，所以应避免使用。

尽早return

  public boolean Contains(String str, String substr) {
    if (str == null || substr == null) return false;
    if (substr.equals("")) return true;
    ...
}

函数里面尽早的return，可以让逻辑更加清晰。

减少嵌套

  if (user_result == SUCCESS) {
    if (permission_result != SUCCESS) {
        reply.WriteErrors("error reading permissions");
        reply.Done();
        return;
    }
    reply.WriteErrors("");
} else {
    reply.WriteErrors(user_result);
}
reply.Done();

这样一段代码，有一层的嵌套，但是看起来也会稍有迷惑，想想自己的代码，有没有类似的情况呢？可以换个思路去考虑这段代码，并且用尽早return的原则修改，看起来就舒服很多：

  if (user_result != SUCCESS) {
    reply.WriteErrors(user_result);
    reply.Done();
    return;
}
if (permission_result != SUCCESS) {
    reply.WriteErrors(permission_result);
    reply.Done();
    return;
}
reply.WriteErrors("");
reply.Done();

同样的，对于有嵌套的循环，可以采用同样的办法：

  for (int i = 0; i < results.size(); i++) {
    if (results[i] != NULL) {
        non_null_count++;
        if (results[i]->name != "") {
            cout << "Considering candidate..." << endl;
            ...
        }
    }
}

换一种写法，尽早return，在循环中就用continue：

  for (int i = 0; i < results.size(); i++) {
    if (results[i] == NULL) continue;
    non_null_count++;

    if (results[i]->name == "") continue;
    cout << "Considering candidate..." << endl;
    ... 
}

拆分复杂表达式

很显然的，越复杂的表达式，读起来越费劲，所以应该把那些复杂而庞大的表达式，拆分成一个个易于理解的小式子。

用变量

将复杂表达式拆分最简单的办法，就是增加一个变量：

  if line.split(':')[0].strip() == "root":

//用变量替换
username = line.split(':')[0].strip() 
if username == "root":
    ...

或者这个例子：

  if (request.user.id == document.owner_id) {
    // user can edit this document...
}
...
if (request.user.id != document.owner_id) {
// document is read-only...
}

//用变量替换
final boolean user_owns_document = (request.user.id == document.owner_id);
if (user_owns_document) {
    // user can edit this document...
}
...
if (!user_owns_document) {
    // document is read-only...
}

逻辑替换

1) not (a or b or c) <–> (not a) and (not b) and (not c)
2) not (a and b and c) <–> (not a) or (not b) or (not c)

所以，就可以这样写：

  if (!(file_exists && !is_protected)) Error("Sorry, could not read file.");

//替换
if (!file_exists || is_protected) Error("Sorry, could not read file.");

不要滥用逻辑表达式

  assert((!(bucket = FindBucket(key))) || !bucket->IsOccupied());

这样的代码完全可以用下面这个替换，虽然有两行，但是更易懂：

  bucket = FindBucket(key);
if (bucket != NULL) assert(!bucket->IsOccupied());

像下面这样的表达式，最好也不要写，因为在有些语言中，x会被赋予第一个为 true的变量的值：

  x = a || b || c

拆解大表达式

  var update_highlight = function (message_num) {
    if ($("#vote_value" + message_num).html() === "Up") {
        $("#thumbs_up" + message_num).addClass("highlighted");
        $("#thumbs_down" + message_num).removeClass("highlighted");
    } else if ($("#vote_value" + message_num).html() === "Down") {
        $("#thumbs_up" + message_num).removeClass("highlighted");
        $("#thumbs_down" + message_num).addClass("highlighted");
    } else {
        $("#thumbs_up" + message_num).removeClass("highighted");
        $("#thumbs_down" + message_num).removeClass("highlighted");
    }
};

这里面有很多重复的语句，我们可以用变量还替换简化：

  var update_highlight = function (message_num) {
    var thumbs_up = $("#thumbs_up" + message_num);
    var thumbs_down = $("#thumbs_down" + message_num);
    var vote_value = $("#vote_value" + message_num).html();
    var hi = "highlighted";

    if (vote_value === "Up") {
        thumbs_up.addClass(hi);
        thumbs_down.removeClass(hi);
    } else if (vote_value === "Down") {
        thumbs_up.removeClass(hi);
        thumbs_down.addClass(hi);
    } else {
        thumbs_up.removeClass(hi);
        thumbs_down.removeClass(hi);
    }
}

变量与可读性

消除变量

前一节，讲到利用变量来拆解大表达式，这一节来讨论如何消除多余的变量。

没用的临时变量

  now = datetime.datetime.now()
root_message.last_view_time = now

这里的 now可以去掉，因为：

并非用来拆分复杂的表达式
也没有增加可读性，因为`datetime.datetime.now()`本就清晰
只用了一次

所以完全可以写作：

  root_message.last_view_time = datetime.datetime.now()

消除条件控制变量

  boolean done = false;
while (/* condition */ && !done) {
    ...
    if (...) {
        done = true;
        continue; 
    }
}

这里的 done可以用别的方式更好的完成：

  while (/* condition */) {
    ...
    if (...) {
        break;
    } 
}

这个例子非常容易修改，如果是比较复杂的嵌套， break可能并不够用，这时候就可以把代码封装到函数中。

减少变量的作用域

我们都听过要避免使用全局变量这样的忠告，是的，当变量的作用域越大，就越难追踪，所以要保持变量小的作用域。

  class LargeClass {
    string str_;
    void Method1() {
        str_ = ...;
        Method2();
    }
    void Method2() {
        // Uses str_
    }
    // Lots of other methods that don't use str_ 
    ... ;
}

这里的 str_的作用域有些大，完全可以换一种方式：

  class LargeClass {
    void Method1() {
        string str = ...;
        Method2(str); 
    }
    void Method2(string str) {
        // Uses str
    }
    // Now other methods can't see str.
};

将 str通过变量函数参数传递，减小了作用域，也更易读。同样的道理也可以用在定义类的时候，将大类拆分成一个个小类。

不要使用嵌套的作用域

  # No use of example_value up to this point.
if request:
    for value in request.values:
    if value > 0:
        example_value = value 
        break

for logger in debug.loggers:
    logger.log("Example:", example_value)

这个例子在运行时候会报 example_value is undefined的错，修改起来不算难：

  example_value = None
if request:
    for value in request.values:
        if value > 0: example_value = value 
        break

if example_value:
    for logger in debug.loggers:
    logger.log("Example:", example_value)

但是参考前面的 消除中间变量准则，还有更好的办法：

  def LogExample(value):
    for logger in debug.loggers:
        logger.log("Example:", value)

    if request:
        for value in request.values:
            if value > 0:
                LogExample(value)  # deal with 'value' immediately
                break

用到了再声明

在C语言中，要求将所有的变量事先声明，这样当用到变量较多时候，读者处理这些信息就会有难度，所以一开始没用到的变量，就暂缓声明：

  def ViewFilteredReplies(original_id):
    filtered_replies = []
    root_message = Messages.objects.get(original_id) 
    all_replies = Messages.objects.select(root_id=original_id)
    root_message.view_count += 1
    root_message.last_view_time = datetime.datetime.now()
    root_message.save()

    for reply in all_replies:
        if reply.spam_votes <= MAX_SPAM_VOTES:
            filtered_replies.append(reply)

    return filtered_replies

读者一次处理变量太多，可以暂缓声明：

  def ViewFilteredReplies(original_id):
    root_message = Messages.objects.get(original_id)
    root_message.view_count += 1
    root_message.last_view_time = datetime.datetime.now()
    root_message.save()

    all_replies = Messages.objects.select(root_id=original_id) 
    filtered_replies = []
    for reply in all_replies:
        if reply.spam_votes <= MAX_SPAM_VOTES:
            filtered_replies.append(reply)

    return filtered_replies

变量最好只写一次

前面讨论了过多的变量会让读者迷惑，同一个变量，不停的被赋值也会让读者头晕，如果变量变化的次数少一些，代码可读性就更强。

一个例子

假设有一个页面，如下，需要给第一个空的 input赋值：

  <input type="text" id="input1" value="Dustin">
<input type="text" id="input2" value="Trevor">
<input type="text" id="input3" value="">
<input type="text" id="input4" value="Melissa">
...
var setFirstEmptyInput = function (new_value) {
    var found = false;
    var i = 1;
    var elem = document.getElementById('input' + i);
    while (elem !== null) {
        if (elem.value === '') {
            found = true;
            break; 
        }
        i++;
        elem = document.getElementById('input' + i);
    }
    if (found) elem.value = new_value;
    return elem;
};

这段代码能工作，有三个变量，我们逐一去看如何优化， found作为中间变量，完全可以消除：

  var setFirstEmptyInput = function (new_value) {
    var i = 1;
    var elem = document.getElementById('input' + i);
    while (elem !== null) {
        if (elem.value === '') {
            elem.value = new_value;
            return elem;
        }
        i++;
        elem = document.getElementById('input' + i);
    }
    return null;
};

再来看 elem变量，只用来做循环，调用了很多次，所以很难跟踪他的值， i也可以用 for来修改：

  var setFirstEmptyInput = function (new_value) {
    for (var i = 1; true; i++) {
        var elem = document.getElementById('input' + i);
        if (elem === null)
            return null;  // Search Failed. No empty input found.
        if (elem.value === '') {
            elem.value = new_value;
            return elem;
        }
    }
};

重新组织你的代码

分离不相关的子问题

工程师就是将大问题分解为一个个小问题，然后逐个解决，这样也易于保证程序的健壮性、可读性。如何分解子问题，下面给出一些准则：

看看这个方法或代码，问问你自己“这段代码的最终目标是什么？”
对于每一行代码，要问“它与目标直接相关，或者是不相关的子问题？”
如果有足够多行的代码是处理与目标不直接相关的问题，那么抽离成子函数

来看一个例子：

  ajax_post({
    url: 'http://example.com/submit',
    data: data,
    on_success: function (response_data) {
        var str = "{\n";
        for (var key in response_data) {
            str += "  " + key + " = " + response_data[key] + "\n";
        }
        alert(str + "}");
        // Continue handling 'response_data' ...
    }
});

这段代码的目标是发送一个 ajax请求，所以其中字符串处理的部分就可以抽离出来：

  var format_pretty = function (obj) {
    var str = "{\n";
    for (var key in obj) {
        str += "  " + key + " = " + obj[key] + "\n";
    }
    return str + "}";
};

意外收获

有很多理由将 format_pretty抽离出来，这些独立的函数可以很容易的添加feature，增强可靠性，处理边界情况，等等。所以这里，可以将 format_pretty增强，就会得到一个更强大的函数：

  var format_pretty = function (obj, indent) {
    // Handle null, undefined, strings, and non-objects.
    if (obj === null) return "null";
    if (obj === undefined) return "undefined";
    if (typeof obj === "string") return '"' + obj + '"';
    if (typeof obj !== "object") return String(obj);
    if (indent === undefined) indent = "";

    // Handle (non-null) objects.

    var str = "{\n";
    for (var key in obj) {
        str += indent + "  " + key + " = ";
        str += format_pretty(obj[key], indent + " ") + "\n"; }
    return str + indent + "}";
};

这个函数输出：

  {
    key1 = 1
    key2 = true
    key3 = undefined
    key4 = null
    key5 = {
        key5a = {
            key5a1 = "hello world"
        }
    }
}

多做这样的事情，就是积累代码的过程，这样的代码可以复用，也可以形成自己的代码库，或者分享给别人。

业务相关的函数

那些与目标不相关函数，抽离出来可以复用，与业务相关的也可以抽出来，保持代码的易读性，例如：

  business = Business()
business.name = request.POST["name"]

url_path_name = business.name.lower()
url_path_name = re.sub(r"['\.]", "", url_path_name) 
url_path_name = re.sub(r"[^a-z0-9]+", "-", url_path_name) 
url_path_name = url_path_name.strip("-")
business.url = "/biz/" + url_path_name

business.date_created = datetime.datetime.utcnow() 
business.save_to_database()

抽离出来，就好看很多：

  CHARS_TO_REMOVE = re.compile(r"['\.']+")
CHARS_TO_DASH = re.compile(r"[^a-z0-9]+")

def make_url_friendly(text):
    text = text.lower()
    text = CHARS_TO_REMOVE.sub('', text) 
    text = CHARS_TO_DASH.sub('-', text) 
    return text.strip("-")

business = Business()
business.name = request.POST["name"]
business.url = "/biz/" + make_url_friendly(business.name) 
business.date_created = datetime.datetime.utcnow() 
business.save_to_database()

简化现有接口

我们来看一个读写cookie的函数：

  var max_results;
var cookies = document.cookie.split(';');
for (var i = 0; i < cookies.length; i++) {
    var c = cookies[i];
    c = c.replace(/^[ ]+/, '');  // remove leading spaces
    if (c.indexOf("max_results=") === 0)
        max_results = Number(c.substring(12, c.length));
}

这段代码实在太丑了，理想的接口应该是这样的：

  set_cookie(name, value, days_to_expire);
delete_cookie(name);

对于并不理想的接口，你永远可以用自己的函数做封装，让接口更好用。

按自己需要写接口

  ser_info = { "username": "...", "password": "..." }
user_str = json.dumps(user_info)
cipher = Cipher("aes_128_cbc", key=PRIVATE_KEY, init_vector=INIT_VECTOR, op=ENCODE)
encrypted_bytes = cipher.update(user_str)
encrypted_bytes += cipher.final() # flush out the current 128 bit block
url = "http://example.com/?user_info=" + base64.urlsafe_b64encode(encrypted_bytes)
...

虽然终极目的是拼接用户信息的字符，但是代码大部分做的事情是解析python的object，所以：

  def url_safe_encrypt(obj):
    obj_str = json.dumps(obj)
    cipher = Cipher("aes_128_cbc", key=PRIVATE_KEY, init_vector=INIT_VECTOR, op=ENCODE) encrypted_bytes = cipher.update(obj_str)
    encrypted_bytes += cipher.final() # flush out the current 128 bit block
    return base64.urlsafe_b64encode(encrypted_bytes)

这样在其他地方也可以调用：

  user_info = { "username": "...", "password": "..." }
url = "http://example.com/?user_info=" + url_safe_encrypt(user_info)

分离子函数是好习惯，但是也要适度，过度的分离成多个小函数，也会让查找变得困难。

单任务

代码应该是一次只完成一个任务

  var place = location_info["LocalityName"];  // e.g. "Santa Monica"
if (!place) {
    place = location_info["SubAdministrativeAreaName"];  // e.g. "Los Angeles"
}
if (!place) {
    place = location_info["AdministrativeAreaName"];  // e.g. "California"
}
if (!place) {
    place = "Middle-of-Nowhere";
}
if (location_info["CountryName"]) {
    place += ", " + location_info["CountryName"];  // e.g. "USA"
} else {
    place += ", Planet Earth";
}

return place;

这是一个用来拼地名的函数，有很多的条件判断，读起来非常吃力，有没有办法拆解任务呢？

  var town    = location_info["LocalityName"];               // e.g. "Santa Monica"
var city    = location_info["SubAdministrativeAreaName"];  // e.g. "Los Angeles"
var state   = location_info["AdministrativeAreaName"];     // e.g. "CA"
var country = location_info["CountryName"];                // e.g. "USA"

先拆解第一个任务，将各变量分别保存，这样在后面使用中不需要去记忆那些繁长的key值了，第二个任务，解决地址拼接的后半部分：

  // Start with the default, and keep overwriting with the most specific value. var second_half = "Planet Earth";
if (country) {
    second_half = country; 
}
if (state && country === "USA") {
    second_half = state; 
}

再来解决前半部分：

  var first_half = "Middle-of-Nowhere";
if (state && country !== "USA") {
    first_half = state; 
}
if (city) {
    first_half = city;
}
if (town) {
    first_half = town; 
}

大功告成：

  return first_half + ", " + second_half;

如果注意到有 USA这个变量的判断的话，也可以这样写：

  var first_half, second_half;
if (country === "USA") {
    first_half = town || city || "Middle-of-Nowhere";
    second_half = state || "USA";
} else {
    first_half = town || city || state || "Middle-of-Nowhere";
    second_half = country || "Planet Earth";
}
return first_half + ", " + second_half;

把想法转换成代码

要把一个复杂的东西解释给别人，一些细节很容易就让人产生迷惑，所以想象把你的代码用平实的语言解释给别人听，别人是否能懂，有一些准则可以帮助你让代码更清晰：

用最平实的语言描述代码的目的，就像给读者讲述一样
注意描述中关键的字词
让你的代码符合你的描述

下面这段代码用来校验用户的权限：

  $is_admin = is_admin_request();
if ($document) {
    if (!$is_admin && ($document['username'] != $_SESSION['username'])) {
        return not_authorized();
    }
} else {
    if (!$is_admin) {
        return not_authorized();
    } 
}
// continue rendering the page ...

这一段代码不长，里面的逻辑嵌套倒是复杂，参考前面章节所述，嵌套太多非常影响阅读理解，将这个逻辑用语言描述就是：

  有两种情况有权限：
1、你是管理员(admin)
2、你拥有这个文档
否则就没有权限

根据描述来写代码：

  if (is_admin_request()) {
    // authorized
} elseif ($document && ($document['username'] == $_SESSION['username'])) {
    // authorized
} else {
    return not_authorized();
}
// continue rendering the page ...

写更少的代码

最易懂的代码就是没有代码！

去掉那些没意义的feature，也不要过度设计
重新考虑需求，解决最简单的问题，也能完成整体的目标
熟悉你常用的库，周期性研究他的API

最后

还有一些与测试相关的章节，留给你自己去研读吧，再次推荐此书：

英文版：《The Art of Readable Code》
中文版：编写可读代码的艺术

IT瘾艺术推荐

agentic coding 本质上是文档管理的艺术

超预期寿命：长寿的科学与艺术

长连接网关技术专题(四)：爱奇艺WebSocket实时推送网关技术实践

1、引言

2、专题目录

3、旧方案存在的技术痛点

4、新方案的技术目标

5、新方案的技术选型

6、新方案的实现思路

6.1 系统架构

6.2 会话管理

6.3 监控与报警

7、新方案的性能压测

8、新方案的实际应用案例

9、写在最后

附录：更多相关技术资料

千人万面奇妙自见：爱奇艺短视频推荐技术中多兴趣召回技术的演变

导 语

01技术背景：如何召回“好苗子”，打破信息茧房

02聚类多兴趣召回

03MOE多兴趣召回

04单激活多兴趣召回

05总结与展望

OCR技术在爱奇艺的应用实践及演进

爱奇艺短视频分类技术解析

简介

技术难点

分类体系复杂

需要文本、图像、生态信息等多模态特征综合判断

解决方案

特征表示模块

02

图像表示

层次分类模块

爱奇艺短视频打标签技术解析

案例

效果说明

总结/延伸

评审的艺术——谈谈现实中的代码评审

如何看待艺术家在展览上泄露 34 万武汉人的个人信息？ - 知乎

[酷工作] [爱奇艺-成都] 招聘：技术总监（算法方向）/算法工程师

关于青少年艺术教育讲座的文字记录

前沿技术是否前沿？爱奇艺首席科学家揭秘视链技术

申请艺术院校的10个建议-By Lucy Xue

如何通过几张穿着暴露艺术照片，找到当事人和拍摄地点？

如何独处是一门艺术

领导力是一门艺术，管理是稳固领导力的方法

iOS特辑：那些精美优雅的艺术品应用（上）

Path

Twitter for iPad

Convertbot

Piictu

Weightbot

Gowalla

网络视觉艺术大观

赞！web设计之路！网络视觉艺术发展史概览

编码指南：寻找科学中的艺术

兰花的欺骗艺术

食色诱饵

高风险，高收益？！

进化：骗术升级还是选择“从良”

Less is More，简化的插画艺术

Susan Kare：为 Mac 设计图标的艺术家

[原]程序员编程艺术第二十三~四章：杨氏矩阵查找，倒排索引提取关键词

第二十三、四章：杨氏矩阵查找，倒排索引提取关键词

引言

第二十三章、杨氏矩阵查找

杨氏矩阵查找

第二十四章、倒排索引提取关键词

一般索引（正排索引）

倒排索引

从倒排索引文件中提取关键词

后记

程序员 房屋粉刷匠而非艺术家

Tim Bryce 对程序员的看法

我对Bryce 言论的解析

再看Bryce 的P理论

移动游戏的架构艺术

转：编程的艺术：漂亮的代码和漂亮的软件

导语

程序员房屋粉刷匠而非艺术家

使用含义明确的词，比如用 `download`而不是 `get`，参考以下替换方案：

增加重要的细节，比如变量的单位 `_ms`，对原始字符串加 `_raw`

合理使用 `_`、 `-`等符号，比如对私有变量加 `_`前缀。

使用 `min`、 `max`代替 `limit`

使用 `first`和 `last`来表示闭区间

使用 `beigin`和 `end`表示前闭后开(2,9))区间