敏捷开发之我见

入职 ThoughtWorks 后,公司邮箱曾收到一篇内部博客大赛的文章《真正的敏捷工作流 —— GitHub flow》,我心想“我一个 GitHub 公民应该会很适应 TW 吧”?

果然…… 不要立 flag……

敏捷不是什么

大多数人对敏捷开发的理解主要停留在 ——

敏捷开发周期短
瀑布开发周期长

而我觉得,更本质的区别在于 ——

敏捷是灵活的,拥抱变化
瀑布是死板的,宁可一无所成,也绝不“犯错”

但我在 TW 前两个项目的工作中发现,一些小伙伴把敏捷实践奉为金科玉律,不容改变……

陷入技术争论

CORS 重不重要?

来 TW 的第一个项目是个内部中台项目,虽然迭代 1 的需求很简单,但创始人们一开始就志在推广到公司各团队,甚至独立对外出售或开源,前后端分离的架构迟早要面对跨域问题。后端从一开始就开启 HTTP CORS 会极大地方便前端开发,各大后端框架也早就有成熟的中间件来一键化处理,比如 Node.JS 的 Koa 框架 ——

  1. 安装中间件
npm install @koa/cors
  1. 启用中间件
import Koa from 'koa';
import CORS from '@koa/cors';

new Koa().use(CORS());

一分钟搞定!即便 Java、Spring 写法繁琐一点,一刻钟够不够?

但我和同为新入职员工的 M 君一同向 Java 后端主程建议此事,他却以多种理由拒绝 ——

  1. 前端 webpack 自己先代理一下(之前代理出了一些罕见 bug,否则我们不会提出早开跨域)
  2. CORS 可能引起 CSRF 等安全问题(两者根本风马牛不相及,不懂的自己 Google)
  3. CORS 优先级不高,应该先抓紧做功能
  4. 敏捷提倡代码集体所有制,若这个点对你真的很重要,我们没时间但你有时间,你可以直接去改(若本项目是 Node.JS 后端,我一人 JavaScript 前后端一把梭,还真不用麻烦你)

结果就这么简单一事儿,用各种理由和我俩争执一上午,代码都没写就吃午饭了…… 说好的“着急做卡”呢?

【八卦】第二天 M 君就以“个人身体原因”为由退出项目组,直到他离职前才私下告诉我“CORS 这么常识的事儿都如此争执,后面坑少不了”……

原生标准好不好?

随后,令我和 M 君更加意外的是,一起加入第一个正式项目后,遇到了更多没必要的争执……

需求 我们的方案 领导的要求 领导的评价 我们的看法
全局异常捕获(后置拦截) unhandledreject 事件(后置拦截) Axios 拦截器(前置拦截) “你们怎么把代码改成这个鬼样子” 对合适但不常见的用法有偏见
分行列展示几项数据 <table />(符合语义化规范,每列自动对齐) <div /> + flex 模拟表格列对齐 “table 太老了,我们的用户也没有盲人” 看重“时髦”甚于无障碍规范
文字罗列多个名词 Intl.ListFormat 依数量自适应中文标点、连词 array.join('、') “你这个我看不懂,我们没那么先进” 书面文书写规范不重视
处理 HTTP 请求 async + await 解决冗长的“回调地狱” Redux Saga 生成器 + 自定义回调 “Saga 唯一的缺点就是‘样板代码’多” “重复代码多”违背编程消除重复的本质

一个 Web 国际标准通常历经三步走才发布 ——

  1. 一线开发者多年实践总结出标准提案
  2. 各大浏览器厂商尝试实现,提出改进意见
  3. W3C 标准委员会综合全球其它会员厂商意见

上述业界领袖们多年争执后推出的正式标准,没有理由再在团队内部争执“该不该用”。我写这块代码我先用了新标准,你写那块暂时没用,都无可厚非,不影响大局。

Code review 本是交流技术的契机,不是用来争执“看不看得顺眼”的。

开卡、关卡必须 BA、QA、UX、Dev 全到齐

多数故事卡的 UI 设计并无不清楚的细节,项目设计师又经常没时间,如不灵活变通,卡一直开不了或关不上,让 Dev 一直被阻塞,拖累了项目进度。

而当 Dev 想先尝试写一下新卡的代码,却被告知“必须先开卡,否则做了后面 BA 改需求就要返工”,但敏捷实践不就要求“较大需求变更本迭代不做,要放到下个迭代的新卡”吗?若真到开卡时大量返工,那是 BA 的错误,与 Dev 无关。

长此以往,对于 Dev 个人

主观上不能尽其所能地写代码,消磨工作积极性;客观上白白增加了其做卡的时长,对其本人评价不利。

技术会议一言堂

M 君离职前提议项目组前端要统一设计规范,后端主程便召集大家开会讨论,他提议全面封装出一套项目乃至公司的组件库,如 ——

