在最近的一段时间，我一直做一件事情。就是把软件设计原则带到前端里面。你们能不能理解是你们的事，我也懒得和喷子理论了。
看看更多做架构的人的结论吧。项目就应该有的设计思维，在ng2里面体现的很极端（DDD模式开发其实可以说ng2早就实现了，等你发掘）
2022年的程序员的口号应该开始：拒绝屎山代码，提高维护性。前人栽树，后人是真的凉。
2022年我更多希望大多数人，提高系统思维，拒绝无效加班。让那些烂代码死去谷底吧。
在我国的程序员开发大多数是这样的一个开发模式，一个新的功能模块给一个人去开发。其他人中途也很少去参与。直到这个人去把组件开发完后，就进行单元测试，然后黑盒子test通过后，就可以部署上线了。
在不就之前，我发布了一篇文章，关于在React里面做了一个策略模式去做渲染组件（随便举一个例子进行讲解，其实实际开发过程中业务比这个复杂多了）。然后发现有那么一些好玩的评论，大概他们还没有理解为什么要这么设计。
如果你想堆代码的话，这文章你可以跳过这篇文章。因为这是给系统设计师看的文章。
我先说说策略模式去渲染组件，为什么我要这么设计。现在的情况是这样的。
一个页面里面有一个显示模块，需要按照不同的人进行显示不同内容模块，如果没有系统设计进行设计的话，按照上面的模式开发，那么大概就是下面的情况。我不管他是用map映射还是什么啦，但是最后的解决要么你维护map还不能做props的迭代更新，或者在if else的屎山代码上堆代码，对于code review的同事来说就是一个恶梦，不过国内也没有多少人是做code review做得好得，因为都是在看你写得规范吗？
在我的团队中，公司安排了一堆毕业生给我，大概7个左右，只有2个中级程序员。毕业生嘛，你想他完整开发一个好的模块，本来项目经验就已经缺乏了，我们做上级的应该需要好好的把控项目进度才对，而不是整个模块丢给一个人来开发，为什么大多数的开发都是丢给一个人开发，还不是因为上级不会设计系统，对模块进行拆分。
我们开发一个新的功能，本应该是下面的模式才对,如果说组件是开发的最小单位，那么每个小的功能实现是模块的最小单位（注意我这里指的是一个人一个文件/避免合并冲突）
但是我们大多数的开发是如下，往一个文件堆代码，code review的同事看了想打人，其他同事共同开发冲突的时候我想哭。
说了这么多基础概念，我开始进入正题，首先我们的团队一开始说了应届毕业生居多。
我最高的那一层做了一个调用,也就这做了new PersonContext(data).renderView()。
function HomePage()
{
const fetchGetQuery = ()=>{
/** * 你自己做的业务逻辑进行判断,然后以后只需要进行维护这一刻的代码，数据建议操作sotre里面，这样你就可以去sotre拿数据，无需要 * 传参数了，当然最好的方式使用rxjs进行监听，这么你的PersionType改变，你的view也同时变化。你只需要监听ViewStrategy的类型 */
if(true){ return new Woman()
}
}
const data = fetchGetQuery()
return <Observer>{() => { return ( <> {new PersonContext(data).renderView()} </> )
}}</Observer>;
}
如果以后业务有所改动，可能事以下的情况。
第一种我们有一些条件判断在React里面实现起来比较方便，对我来说。比如业务扩展的时候,我需要多一个props
new PersonContext(data).renderView(props) , 在组件调用的时候 <Component {...props} />
相比其他两大框架 你需要 <component :props1="1" :props2="2"> 对我来说增加了工作量，不喜欢而已。
只所以不用map的原因是，如果以后有一个类似的功能，但久的模块不需要。我只需要在新的模块注入新的工厂组件对象。即可，我也不要维护之前的map代码。
我把调用关系画完后，是不是清晰多了？我在设计的时候只是定义好了调用关系，然后每一层的设计交给能力对应的人去实现，最后进行集成测试。而且重要得是，你不要做死做活，对应毕业生也不用有太多的压力和心里负担，我个人是不推荐我手下的人有加班这种行为。
什么样的人做什么事，才是最快做好一件事的过程。
如果后面每个组件都需要添加东西，我们可以直接修改渲染选择器即可。如果单独的业务修改，直接到该组件进行修改对应的逻辑。
拆开的还有一个好处,就是你在维护的时候，对代码的定位更加精准，查看的代码量也少。
这里我就不举例子了，懂得都懂，不懂得喷子我也懒得解释了。
