一名程序员的2017年末总结

眼看着又一年结束,想想今年过的还真是快,上个画面还是去年年末各种处理故障的场景,一眨眼一年就过去了。既然过了一年,还是得留下些思考和展望,否则就有些太无趣了。 还是套用那个老的不能再老的梗吧,the good,the bad and the ugly。 The Good 今年职位从高级码农变成了看上去很忽悠人的”技术专家“,虽然按专家的头衔来说应该做一些更深入的研究工作,不过受限于身体状态一直不好,一认真的思考问题就会头昏脑涨,只好做了很多给团队打杂的工作,所以好的部分大多数不是我个人的贡献,而是团队的功劳。 今年最主要的成果,应该是跟团队一起在很多事情上兑现了之前一直念叨的“应该”。 应该从现在开始做重构,而不是“到时候” 从去年接手团队之后就一直在跟历史代码做斗争,在做了很久看似出工不出活的“代码review”、“重构”、“增加测试”、“删代码”之后终于有了回报:我们的代码质量可以让我们在其中正常工作,不再需要为了一个看似简单的功能而大动干戈的在“屎一样的一大坨代码”里纠结半天了。 我们试过很多办法提升代码质量,包括强制code review、专门抽出时间重构、周会上的代码评审等等。每一种都或多或少的有一些效果,但最有效果的做法是引入自动化的代码风格检查工具,可以发现大部分代码细节问题,并且很容易量化,对于“质量”这种没有实感的东西,量化是能够让你持续投入很重要的一个方面。 而最终的收益不仅是开发效率的提升,更重要的是,一个不断进化的团队中的一员在看到烂代码时,感受到的是“如何解决这些问题”的挑战,而不是”这些代码再也不会好了“的无力感。 应该通过提升开发效率完成工作,而不是靠加班 有代码不断优化的基础,我们也很自然的把服务过渡到了微服务架构。微服务架构让我们能够更敏捷的工作,不再需要忍受单体架构带来的“一个巨大的黑盒”带来的不便,我们可以对性能做更细致的分析,对问题做更精确的定位,对技术选型也有更多自由。在此基础上建立起了持续部署系统终于把上线变成了一件日常工作,“等我5分钟,我review代码的时候发现个bug,上个线就去吃饭”。 我跟很多人谈起这个“5分钟上线”的时候,他们都觉着我是个不负责任的人,并且一遍又一遍的问我:“上线上出问题怎么办?” 问我这个问题的人一定是没有考虑过“复杂度”本身就是一个巨大的问题源,当代码足够简单、依赖足够清晰时,很多问题就自然的消失了。实际上,我们现在的上线次数从每周两次提高到了每天十几次之后,上线产生的问题已经几乎不存在了。 应该通过报警发现问题,而不是用户投诉 我去年用几天写了一个报警系统,团队又在此基础之上建立起了一套特别靠谱的报警服务,不再依靠“检查系统内部有没有问题”,而是站在用户的视角,依靠探测程序检查“用户在使用时是不是有问题”。 站在用户维度报警的好处是,只要有报警,那么就一定有问题。于是我们终于从每天轰炸式的报警短信中脱出身来,不再需要“按报警频率估计服务有没有问题”这种无用的工作,也不需要面对boss“怎么用户都投诉了你们还不知道”的尴尬问题。只要有报警,那么就需要处理;反过来,只要没报警,那么绝大部分用户使用也不会有问题,我可以放心的玩《守望先锋》而不用担心boss会突然来电话。 最终,有惊无险的,我们做到了服务全年无故障(虽然还有几天才过完今年,希望这不是一个flag……)。 应该通过技术解决性能问题,而不是堆机器 微博的访问量极大,做个方案动辄要支持百万并发、千亿数据,但奇葩的是公司又很穷总是买不起新服务器(--),性能优化就变成了极其重要的工作。 我们今年做了不少应用的性能调优,把每个服务的性能指标都提升了几倍(还有几倍是留给明年的KPI的--)。性能调优是一件有挑战又有成就感的事情,而且比较有意思的地方是,无论程序员的水平是好是坏,总是有调优的空间。水平弱一些的同学可以调优业务代码和基本参数;好一些的优化架构和第三方组件;牛逼的可以深入jvm和内核原理。调优经验多了,总会有种“无论怎么优化也到不了头”的感觉。 另外,我们今年基于云服务、容器技术、调度系统、混合云编排系统、容量评估系统和自身的微服务架构体系,实现了公司成本部门老是念叨的的“按需扩缩容”功能,我们的直播互动系统也成为了微博内部首个按流量自动扩缩容的服务,达到了“5分钟完成无人值守自动扩缩容”的状态。在这个系统的帮助下,支撑微博直播互动服务的常备机器只有几台而已,参加技术大会看到有人谈直播架构时,总是莫名的有一种优越感…… 应该做更多有挑战的事情,而不是一直重复自己的工作 今年我们承担了更多微博的业务,我们如今应该算是微博里少有的“后端服务一条龙”团队,一整年来我们都在整合和优化各种服务的架构和链路。从消息箱底层业务,到tcp连接服务,到收件箱后端服务,到直播互动服务,到微博视频服务,到文件存储服务等等,这一年做了不少对原服务进行重写和进行新架构设计的工作。 技术栈的多样化带来的是难以管理和重复性的工作,但是只要对不同的业务稍作抽象,那么就可以复用很多现有的基础设施,抽象和复用的实践多了,就可以称之为体系。今年我们对不同服务的各方面,比如架构、开发框架、运维、监控、报警等等方面做了抽象,建立起了一套体系,使我们不再受技术栈过于发散的困扰。 换句话说,团队一方面享受着大公司的技术积累,一方面又有各种新业务场景带来的技术挑战,这是挺难得的状态。 The Bad 就跟之前说的一样,今年本来想做一些更纯粹的研究工作,比如对操作系统内存模型完整的剖析,或者对性能分析能力的进一步提高,又或者再去qcon之类的技术大会露个脸,但是受限于身体状态,只好作罢。 前两年工作加班的比较猛,经常一搞就到凌晨5,6点。这一年也做了些调整,没再整到过后半夜,下了班就一溜小跑回家玩守……啊不是,回家休息。对团队小伙伴们的要求也是尽量提升效率,少加班。合理的作息和锻炼对于程序员很重要,”身体是革命的本钱“这句话诚不欺我。 今年还有个遗憾就是没能实现“三十岁前用自己写的语言写一个操作系统”的愿望。也忘了这是什么时候定下的“小目标”了,在如今,写个语言其实并不困难,编译器已经是很完善的技术了;写个操作系统也有一大堆从入门到xx系列。但难就难在真的去做,说到做到和觉着自己能做到还是两件事情,希望有机会还是自己动手做一做。 另一方面,对团队来说,还有很多想做但因为新业务太多而没有时间做的事情。比如弱网环境下的文件上传性能优化,微博私有通讯协议的优化,我们团队维护着的开源motan rpc框架对于微服务监控和调度能力的优化,还有最近微博越来越火的视频服务的后端转码服务、存储服务的性能优化,等等等等。这些只能期望来年搞定了。 The Ugly 程序员这个行业里的人大多数人不喜欢交际,我也一样。而实际工作中总有很多需要沟通的工作,而对于这部分工作实在是我的痛点。 而痛苦的来源主要来自于沟通时不在一个频段上, 比如我问”为什么没搞定“,而对方的回答是:“我不会啊”。 又或者我说“这么做的话会更合理”,而对方一直在强调:“我这么做能实现啊”。 再或者我说“这里的需求明显不合理”,而对方只有一句:“老板是这么要求的”。 无论如何,跟人沟通是一件痛苦的事情,尤其是跟与自己三观不合的人沟通更是如此。今年也没少经历过拍桌子大吼的场面。虽然不想承认,但是很多人并不是真的想把事情做好;有一些人的“好”跟你的“好”不是一个衡量体系;有些人虽然意愿很强,但他是笨蛋;当然,还有又懒又笨三观还跟你不一致的…… 如何跟人打交道是我今年反思最多的问题之一,作为一个与世无争(?)的程序员,我希望尽量少跟人起冲突,默默的多写些代码,但又不想自己因为要避免冲突,变成跟他们一样又笨又懒的人,尝试了几次之后发现日剧里那些“靠热情就感染了身边的人”之类的桥段是骗人的(要么就是因为我没长一张男主角的脸),与其苦苦挣扎着期望别人某天突然改变,不如找些志同道合的人在身边。值得欣慰的是,今年招到的小伙伴都是能够认可我的三观,有意愿和能力把事情做的更好的人。

