CSDNTB|饿了么四年、阿里两年：研发路上的一些总结与思考( 二 )
日常不管是聊需求还是做系统设计 ， 习惯性的把图画出来 ， 就达成了一半 。 剩下的一半就要看图去想、去找问题 。
? 3. 技术债务
永远不要骗自己说 ， 现在为了这个需求先挖一个坑 ， 过一段时间再来填（重构 or 重做） 。
技术债务和金融债务一样 ， 它必然存在 ， 并且会像无赖一样一直赖着 ， 隔三差五会爆发一下 。 随着时间的推移和业务的发展 ， 你会发现架构越来越混乱 ， 不同系统的领域边界越来越模糊 ， 系统和需求与组织关系的映射越来越复杂 ， 服务内编码风控越来越不一致 ， 重复的轮子一个接一个隐蔽的出现 。
“太忙了没时间梳理哪些问题”、“改那些问题需要上下游一起改 ， 费时费力 ， 推不动”、“现在还没出问题 ， 而且正在整理了 ， 别催” 。 这是我们经常会听到的声音 。 其实 ， 技术同学多少都有点代码洁癖 ， 有很多问题不处理不是主观的原因 ， 而是客观上因为精力、时间、ROI等因素 ， 往往要等问题真的爆发后 ， 大家才能狠下心去处理那些问题。
我以前处理技术债务的思路 ， 是要有一个检查清单 ， 我会定期的复盘所有的系统 ， 并且结合自己团队和其他团队的事故去全量扫雷 。 系统本身是一个平衡的产物 ， 是时间、功能、风险、未来可能性等几个方向平衡的结果 。 所以技术债务对于研发同学的考验 ， 不在于你怎么在日常工作中保证系统技术债为0 ， 而是你要评估清楚在有限的资源和时间下 ， 哪些问题是刻不容缓的 ， 哪些问题是可以往后放的 。
很难想象一个没有技术追求的团队能开发出一个健壮的、可维护性好、可扩展性好的系统 。 相反 ， 这种业务代码的堆砌 ， 从短期看也许是“较快”实现了业务需求 ， 但是从长远来看 ， 这种烂系统的增加会极大地阻碍业务的发展 ， 形成一个个的黑洞应用 ， 而工程师被裹挟在业务需求和烂系统之间 ， 疲于应对 ， 心力交瘁 。 这种将就将导致系统腐化堕落 ， 技术债越垒越高 ， 丑陋的代码疯狂滋长 ， 像肿瘤一样消耗你所有的能量 ， 最后还要你的命 。
? 4. 警惕大项目
并不是所有人都有能力操盘大项目 ， 也不是所有人都能够平衡好交付压力、上线质量、产品逻辑以及时间窗口 ， 这是一个非常有挑战的工作 ， 需要纯粹的技术能力之外的很多软性能力来辅助 ， 比如组织的沟通协作能力、向上要权要责的能力、平衡产品业务期望的的能力、突发情况应急转变的能力等 。 越大的项目对于Owner的要求也越高 ， 真能把大项目做好不怎么留大坑的少之又少 。
大项目从启动到立项所用的时间很多时候是远超项目实际的开发周期的 ， 项目的顺利推进需要“妥协” ， 但项目的成功需要坚持 。 很多项目之所以失败 ， 是在做的过程中方方面面不断妥协 ， 最后做出来的东西已经远离了最开始想要的样子 。
业务层面
除了技术之外 ， 研发同学对业务层面也需要提升认知与重视 。
对于研发而言 ， 业务就像是外语 ， 你不理解业务就好比人在异国 ， 与周围的环境格格不入 ， 并且容易吃亏！相比产品、业务、运营等其他工种 ， 技术更喜欢和技术打交道 ， 业务在大多数同学眼中是混沌且缺少秩序的 ， 没有技术那样清晰的实现路径和稳定共识的知识结构 。 并且技术相对容易证伪 ， 而业务往往就是不停的尝试 ， 研发都讨厌“不确定性” 。 但是在一个庞大的组织里想把技术做好 ， 就必然要与业务打交道 ， 毕竟业务才是一家公司存在的核心价值 。
? 1. 基于业务规划做技术规划
很多同学习惯于把计划等同于规划 。 阿里是一家尊重技术的商业公司 ， 所有的团队都在谈业务、规划里是业务规划、周报里是业务项目、汇报里是业务成果、晋升的时候也要突出你的“战功” 。 相比技术本身 ， 大家更关注技术改变了什么 ， 在业务部分聊技术团队如何做规划的原因就在于此 ， 这是公司运营的的起点（目的） ， 延伸出来才有具体的技术规划和组织设计作为解决方案 。
推荐阅读
- IT新经济|饿了被指利用虚假价格手段诱骗交易遭罚25万
- 中年|回忆四年前在日本的美好时光
- 中新经纬|创指创逾四年半新高！两市成交额连续四日超1.5万亿
- 澎湃新闻|小米金融与山东小米金融商标纠纷达四年，后者涉嫌非吸被查
- 投资时报|再报亏损！深交所拍了拍贝因美：为何连亏四年？资金链有没紧张？
- |巨人网络四年腾挪曲线收购Playtika 将增厚业绩
- 界面新闻|【图解】深成指创四年来新高，10.1亿资金打板中国中免
- 郎酒|郎酒四度谋求上市，负债率超茅台两倍，四年后将和茅台平起平坐？
- 中国科技新闻网|贝因美年报被问询：扣非净利连续四年为负
- 金波财经|外卖行业被夸大？月入万不是梦？饿了么：月收入上涨！