image from pixabay.com 静态类型正在逐渐成为潮流， 2010 年之后诞生的几门语言 Go、Rust、TypeScript 等都走了静态类型路线。 过往流行的一些动态语言（Python、PHP、JavaScript）也在积极引入语言新特性（Type Hint、TypeScript）对静态类型增强。 我曾使用 Python 开发规模较大的项目，感受过动态语言在工程规模变大时候带来的困难： 在重构阶段代码回归成本异常之高，很多历史代码不敢动。 后来技术栈转到 Java，被类型系统怀抱让人产生安全感。 ...
随着业务规模扩大、团队组成变复杂，如何降低项目实施风险，降低软件复杂度变得尤为关键。 我从 Martin Flower、Joel Spolsky（软件随想录 作者） 等巨匠智慧中寻找解决复杂工程之道，其中 Code Review 是行之有效手段。 我认同 Code Review 价值也是忠实执行者。 加入蚂蚁以后，我在所接触项目中都大力推广 Code Review。 感谢团队信任和支持，目前 CR 协作进展顺利， 项目 CR 从最早不主动，到现在形成基于模块 Owner 制度 CR 和 Peer Review。 我也曾经在 3 个月内处理完成 700 多个 Pull Request，并在 PR 讨论中中都留下一些有价值讨论。 这里我将自己对 Code Review 一些理解记录下来。 ...
2019 年 9 月摄于巴厘岛 和老友聚餐时候完了一个游戏，大家各自找了一个词形容自己的 2019。我用的词是「累」和「平凡」。 2019 关键词：累和平凡 2019 没有进入生门。 加入阿里之后，组织像榨汁机一样将个体精力榨干。 工作日几乎没有自己的时间。这样画面经常出现：回到酒店先倒头趴一会，然后洗完澡看眼儿子视频就睡觉，醒来又是新的循环。 周末的时间则是交给了家人，今年母亲身体抱恙，我尽量每月都能回一趟老家，以至于陪伴儿子的时间所剩无几。 ...
在阿里，我们不得不承认一个事实：前端的确有价值，但放在全局来看，前端产生的价值并非核心价值。 在阿里，虽然前端的工作已 经不可或缺，但对大公司而言，不可或缺的岗位多了去呢，不可或缺不代表有核心价值，我就不说了。 - 玉伯 2013 年 阿里前端的困局与突围 image from Abbey Arches Architecture - Free photo on Pixabay 和 G 总论道 前几天和某大厂前端负责人 G 聊职业生涯发展，聊着聊着就谈到了前端和后端职业天花板。 我表达了自己观点：后端职业天花板更高，这是由职能细分决定。 后端（服务端）概念比较宽泛，常见分类可以有应用开发工程师、中间件工程师、甚至可以包含运维、数据工程师、算法工程师。 本文我只将后端工程师限定在应用开发工程师以及衍生的框架、库开发工程师。 前端这边由于引入大前端概念，概念也比较广，包含：Web 前端、移动端（iOS + Android 客户端）、桌面端（PC 端）。 我们也限定在这几个方向的应用开发。 ...
图片摄于北京圆明园 怎么描述 2018？我找了三个关键词。 2018 忙、拥抱变化、新生 我的 2018 年从北京拉开帷幕，1 月份时候团队几个小伙伴一起去给北京研发中心同学做了一次技术分享。 TL 余老师带我们三个架构师逛了圆明园，北京小伙伴热情招待我们吃了东来顺火锅。 在天津时候还第一次从海河冰面渡河。只是没想到，这次旅行成了我在沪江最后一次团建， 当时我已经有一些想法离开沪江，一些问题逐步暴露出来： 沪江工作舒适、做事情自由，但技术上缺乏量级挑战，制度上内部流程僵化，部门利益关系错综复杂。 我深信业务、技术是互相引领促进，在这种环境下无法全力施展拳脚。 ...
最近有一位朋友和我聊职业发展方向问题，聊了不少 DevOps 和 SRE 话题。 我几年前刚接触这两个概念时也常常将之混淆，可惜当时没有人来解答我困惑。 现在这虽然已经极为流行，但是我发现我这位朋友对这两个职位还存在一些误区。 于是我给了一些见解并整理成文章以饕大众。 最常见的误区： DevOps 新概念，好高级哦 SRE 是高级版 DevOps 运维可以轻松转身 DevOps 工程师 让我一一给你讲解吧。 image via YouTube DevOps 和 SRE 定义 DevOps 是字面上 Dev 开发 / Ops 运维两者组合， 严格意义上 DevOps 如下（via DevOps - Wikipedia）： ...
image from Wikipedia 八卦 随着孩子预产期临近，我还有一个重要的任务没有完成：给孩子起一个名字。 这本来是个随性的任务，但是由于上一辈笃信某个算命先生的姓名测试算法，让这个任务难度倍增。 我根据一些古文取了不少名字，但是最后都败在姓名测试上面：得分不高。得分不高老一辈就要有说辞， 我自己就是一个活生生案例，曾用名得分不高，中考被逼换了名字，改头换面重新做人。 我根据韵律取的名字几乎都败在算分数上面，我得琢磨一下其中奥秘，提高取名效率，避免再出现差错。 不少网站都提供姓名测试算命，我且先看看上面的得分，研究一下规律： ...
该系列三篇文章已经全部完成： 从 SQL Server 到 MySQL（一）：异构数据库迁移 - Log4D 从 SQL Server 到 MySQL（二）：在线迁移，空中换发动机 - Log4D 从 SQL Server 到 MySQL（三）：愚公移山 - 开源力量 - Log4D 我们用了两章文章 从 SQL Server 到 MySQL（一）：异构数据库迁移 / 从 SQL Server 到 MySQL（二）：在线迁移，空中换发动机 介绍我们遇到问题和解决方案。 不管是离线全量迁移还是在线无缝迁移， 核心 ETL 工具就是 yugong。 Yugong 是一个成熟工具， 在阿里巴巴去 IOE 行动中起了重要作用， 它与 Otter / Canal 都是阿里中间件团队出品。 它们三者各有分工： Yugong 设计目标是异构数据库迁移； Canal 设计用来解决 MySQL binlog 订阅和消费问题； Otter 则是在 Canal 之上，以准实时标准解决数据库同步问题。 Otter 配备了相对 yugong 更健壮管理工具、分布式协调工具， 从而长期稳定运行。Yugong 设计目标则是一次性迁移工作，偏 Job 类型。 当然 yugong 本身质量不错，长期运行也没问题。 我们有个产线小伙伴使用我们魔改后 yugong， 用来将数据从管理平台同步数据到用户前台，已经稳定跑了半年多了。 ...
该系列三篇文章已经全部完成： 从 SQL Server 到 MySQL（一）：异构数据库迁移 - Log4D 从 SQL Server 到 MySQL（二）：在线迁移，空中换发动机 - Log4D 从 SQL Server 到 MySQL（三）：愚公移山 - 开源力量 - Log4D （image via https://pixabay.com/en/military-stealth-bomber-refueling-602729/ ） 在上篇文章 从 SQL Server 到 MySQL （一）：异构数据库迁移 - Log4D 中，我们给大家介绍了从 SQL Server 到 MySQL 异构数据库迁移的基本问题和全量解决方案。 全量方案可以满足一部分场景的需求，但是这个方案仍然是有缺陷的： 迁移过程中需要停机，停机的时长和数据量相关。 对于核心业务来说，停机就意味着损失。 比如用户中心的服务，以它的数据量来使用全量方案，会导致迁移过程中停机若干个小时。 而一旦用户中心停止服务，几乎所有依赖于这个中央服务的系统都会停摆。 ...
（图片来自 The Dead Sea, Israel | One of the lowest, saltiest and unusu… | Flickr） 最近听团队老大的一个分享，介绍公司提倡的工程师的核心价值观，受益良多。 这也让我想起了一篇文章， Bruce F. Webster 在 2008 年写了一篇文章「The Wetware Crisis: the Dead Sea effect」， 翻译过来是「死海效应」。 Bruce 在文章中阐述了一个概念：一个团队可能陷入一种反模式，称之为死海效应。 死海是位于约旦的一个高盐分水域，由于水分被蒸发，这里的盐度是正常海水的 8 倍。 将水分比喻为高质量人才，盐分比喻为低质量人才。 水分容易被蒸发，而补入不足，盐分不容易蒸发日积月累，进而导致整个团队的人才质量劣化。 ...