从码农到工匠:程序员的质量修炼之道

作者/分享人:蔡建斌
向 Ta 提问
技术总监,十年敏捷软件开发经验。合著《敏捷开发一千零一夜》;译著《Elasticsearch服务器开发 第二版》。走进一个软件研发经理的日常,这里我们聊需求,技术,敏捷,架构,流程,设计,代码,质量, 运维, 团队…… 我的每次分享,除了内容本身,更希望塑造你对软件开发的思考模型和价值观。技术都是短暂的,价值观永存。

年底加薪时,你是想被老板告知一个百分比?还是想告知老板一个百分比并且给他个理由?程序员的价值在哪?在日新月异的 IT 行业,我们在终身学习的路上有什么是能够积累下来并对我们持续增值的?

答案也许不止一个,但质量无疑是其中之一。做出好东西,才是公司对我们最终的期待。

本 Chat 是讲师十余年码农生涯的经验总结和提炼,带来关于质量的思维体系和价值观,包括:

  • 什么是质量圈,有哪些不同维度的质量
  • 如何度量、提升程序员的产出质量
  • 如何与团队中其它角色配合,系统性地提升产品质量
  • 如何平衡速度与质量

适合对象:

  • 对自己有更高期望的程序员
  • 对自己的程序员团队有更高期望的管理者
  • 需要跟程序员打交道的 IT 从业者
已有270人预订
预订达标
文章出炉
交流日期
     
04月18日
05月02日
05月08日 20:30
查看文章评论/提问
拆弹小能手
作为技术人员,充分理解产品经理设计的功能背后的真实用户需求,然后提出技术代价小的替代方案,我们责无旁贷。
sunny
作为团队QA我要说 你做到了影响力 读了几遍 好文章 顺便问一句 请QA吃的那顿饭呢 😄
蔡建斌: 先记账,存着
weichye
大多数观点是都赞同,但“码谈”那段,每个小时提交一次,而且似乎指的是提交到develop branch ,我觉得不太妥当。这会带来两个问题,第一,完整的user story 未必能在一个迭代里做完,这样就要在迭代结束时硬着头皮上部分功能,如果不上,再拆出来太痛苦了,第二,这样的模式似乎回到了svn的时代,在出现regression issue 的时候会花很多时间。而且基于时刻重构的思想,写着的时候函数名称变化,而别人已经迁出使用但未签入,也会造成一些低效和费时排查的问题吧
蔡建斌: 据我了解,最极端的不是提交到develop分支,而是直接提交到唯一的master分支。这种“单一分支”对团队的要求高,或者说在小的团队比较容易实现,之前Ruben负责的前端项目就做到了这一点。关于你的第一点,“特性开关”是必须的,它把部署和发布分开,部署是技术选择,发布是业务选择,这是持续交付的关键实践之一。第二点没太看懂,抱歉哈
潇雨
慢工出细活,好文值得反复读!工匠级的代码往往也不是一气呵成的,长期追求付诸实践积累经验,通过重构反复雕琢。
你可能还喜欢
高并发、低 RT 的风控系统架构及技术架构的实现
火币集团研发中心
程序员副业赚钱的 8 种模式
安晓辉
全栈开发入门实战:后台管理系统
鲁鹏
每一个开发人员都应该懂的 UML 规范
码匠笔记
不写代码:程序员最重要的技能 [英文版]
Chat 三人行
“花式吊打”系列之逻辑回归讲透透
天马行空
微信扫描登录
关注提示×
扫码关注公众号,获得 Chat 最新进展通知!
添加小助手微信×