项目名不要叫base、basic
打个比方，一个公司在建设初期，公司技术人员十几个。架构师就按照具体情况给了个适合当前情况的SOA(面向服务架构)设计：分成4个业务模块，将共用部分提取出一个公共模块basic。后来公司越做越好，越做越大。公司技术人员增长了5倍。于是4个业务模块和basic模块成了5个团队。
现在basic团队面临着一个巨大挑战：业务上不属于4个业务模块领域内、或者和其他业务模块2个以上模块领域上都沾边不太好区分到底是哪个领域的。通通被交给basic团队来开发维护。basic团队很忙很累，苦不堪言。但是拒绝接这些需求都没有借口：谁叫你是basic，就该你做！
但是basic团队忙忙碌碌，实际只是承担了其他团队一些数据模型维护、其他一些不能独立成为一个产品的工作。最终的产品成果归其他团队。没有业绩。于是basic团队同事纷纷跳槽。
现在怎么办呢？重新招人呗。结果新招来的人很负责的通读了自己要维护的代码，发现不知道自己的代码在干什么。代码没人敢改，没人敢动。
上头看着不行，想将这个模块的功能按照领域驱动的思想划分到各个领域去维护，功能代码没团队敢接……
这是在很多大公司很多部门都发生过的真实事件，血泪的教训。所以我建议你的项目千万不要叫base、basic之类包罗万象的词。
那有人问：我们正处于这么一个初期阶段，上头非要我们做一个通用基础模块，我们怎么办？我的建议是该做的照样做，名字宁愿叫“盖娅”也别叫basic。盖娅是希腊神话里的超原始神，是众神之母，本身含有基础的意思。但是只要不叫basic，等到领域划分的时候只要可以自圆其说还是有希望把边界理清楚的。叫basic就哭吧。
不能只提问题不说解决方法。对于这种应用，改造迫在眉睫的时候。不建议用重构来解决，逻辑改动的风险不可预估。建议另起炉灶重做功能，把里面的功能清晰价值大的做一个抽象升级，给新接入和正在改造的接入方使用。老系统不动，让其渐渐失去生命力直到最后可完全下线。
避免随手优化
世界上有很多事情是反直觉的：一个努力上进的开发小姐姐，每天晚上10点多急匆匆的合上电脑去赶末班地铁；而他们公司的前台小姐姐逛了一天的某宝，5点下班从容的走进一辆法拉利812。但是，开发小姐姐感觉每天充实快乐，前台小姐姐感觉自卑空虚。
忘记上面的例子，不是重点。重点是我们通常以为看到代码写的不好，愿意花时间做优化是件好事，实际上反而是危险的。
假如我们看到某个代码，明显有逻辑错误，想随手改改。你就要考虑一件事情：这段明显有问题的代码为什么在线上运行着没有人来报bug？有一种正常运行叫做【负负得正】。如果把错误的逻辑改对了反而可能引起问题。
遇到开发小哥哥改并非之前需求和技术方案中涉及的代码，出于技术追求不堪忍受太烂代码的，我代码评审的时候，手都是瑟瑟发抖，反复的在拿捏影响。对于未开始动手优化，在看这篇文章的你，我的建议是：避免随手优化。
有的朋友说，那看着这些代码【破窗户】(破窗户形容已经开始变坏的代码任由放着继续变坏)就放着不管了？如果觉得很有必要改，可以提出来讨论，作为一个专门的优化事项，评估好风险与收益，做一个完善的方案再行动，避免好心办坏事。
【冷却期】设计
上面是银行卡转账的一个截图。上面有个大家经常用的功能：输入短信验证码。要知道每发送一条短信都是要给短信代理公司交钱的。不仅如此，如果短信发送过于频繁，会导致排队。很久才能收到。或者等的花儿都谢了也收不到。所以现在的短信发送一般会设置60s的冷却期。
但是延迟还是不可避免。所以发信短信内部一定要做异步哦。同步等结果的话，怕是系统一天挂好几次。
60s还收不到现在这个时代也还是会经常出现的。那就再点次发送。结果这次收到了两条。问题来了，谁是最新的？两个都让用户输入试试这个用户体验，想必用户留存率会大打折扣。
所以现在会在发送短信验证码同时发送核对序号，只需要输入序号相同的验证码。
除了发短信，对于其他宝贵资源的使用和申请，比如IP申请，都可以使用【冷却期】设计来解决可能造成的资源浪费问题。
相关阅读
扫一扫
286
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
