背景:PPT之痛
年末,又到了很多朋友准备答辩晋升 slides 的时候。PPT工程
应该是很多技术人的天敌之一,不少人为了在工作之余折腾出一份既有内容又美观的 slides 弄得焦头烂额。
其实,大家对 PPT工程
之所以这么惶恐,主要是因为技术人更习惯跟代码打交道,更习惯用技术思维去解决问题。而做材料考察的是信息的提取整合能力、审美品味以及口头表达能力,而这些都不是做技术的必要条件。
然而,也不必对使用 slides 答辩过于深恶痛绝,它只是一个用来说你的故事的工具:我们不应该被工具所束缚,而应该把它用好,将它变成你的优势。我私下里也看过不少同事的答辩材料,发现了一个很有趣的现象:往往内容非常好的材料,美观度也很高,看起来赏心悦目。而内容一般的材料,排版、美观度也比较糟糕,缺乏美感。工程师的素养,在做 slides 花的心思上面也能够体现出来。
Read More
我是在 2015 年 5 月 20 日离开的百度,次日就来到了平安。当时平安的这个团队叫做移动开发二队。在百度的最后一天,我在朋友圈发了张合照,写了句“再见,我爱你”。很多人不理解我为什么在百度干了一年就走了,而且去的是平安这个并不以技术见长的公司。其实原因很简单:跟对的团队做对的事情。
说是“对的事情”是因为平安正处于技术转型期,其间会有大量的技术需求可以放手去做。而来平安这个团队的首要任务是开发完善底层的技术框架,有机会接触比较核心的技术,这对我的技术成长很有好处。
说是“对的团队”是因为我对平安这个团队的了解。平安那边的老大锋哥也是原先我们百度 LBS 团队的研发 leader,而 leader 定一也是之前在百度的时候合作非常愉快的一个同事。再加上鑫哥 @ASCE1885 每周一更的技术周报,让我觉得这个团队是非常尊重技术的团队,而我过去应该能有更多发挥的机会。
于是,在锋哥的几次劝说下,我来到了平安。时间过得很快,一转眼的功夫,我也已经在平安待了两年的时间。从团队初建,到发展壮大,我和这个团队携手共同成长。对平安,对金融壹账通,对这个团队,我有说不尽的感激。如今我即将告别平安,走向一段新的旅程。在启程之前,我想对这两年走过的路做一个回顾。
我这两年的工作基本是两条线的思路:主线任务保证做得漂亮,然后主动从日常工作中找问题和需求,做点支线任务。
Read More
毫无疑问,Git 非常适合用于代码文件的版本控制。对于纯代码仓库,由于每次实际提交都是增量内容,即使仓库经历了几十次提交,整个仓库的大小往往都不会大幅增加。
而对于存在二进制文件的仓库,情况就变了:Git 并不能很好地支持二进制文件的增量提交,每次更新一个二进制文件,就相当于把这份文件的完整内容再往仓库里扔。久而久之,这个仓库就会变得非常大,影响代码拉取速度。
举一个实际的例子,为了加快应用的构建速度,我们团队的框架先会编译成 SDK ,再交由上层构建应用。框架 SDK 也是一个独立的 Git 仓库,里头包含了大量的二进制包:
由于框架也有多个分支,每个分支的迭代速度比较快,SDK 仓库的体积在三个月的时间内就膨胀到了 1G 。
Read More
需求描述
在继续写数学系列前,我想切回去之前的 Git 系列写点东西。我想写系列文章也可以像操作系统的进程调度一样,一个系列暂时写不动了,先 保存现场
跳去另一个 topic 写点东西,同时也给自己留点 buffer 再酝酿一下这个暂时 中断
的系列。等这个系列酝酿够了,再 恢复现场
,继续还这个系列的技术债。
对于一个规模较大的企业,存在多个 Gitlab 站点是很常见的事情。
比如,我们团队在公司发布统一的 Gitlab 之前早已经搭了一个团队用的 Gitlab ,当公司开始推 Git 时,由于我们已经对自己团队的 Gitlab 做了大量的定制,因此并不打算迁移到公司的 Gitlab 。
自己搭建 Gitlab 的好处是可以随心所欲的进行定制,像加远程钩子之类的东西想加就加。但缺点就是平台的维护成本也落到了自己身上。相比之下,公司 Gitlab 则没有什么维护成本,服务的稳定性由更专业的运维人员保证,也不用考虑扩容的问题,但灵活定制就别想了。如果能够实现 Gitlab 间的数据自动同步,我们可以没有顾忌的使用自己的 Gitlab 平台,一旦出现问题,再无痛迁移到公司的 Gitlab 。这样一方面避免了单点问题,节省了维护成本;另一方面也能尽可能保证灵活可定制。本文想讨论的就是多个 Gitlab 站点间的数据同步问题。
Read More
说到版本控制,就不得不提到分支管理策略。就像学开车必须学学交通规则。分支管理策略是代码版本控制的基础组成部分。为团队定制一套合适的分支管理策略,就好比制定了一套合理的交通规则,可以让团队的代码的更加有序地演进,尽可能降低多分支带来的复杂度,并避免由于分支混乱引发的各种“车祸”。本文将简单讨论下我们在开发过程中尝试的各种分支管理策略,在面对各种复杂场景下呈现的优势与不足,以及我们的妥协和后续期望。
Github-Flow
作为 Github 的重度用户,我首先考虑的当然是 Github-Flow 。
Github-Flow 是一种非常简单的分支管理方案。它的流程只有如下几步:
- 拉出一个新分支;
- 在新分支上进行修改,并提交和推送你的改动;
- 发起一个 Pull Request ,向代码管理员申请将你提交的分支合并到原来的分支;
- 讨论并接受 Code Review。在这个过程中,你依然可以继续推送新的代码到你的开发分支上,并且新的提交在推送后会出现在未完成合并的 Pull Request 页面中;
- 合并和发布。Review 通过后,代码管理员将该分支合并到原来的主分支上。
Read More