是否在新项目中应用新技术（新的框架、新的语言）
两种情况，
新项目在产品逻辑上与其它项目无关，此时使用新技术是可以的
此时成本是在于新技术的门槛和维护成本，以及对于新功能的兼容和开发
好的一点在于新技术有其优势，在未来存在一定可能会有利于产品的迭代和开发
新项目在产品逻辑上与其它项目相关，此时不可，
例如G端交付类项目和自身示例项目，虽然两个项目开着像两个，但实际上产品只有一个，此时对外的只有一个产品，但发生产品迭代和产品更替时，G端交付类项目的甲方需要同步更新时会产品老技术迁移到新技术的运营成本以及重新研发成本，重点在于这些成本来自于技术选型，可以认为是无效成本，所以此时不应该使用新技术
第二点G端交付类项目成交的关键在于与甲方的联系，如果要继续合作，必定存在交集。就算说明了升级需要付费，但这不可能绝对实现。所以G端项目上，我们应该更慎重使用新技术或者说我们如果使用新技术，应该全面的替换而并不是小范围试点之后就算了。
对于一套代码复用很高时应该是写一套还是拆分多套
一套代码好处：一套代码可以解决代码散乱问题，写好注释可以很简单的找到对应的位置，代码bug解决起来一劳永逸
一套代码坏处：代码一旦交付部署会一起进行部署，接口的兼容性要求高，大部分情况接口会经常性出现问题，需要很长一段时间进行接口的稳定性测试，测试成本极高，接口后续维护高成本。
拆分多套代码好处：多套代码可以隔离影响，如果一个接口出问题不会影响别的交付类项目，接口开发难度较低，测试成本较简单，维护成本也较低。
拆分多套代码坏处：代码bug修复时存在很大问题，G端交付类项目一多，如果发现一个问题，后续可能面临几十个的问题修复。如果G端项目承诺免费升级的，每次新功能的开发都代表着几十个项目的CV，此时成本极高，这样会极大的拖延产品迭代进度。
对于产品迭代速度高，产品开发速度快，不负责免费更新的此类产品建议拆分多套，通过一个大仓库的方式来管理。此类bug可以采用不报不修的措施，如果不报证明这类问题可以容忍，功能使用不多，没必要花费精力。
对于产品迭代速度不高，产品开发速度可以接受，负责免费更新的产品，此类产品建议合并一套，免费更新所需要的修改点特别多，经常会出现新功能开发一天，同步三天，极大浪费资源。合并一套虽然兼容性和测试环境压力会大。但是相比同步来说，成本可接受。只要逻辑树清晰，测试同样不需要太久。
前端组件化时哪些样式不要写在组件内部
外部的margin、bottom、right、left、top、color、background、z-index、外部的position等，这些样式如果写在内部的话，外部如果调用中权重稍小，便不会生效，会造成各种迷惑展示。
前端样式注意点
写样式不要造成两边重叠，一个块级组件就占使用的那么大，不要产生重叠。要以搭积木的方式粘和，而不要叠加。
swagger还是postman
swagger和postman都是调试工具，那我们在日常选取哪种呢？
postman出了代码生成工具瞬间让人好感满分，但是接口文档使用postman真的好吗？
swagger优势：
代码无关，只要在代码中配置好就可以开启代码的时候启动swagger
swagger全线上化，方便管理，部署一套，系统就可以使用
swagger可以在线调试，部署后更能实时获取接口状态
postman优势：
本地调试方便
集成化的终端环境所以没有任何部署烦恼
各种语言代码一键生成
本地接口打包管理容易
随时随地看视频