本文参与腾讯云自媒体分享计划,欢迎正在阅读的你也加入,一起分享。

发表于

我来说两句

0 条评论
登录 后参与评论

相关文章

来自专栏PPV课数据科学社区

如何从一开始就设计好数据分析的基本框架

关于数据分析,避免6个错误 1.走得太快,没空回头看路 初创公司里的人们仿佛一直在被人念着紧箍咒:“要么快要么死,要么快要么死。”他们是如此着急于产品开发,以至...

30950
来自专栏华章科技

华章微课堂 | 孙宇熙:大数据时代程序员生存之道

我们先来看一看大数据时代的催化剂。这里显示催化剂其实有三样:社交媒体、移动互联网和物联网。我们先从社交媒体开始,大家知道从20世纪90年代开始,一直到当下,社交...

12520
来自专栏腾讯大讲堂的专栏

写给产品经理和设计师的用户体验知识①

作者:刘涵宇,男,有用户体验设计背景的产品经理。曾辗转于哈尔滨、北京、深圳3个城市学习、工作和生活,目前在腾讯任职。 2014年5月,我在腾讯内部转岗,开始从事...

23850
来自专栏华章科技

张小龙内部分享:我们只做一件事情,产品只有一个定位

张小龙说:“用户要的是你给他提供了什么新的体验。”一起来学习一下张小龙牛掰的产品思维吧。

16410
来自专栏Crossin的编程教室

如何保持学习编程的动力

但话说回来,关注了一阵子我发现,Reddit 上的讨论真要比贴吧不知道高到哪里去了,甚至比不少知乎回答要有价值。而且感觉下面的讨论氛围也更好些。

11230
来自专栏软件测试经验与教训

软件质量浅谈

30470
来自专栏用户3246163的专栏

为什么DDD是设计微服务的最佳实践

在本人的前一篇文章《不要把微服务做成小单体》中,现在很多的微服务开发团队在设计和实现微服务的时候觉得只要把原来的单体拆小,就是微服务了。但是这不一定是正确的微服...

44420
来自专栏达摩兵的技术空间

以用户为中心的设计理论

体验的价格远超过日用品本身。我们无法预知科技会进步到什么状态,但是只有把科技转换成体验的,收费才会非常高。如果只是应用就收费低。比如说指纹识别,在苹果手机出现指...

9020
来自专栏Java架构

如何从三流程序员成长为一名年薪50W的架构师?1.源码分析专题2. 分布式专题3.微服务架构专题4.性能优化专题5.工程化专题6.电商项目实战

20730
来自专栏CSDN技术头条

单单Scrum是不够的

伴随着Scrum的实施,你若想取得长久的成功,需要的可不只是基础的框架。Scrum是故意这么设计的,它提供了框架结构作为起点,而它生来就能与其他的有效模式组合应...

193100

扫码关注云+社区

领取腾讯云代金券