孤尽
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: 最后还有什么话, 想和大家分享?
忽悠是把我不相信的东西说给大家听, 而信念是把我相信的用行动传递给大家我相信手册的愿景是码出高效, 码出质量, 码出未来, 帮助到更多的人希望我们开发同学, 能够觉得开发是一件幸福的事情, 开发是一件有创造力的事情, 开发是一件能够改变世界的事情, 而不是为了争论不休的规范, 影响了算法效率和架构设计的优雅性
最后提前祝大家新春快乐, 也期待未来能与大家有更多交流学习的机会
来源: https://yq.aliyun.com/articles/458752