孤尽
Q：为什么当初会想去做这样一本手册，初心是什么呢？
大家好，很高兴今天能与大家一起交流。要回答这个问题，我想用个例子来解释。
原始社会的争端，更多的是讲究个人的蛮力；三国时代的群雄并起，开始讲究士兵的团队默契；到了现代战争，海陆空、信息兵、工程兵，无不需要紧密配合。软件发展至今，只是靠一句hello world走天下的时代，已经过去了，我们需要团队紧密协作。
代码规约是一种文化软实力，关系着互联网公司规模化生产效率，从这点上讲就是要提升研发效率，提升代码质量。在规约出现之前，一片混沌，如表达删除状态的字段名，非常多，像：delete, delete_flag, is_delete, is_deleted，在数据分析时，总要小心翼翼，像文字游戏。而0/1还是y/n来表示已删除和未删除，更是神坑，极易造成线上问题。再如，批量接口定义时，没有接口保护很容易造成服务提供方内存耗尽，产生OOM等等。
所以，我们的初心是码出高效，码出质量。码是名词，也是动词，希望规约能够提升整个社会的研发协作效率，提升系统质量，提升我们广大程序员编程的幸福感。
Q：手册发布后，受到许多工程师的认可与支持。可以分享一些数据吗？
这本手册的影响力，确实出乎我们所有人的意料之外。据不完全统计，手册推出一周年，影响了全球范围内逾160万人，插件安装数23万+，《手册》纸质版一个月连续增印两次，一直处于热销状态；插件开源不到4个月，已经超过7300star，曾达到周热度排名世界第一；手册插件正式在云效公有云上线；英文版也在海外发布，引起业界广泛关注。
在此期间，业界同仁为我们提供了许多宝贵的建议，在此也非常感谢大家的支持与厚爱。
Q：对于一路陪伴它成长起来的你来说，你觉得最大的挑战是什么？
挑战的主要来源是程序员内心的天马行空和自身价值的不可替代性。
程序员都是天生幻想创造个性化作品的艺术家，变着法子想着要如何与众不同，最好代码只有自己能够看懂，只有自己能够维护。内心深处个人至上的不可替代性，是一个深层次的潜意识抵抗，是最大的阻力来源，没有足够的意识为了遵守团队的代码风格去委屈自己。
但是个性化应尽量表现在代码质量和算法效率的提升上，而不是对于合作规范上纠缠不休的争论。再者，公司是请程序员来产出实际价值的，而不是经常消耗时间为TAB还是空格的事情争得脸红脖子粗的。有时候，就是一个规定，就像交规靠左行，还是右行一样，大家这么做了，协作效率自然就提升了，正所谓无规矩不成方圆，无规范难以协作。
Q：今年手册推出了实体书，怎么会有这样的想法呢？
其实，实体书的推出并非计划之内。在2017年杭州云栖大会，为了方便现场做规约挑战赛，我们精心准备了800本试读本，把网络上公开发布的电子版制订成薄薄的册子，结果现场受到很多童鞋的喜欢，甚至有人愿意出钱收购。
后来我们意识到，尽管有电子版，同学们还是希望能够有实物可以在纸上记录自己的学习心得，在地铁、公交、火车上的碎片化时间内也可以随手翻翻，所以我们把尺寸极大缩小，制订成册，并且独家发布了《设计规约》部分。
为了把实体手册做好，我们做了反复校对，在标点符号、示例代码、字体颜色等都做了认真的审核。到第三次印刷时，也进行了20处的精细修改，我们希望这是一本走向卓越的小册子，是陪伴大家的床头书、工具书。
Q：这本书推出后，你也承担起了“布道者”的角色，带着它和业界童鞋积极交流。可以分享一下你遇到的人或故事吗？
是的，我们非常欣喜地看到，手册受到了广泛的关注和支持，大家都希望它变得更好。苏州微软的一个同学提及错误的示例代码，是关于延迟初始化的问题，我们反复论证，发现《手册》的命名是存在问题，所以在第三次印刷中，我们进行了修改。
另外，也有人觉得设计规约过分量化了。事实上，如果描述为“原则上”，或者说写一个非常宽泛的区间，指导意义也很弱，干脆就写成具体的数字，当然具体的数字，也是从无数的设计案例中抽象出来的。
前段时间有读者问我如何理解<? extends T>和<? super T>的区别，我是这么举例的。好多人看过优酷剧场的《白夜追凶》吧，关宏峰追查他弟弟的悬案时，去查看被封存的证物箱，被明确告知，你只能看，不能动，当然更不可以增加一件新的证物进去，那是在伪造证据，这就是前者，只能读取，不能增加。
那<? super T>在什么样的情况下只能增加，不能读取呢？这个场景似乎更难立体地被想象出来。比如，投票选举代表时，你只能往里投选票。如果自己选错了代表，想从票箱里捞出来，重新投票，这可能吗？更加不可能给你读取票箱元素的机会。有人说，这只是一种生活场景，在系统设计中，很难有这样的情形。那么，我再举例说明一下，我们在填写对于主管的年度评价时，填写完毕提交后，即使填写错误，当你再次访问之前的链接时，也会告诉你：“您已经完成对主管的年度反馈，谢谢参与”，当然更加不可能让你读取到其它成员对于主管的反馈内容。
Q：未来，《手册》还会给大家带来哪些惊喜，可否提前透露一下？
《码出高效——阿里巴巴开发手册详解》即将出版，此书将详细说明规约的初衷和意义、编写和推广历程，每个条目背后的思考与详细的示例代码，以及相应的故障案例分析。当前基本完成了三章的编写，我们希望这本书是深入浅出、言之有物，从实践中来，走向理论，再走向指导实践。
言之有物，物指的是有定义、推导、案例、总结。而深入浅出的深指的是能够在业界领先的深度上，把内容讲深讲透，浅指的是让一个Java初学者都能够看得懂。
Q：情怀，这似乎是一个非常虚的词。但我却听到许多人，用“情怀”来评价这本书。在你眼里，情怀是什么呢？
经常有人问我，编写和推广《手册》如此费心费力，是什么样的信念让我如此执着？
我想说一个自己经历的事：我很喜欢电影《冈仁波齐》，也去过冈仁波齐。转山的那段路，汽车呼啸而过，尘土飞扬，可是转山的藏民，还是那样的虔诚，叩拜之后，即使满脸灰尘，他们的信念依然朴实而笃信。陆川的电影《可可西里》也是，很多事情是因为信念而坚守，现实中为可可西里申遗做过巨大贡献的王欣，毕生都献给了藏羚羊的保护，长年驻守在高原雪域，他无私地付出了很多，也放弃了很多，因为信念而坚持体现出人类的伟大，信念就是一种情怀。
情怀，如果用武侠文化来说，是行侠仗义于江湖，快意潇洒于恩仇，大江南北，侠之大者，为国为民；侠之小者，为红颜，为知己。而技术情怀是什么？它是一种匠心；是追求一年又一年双11业务背后的技术突破，拓展商业边界；是解决问题后客户的认可。
说到底，技术情怀是一个比较虚的词，工程师是偏向于数据驱动的群体，希望能够用数据来量化定义，能够明确符合什么特质，达到什么程度的人，才是具有技术情怀的。我抛一下个人愚见，尝试从三个维度来解读一下技术情怀：热爱、思考、卓越。热爱是一种源动力，而思考是一个过程，而卓越是一个结果。如果给这三个词加一个定语，使技术情怀更加立体、清晰地被解读，那就是奉献式的热爱，主动式的思考，极致式的卓越。
Q：冰冻三尺，绝非一日之寒。这本手册虽小，却是众多工程师平日一点一滴的积累而成。在你平常的工作里，有哪些一直保持的良好编码习惯，可以分享给大家吗？
我很习惯去做摘记，从进入阿里第一天开始，沉淀了近2000页的笔记，分为两个文档，搜集和整理。我会让知识快速进入搜集区，包括听到的、看到的、疑惑的，不断地去思考，不断地去总结之后，将它们沉淀进入整理区。有一些至今没有搞清楚的知识点，在搜集区已经沉淀了多年，依然会不断地去review一下。所以，我对于知识的记忆非常清晰，因为那是不断进行总结、思考、沉淀的结果。
编码的过程也是一种艺术的演绎，对于设计七大原则和架构设计理念的理解，需要充分融入到代码体系中，使代码有灵感，有活力，有创造力。软件设计是一个不断学习，不断实践，不断参悟的反复过程，这个过程可能比较辛苦，也容易缺氧，这个时候，多和身边的良师益友沟通，或许会有“听君一席话，胜读十年书”的感受。
Q：最后还有什么话，想和大家分享？
忽悠是把我不相信的东西说给大家听，而信念是把我相信的用行动传递给大家。我相信手册的愿景是码出高效，码出质量，码出未来，帮助到更多的人。希望我们开发同学，能够觉得开发是一件幸福的事情，开发是一件有创造力的事情，开发是一件能够改变世界的事情，而不是为了争论不休的规范，影响了算法效率和架构设计的优雅性。
最后提前祝大家新春快乐，也期待未来能与大家有更多交流学习的机会。
原文发布时间为：2018-02-9
本文作者：孤尽
本文来自云栖社区合作伙伴“阿里技术”，了解相关信息可以关注“阿里技术”微信公众号