<tw-button>
  # shadow-root
  <vant-button />
</tw-button>

我则补充道:

过于简单的组件不需再封装一层,直接用现有组件库的即可,否则对开发、运行都增加负担。

但双方争执不下,于是民主投票,其他人都赞同后端主程。

几日后正式开发,

S 君突然说:“我们还是每个组件都再封装一层吗?”
一个附和道:“没必要了吧?”
另一个也点头默许……

对于前文中项目伊始我和 M 君提出的“Saga 样板代码多”问题,S 君后来接触那一块代码时也私下向领导提出同样的疑问。

如此看来,我和 M 君有时并不是看起来“不好合作”,只是

多数人在众人和领导面前 —— 不敢讲真话

Code review? Code rejected!

每天下午的代码回顾会的一般步骤是

  1. 该项目的前后端各自预定地点,集体开会
  2. 每人照着 Git 变更记录,轮流讲解自己一天所写代码的来龙去脉
  3. 其他人可随时提出意见,经探讨达成一致修改方案后记录在案
  4. 检查前一天的修改方案是否实施

但这个民主的议程,实际运行得似乎并不太民主 ——

  • 组长的代码 组员有异议的,若组长不赞同,有时就一笔带过、不予记录
  • 组员的代码 组长有异议的,即使组长没能有理有据地说服组员,组长也会记录在案
  • 组长对组员一些变量/函数命名等有异议,组员问组长和大家,无人说得出更好的建议,但组长依然要求该组员修改
  • 对于上述争议问题,组员事后没有修改,便被定性为“不重视 code review”

可话说回来,既然敏捷开发是代码集体所有制,相持不下之际,谁有异议谁去改就好了,追着组员去改一点都不敏捷……

沟多通少

敏捷重视沟通与反馈,但实践起来也有不尽如人意的地方 ——

问题 建议
凡事都要开会商量 能用简洁代码国际标准解决的就不开会
多人多次反复拉通上下文 简洁文档自动化办公工具
大小会议经常严重超时 有人开始注意力不集中了说明要精简了

在入职不久后的“反馈文化”培训会上,一位人事小姐姐说:“看似很大的沟通成本,TW 认为这种民主的过程是值得的。”

但社会上大有人在的“保守派”就是一直揪着民主的效率问题为独裁统治辩护、站台的!民主人士必须用更好的方法论更新的技术手段去解决 ——

太长不看,太久不听,太繁不做……

但凡有人对上述繁琐、低效的沟通表现出一丝不悦,可能就会被同僚视为 —— 态度不好,难以融入团队!

其实不限于交朋友、谈恋爱,人与人的沟通都可在短短几句话中判断“能否懂得起”。虽说所有问题在充足的时间内都可解决,但与其“你说东,我说西”迟迟不能共识,不如

先尝试做起来,用事实说话会更清楚、更高效~

用 Linux 和 Git 之父 Linus Torvalds 的名言就是 ——

Talk is cheap, show me the code!

俗话也说得好 ——

懂得起的人不用解释,懂不起的不必解释~

不敏捷的感受

如果每个员工都以“按点上下班,卖身领工资”的心态去工作,只要不加班,敏不敏捷、高不高效“与我何干”?才不着急上火呢!悠哉悠哉不好吗?

但凡希望在日复一日的“搬砖”之余做些更有意义的事的人,多半焦躁不堪、疲惫不已。写过代码的都知道,状态差时就是在“写 bug”……

于是,在第一个正式项目的迭代 1 结束时,M 君再次主动离开,并且是彻底的 —— 离职……

他走前的一句话我一时不解其意 ——

我之前创业时虽然练就了善于沟通的能力,但我现在很讨厌沟通……

那时前文所述的种种才经历了不到一半,当全部经历后,我才明白 ——

讨厌的不是沟通,而是不必要的低效沟通

在 M 君离职的同时,我和上司有次长谈,其间我提了个问题 ——

ThoughtWorks 有没有可能至少在某个局部,存在一定程度的表面和谐

她坚定地给了我否定的答案……


转载请注明: TechQuery 敏捷开发之我见

上一篇
结构化简历数据 结构化简历数据
参加工作久了,经历公司多了,每次换工作写简历都烦得要死 —— 常用招聘网站更新简历:简历编辑器改版了,操作习惯大变不说,数据格式很多也对不上号 注册新招聘网站填简历:所需内容和之前其它网站差不多,但填法大相径庭 所以,虽说每次只加一项前
2019-08-14
下一篇
Web 与 Chrome 最新进展 @Google I/O 2019 Web 与 Chrome 最新进展 @Google I/O 2019
Google I/O 2019 extend 成都站 DOM 与 BOM 延迟加载<img src="path/to/image" loading="lazy" /> <iframe src="path/to/page"
2019-05-15