当你思考选择什么方案的时候
Posted 小章鱼哥
tags:
篇首语：本文由小常识网(cha138.com)小编为大家整理，主要介绍了当你思考选择什么方案的时候相关的知识，希望对你有一定的参考价值。
我最近在维护一个非常重要而且非常老的一套代码。
比较没有兴致，既接触不到什么前沿的技术，老的代码还那么晦涩难懂，加起需求还要小心翼翼，有点不想上心。
今天早上，老大突然说：你把你昨天日报里写的你碰到那个问题，今天过来跟我讲一下，你是怎么想的。
惊！
老大要跟我讨论我的问题了。
然后我屁颠屁颠的过去。把我遇到的问题说了。
老大竟然一边就听懂了，然后很耐心地跟我讲了他的思路，不得不说，茅塞顿开呀。
目录
需求
画了个图：
需求：要求搜索带有记忆功能，上次搜了什么【标签】的内容，这次再搜索的时候，记忆上次搜索的【标签】。
比如，这次用户搜索了小猫，选择了恶搞标签。那么下次选择小狗的时候，希望还是在恶搞标签下。
需求分析
Tab Module可以拿到标签的切换。（其中tabMenu还是框架自带的组件，并没有暴露方法可以去劫持。）
Search Module可以实现页面的跳转。
明显这俩在两个模块里面呦。
当时想出了两个方案：
Tab Module给Search Module通信，让Search Module把之前写死的路由改成通信发过来并缓存下来的路由。Search Module自己缓存上次选中的tab，页面跳转到令Search Module``active的时候，就让它redirect一下，把路由的tab query换掉。
2.明显要pass掉，怎么能到了页面还要redirect一下呢。太hack了。
当时就选择用1.方法。
为什么会有这个迷惑
实际上，项目在设计的时候，在search和page之间，缺失了tab route这一层设计。
tab route的设计，在功能上，应该能控制跳转，拥有小路由的功能，自己有选择展示哪个page的能力。（实际上现在的tabMenu Module没有这个能力，它就是一个page）。
跳出这个需求，实际上，一个好的架构，像我这种小萌新，加起需求来是很顺的，不会有这种迷惑。
老大提示我：如果时间充足，可以把这层tab route加上，一个完整的功能，这些都是要有的。
老大还画了图，帮我分析了一下，加上一个tab route模块之后，数据的流动。并且替我考虑了更多可能需求的情况下，会有什么问题。
最后确定的方案是我之前选择的1.方案的基础上抽象出一个module的方案，我也非常认同。
老大比我思考的角度就是高了不少。
为什么会有这个迷惑 续
回头发现，
其实我之前用的现代化框架，就不会遇到这个问题，
我们现在的tab组件，路由组件丰富，功能强大。
现在化的框架，都越来越方便开发者开发，很多功能完整，用起来舒服。
实际上，它把架构的一些问题帮我们解决了。
所以我们在遇到很老的框架写的程序的时候，我们会蔑视它的用起来不舒服，不自动化，像半成品。
实际上，是我们把很多应该思考的东西，交给现代化框架去做了。
我们缺失了一些宏观的思考。
所以我们觉得写一个业务代码很简单，没什么难的。那是你站在巨人的肩膀上。
不光要多去思考，还要站的高度更高一点吧。
以上是关于当你思考选择什么方案的时候的主要内容，如果未能解决你的问题，请参考以下文章