背景
起这个标签（前端架构），主要是因为自己最近一直在从更高层级上去思考一些前端的问题，想专门建个tag，分类一下。
首先我认为作为程序员，在公司的工作就是不停的挖坑（寻找一个目标或接一个需求）-->朝目标前进-->遇到问题-->解决问题-->直至完成目标的一个过程。也就是说，程序员和其他职业一样，都是解决问题的存在。
对于要解决的问题的定义，我认为，业务在不同的情况下，所面临的问题肯定是不同的。例如项目在创立之初，所面临的问题是如何快速建立原型，放到市场上去验证；而当业务在成长过程中，需要数据来指导我们的发展，所面临的问题是如何收集用户的反馈，如何更好的捕捉到用户使用场景的信息（例如页面crash，按钮不合理，加载缓慢），这里就需要埋点，错误监控，性能监控等方案加以扶持；那发展到后期面临的用户终端越来越多，如何最高效的发挥人力，也是我们需要思考的问题。而这些问题并不是说网上搜一搜就有最佳解决方案的，为什么这么说是因为：
- 上下文无法完全匹配，诸如人力，时间，未来发展等等；
- 解决方案是有一定时效性的，时代在进步，场景在发展，解决方案也在不停的发展；
- 每个解决方案都有其对应的坑，只有走过的人才知道，而坑的大小就决定了所需消耗人力的成本，因此有的解决方案看上去最优，但可能光踩坑就要踩很久，因此性价比也并不是最高。
上面这些问题看似繁多，其实都是表面，总结下来所面临的问题应该是以下几点：
- 高可用性，尽可能减少代码报错几率，提升用户体验；
- 抽象，抽象分很多种，大了像
ReactNative直接对不同宿主环境的代码进行抽象，小了可以组件化抽象，业务抽象等等，主要是为了提升开发效率； - 性能，很好理解，提升用户体验；
- 可维护性，这一点单独拿出来讲是因为我们的代码随着时间的流逝，代码量的增长，人员的更替，代码的可维护性会变得越来越关键，一旦可维护性变差，那版本的迭代，功能的增长，开发的效率等等都会受到制约。
等等（目前只想到这些）
目的
因此建立这个tag的目的就是把自己所发现的问题，以及对应的解决方案记录一下，方便自己日后在面对问题的时候查看，相当于一个经验的累计。
当然有时候也会对一些没有在生产环境使用过的解决方案进行一些简单探索和介绍，主要是为了能收集更多的锤子。
完
网友评论