一入架构深似海，本文总结了一些可以实际运用于架构的方法，希望能够帮助到你们。
这里分享一个思考问题好方法——结构化思维
以事物的结构为思考对象，来引导思维、表达和解决问题的一种思考方法。
3大要素：
- 主题鲜明
- 归类分组
- 逻辑递进
举例说明你喜欢的食物，通常零散的发散性思维
结构化思维后
作为程序员特别推荐这样的思考方式。
正文
架构
我的理解：
架构是解决复杂问题的能力，同时发现技术的问题，服务于技术。
很多人总是误会，认为前端的架构该做的是，工程化、自动化甚至于写后端，这些当然算，但是架构其实就在你身边，需要换一个角度去看问题。
回到上面的理解，解决复杂问题，上面说的内容都是解决复杂问题的方式，首先需要挖掘问题。
产品经理
发现问题
用户行为轨迹，体验上的优化（埋点、针对业务单元的特殊UI） -> 工程化
其实前端才是离用户最近的，这些东西站在程序员的角度可能比产品经理看到的更多。
业务架构
把自己作为用户，深度使用同一类业务的功能产品，某些通用的模块可以剥离，某些模块可以优化。
没理解？我们来举个例子
电商行业与医疗行业的侧重点就是不同的。
电商行业：互动、高并发、市场营销……
医疗行业：兼容性、快速操作、专业的医疗流程……
当然实际情况复杂得多，对于用户（医生）来说保证表单功能的详细情况下还要做到操作简单，类似的联动、搜索、自动保存等功能都可以做成针对处方的工具模块（包）。
以单点登录（SSO）举例，当医生走了这一套复杂流程之后点击提交却因为登录态失效重定向跳转出去，同时登录之后填写的内容全没了，想必心里一定是崩溃的。
前端
发现问题
观察/调研同事开发中出现的痛点（重复性劳动，可以提效的地方）-> 自动化
单点登录需要跳转不好用？直接开发一个弹窗单点登录的包，可以选择有UI和无UI俩种。
为什么要这样做？前端需要个性化的地方非常多，无UI支持用户（技术）和设计师自己提供界面，对于开发来说好用的工具一定是可以支持自己魔改的~~
Devops、脚手架，也是一样的，这些工具都是可以提效的但是要让用户使用的爽一定要给他们留口子。
习惯会扼杀这些新架构的约定，当开发人员的习惯不统一的时候，这些工具很难使用起来？
首先确保这些架构产出稳定好用，其次要做到量化，当你的架构提效可以确切量化，那将会轻松许多，因为量化的内容可以让你的用户在使用你的方案之后轻松拿到KPI，这个时候新的架构来了—量化方案/平台（架构之间总有一些联系）。
剩下的，考验推进能力的时候到了。。。
推进
这里毫不吝啬，本文精华部分，个人的一些经验总结
产品本身
产品本身有解决复杂问题的能力，那么推进起来可以说一帆风顺，到了合适的timing迟早用户都会使用上。
捆绑产品
还是以单点登录弹框为例，其中的统一UI框架、极验验证、甚至iframe的跨域、跨级通信都是可架构的，这些东西是完全可以联系在一起，巧的是我刚好手上都有这些东西，开发的过程中自然而然就输出成了一整套方案。
因此，不要认为自己做的东西功能单一，很小儿科，当他们组合起来很有可能就是另一个架构产品。
共赢策略
许多时候光靠自己是不行的，例如Devops需要运维支持、做业务架构需要产品的帮助、node层/微服务需要后端大佬的指点等，个人认为去学习这些知识，还不如直接让他们加入你。
把你的Idea抛出来，专业的事情让专业的人来干，同时你可以负责产品的售后，只做架构的产出且无须对产品负责我想对于他们是百利而无一害。
你可能会问，为什么由你做售后，其一是通过排查问题学习背后的技术（总比你不了解原理开发出的bug要很多），其二是收集用户反馈。
当反馈积累到一定量的时候，你就能知道架构是否成功，进行下一次迭代的方向等，那么你这个产品经理的身份就坐实了。
死缠烂打
其实在推进方面这不是一个贬义词，扩大你的社交圈子、锻炼你的沟通能力这些都是推进过程中的必经之路。
除了厚脸皮的推销，其实你大可以利用身边的路径做到“阴魂不散”。
- 利用公司的社区、论坛、月刊等推广（如果没有可以考虑自己建设）
- 利用掘金、公众号这样的平台发布在公司技术群
- 在公司内部举办“发布会”
- 在内部的架构系统/工具/包里广告植入
- 从上至下，先说服领导，再拉一个关于此架构的群，在群里说明架构解决了什么问题（当一个领导与你达成共识，其余的领导也会相对容易加入进来）
- 刷脸
最后，今天你对我爱答不理，明天一杯星巴克称兄道弟。
投递简历砸我邮箱 yangyz1@guahao.com
素质四连，点赞、关注、转发、评论
了解更多，关注技术公众号：ihap 技术黑洞 ！！！
