这才是看能力的地方，软件工程的能力比用什么新技术之类的重要多了，推荐一本
https://book.douban.com/subject/35006892/ ，我挺赞同这里面的挺多想法的，很多自己也实践过。
1. ETC （ Easier to change ），书里强调是一种价值观，我觉得也是，而且是最重要的一条，所有的事情从设计的时候就得考虑，他是否易于变化。做每一个决定也都要考虑，这个决定是否能做到易于变化，这样落实到代码的时候我们就会拆分的更清楚。
2. DRY (Don't repeat yourself)，这个我最初的理解其实是浅见，只是想如果能自动化的就不要手动，这本书里给的了启发，避免重复其实就减少了维护的难度，特别是代码逻辑里面，这会让我们意识到，我们可以把逻辑拆分的更细，更易于变化，然后通过组合来去呈现复杂的逻辑。
3. 正交性，如果能设计成完全不相干的系统就尽量不要有关联，消除不相关的事物之间的联系，这个最近有体会，因为一些原因我们很难做 SSO，所以我们的 portal 提供给各级子项目 token，而这其中还传递了其他的 profile 信息，其结果就导致了其他的系统出了问题，一直找不到原因，结果发现是 profile 信息因为某些权限问题传空了，结果就成了跨系统的问题，所以设计的时候一定要尽量做到正交。
4. 封装，组件化，前端现在已经很容易能做到组件化，特别像 react，组件化是常态，重要的是如何能在多个系统 share，如何能够更方便的提出组件，提取出公用 utils，这个很推荐 monorepo 的方式组织代码，我们可以很方便的在一个项目里很容易的拆分出相应的公共部分，组件，逻辑，工具等等，可以结合 nexus3 这样的私有代码仓库，做到多个项目的 share
5. 领域模型，构建前端的领域模型，只用通过稳定的模型去映射组件才能有更好的维护性，设计好领域模型后我们可以把后端的 api 映射到领域模型，然后前端的领域模型去映射组件，当然最好的办法是直接上 GraphQL.
6. code review，以上所有的东西都需要 code review 去统一和实践以及监督，这是落实这些东西最重要的一部，否则每个人都有不同风格，当然我们做的更多一些，比如通过 Prettier，以及 eslint 去定制一个我们的规则，通过 SonarQube 去看代码质量等等。