江苏龙网

  1. 首页 > 资讯 > 科技 > >

|饿了么4年，阿里2年：我的总结与思考( 二 )


放大到将链路画到业务场景里 ， 突出业务逻辑和上下游交互 ， 缩小到某一次调用的处理逻辑大致是怎样 ， 数据是怎么变化 。
经常画图 ， 不用纠结形式和标准 ， 重要的是形成自己理解系统的一个框架 ， 一个自己的思维方式 ， 需要的时候可以随时拿出来用 。
日常不管是聊需求还是做系统设计 ， 习惯性的把图画出来 ， 就达成了一半 。 剩下的一半就要看图去想、去找问题 。
技术债务
永远不要骗自己说 ， 现在为了这个需求先挖一个坑 ， 过一段时间再来填(重构or重做) 。
技术债务和金融债务一样 ， 它必然存在 ， 并且会像无赖一样一直赖着 ， 隔三差五会爆发一下 。
随着时间的推移和业务的发展 ， 你会发现架构越来越混乱 ， 不同系统的领域边界越来越模糊 ， 系统和需求与组织关系的映射越来越复杂 ， 服务内编码风控越来越不一致 ， 重复的轮子一个接一个隐蔽的出现 。
“太忙了没时间梳理哪些问题”、“改那些问题需要上下游一起改 ， 费时费力 ， 推不动”、“现在还没出问题 ， 而且正在整理了 ， 别催” 。 这是我们经常会听到的声音 。
其实 ， 技术同学多少都有点代码洁癖 ， 有很多问题不处理不是主观的原因 ， 而是客观上因为精力、时间、ROI 等因素 ， 往往要等问题真的爆发后 ， 大家才能狠下心去处理那些问题。
我以前处理技术债务的思路 ， 是要有一个检查清单 ， 我会定期的复盘所有的系统 ， 并且结合自己团队和其他团队的事故去全量扫雷 。
系统本身是一个平衡的产物 ， 是时间、功能、风险、未来可能性等几个方向平衡的结果 。
所以技术债务对于研发同学的考验 ， 不在于你怎么在日常工作中保证系统技术债为 0 ， 而是你要评估清楚在有限的资源和时间下 ， 哪些问题是刻不容缓的 ， 哪些问题是可以往后放的 。
很难想象一个没有技术追求的团队能开发出一个健壮的、可维护性好、可扩展性好的系统 。
相反 ， 这种业务代码的堆砌 ， 从短期看也许是“较快”实现了业务需求 ， 但是从长远来看 ， 这种烂系统的增加会极大地阻碍业务的发展 ， 形成一个个的黑洞应用 ， 而工程师被裹挟在业务需求和烂系统之间 ， 疲于应对 ， 心力交瘁 。
这种将就将导致系统腐化堕落 ， 技术债越垒越高 ， 丑陋的代码疯狂滋长 ， 像肿瘤一样消耗你所有的能量 ， 最后还要你的命 。
警惕大项目
并不是所有人都有能力操盘大项目 ， 也不是所有人都能够平衡好交付压力、上线质量、产品逻辑以及时间窗口 。
这是一个非常有挑战的工作 ， 需要纯粹的技术能力之外的很多软性能力来辅助 ， 比如组织的沟通协作能力、向上要权要责的能力、平衡产品业务期望的的能力、突发情况应急转变的能力等 。
越大的项目对于 Owner 的要求也越高 ， 真能把大项目做好不怎么留大坑的少之又少 。
大项目从启动到立项所用的时间很多时候是远超项目实际的开发周期的 ， 项目的顺利推进需要“妥协” ， 但项目的成功需要坚持 。
很多项目之所以失败 ， 是在做的过程中方方面面不断妥协 ， 最后做出来的东西已经远离了最开始想要的样子 。
业务层面
除了技术之外 ， 研发同学对业务层面也需要提升认知与重视 。
对于研发而言 ， 业务就像是外语 ， 你不理解业务就好比人在异国 ， 与周围的环境格格不入 ， 并且容易吃亏!
相比产品、业务、运营等其他工种 ， 技术更喜欢和技术打交道 ， 业务在大多数同学眼中是混沌且缺少秩序的 ， 没有技术那样清晰的实现路径和稳定共识的知识结构 。
并且技术相对容易证伪 ， 而业务往往就是不停的尝试 ， 研发都讨厌“不确定性” 。
但是在一个庞大的组织里想把技术做好 ， 就必然要与业务打交道 ， 毕竟业务才是一家公司存在的核心价值 。


推荐阅读


上一篇：中国家电网|求真实验室：洗碗机能洗锅吗？

下一篇：科技蟹|官宣！RedmiBook16英特尔版