共计 783 个字符，预计需要花费 2 分钟才能阅读完成。
在设计架构的时候，要思考由下而上的模式，底层的实际最终会影响整个零碎的架构。再好的架构，如果没有辅以无效的工程实际，那么最终咱们失去的只是一只空有其表的架构计划。能自下而上影响软件架构的，就只有代码了。
代码自身是一种难以掂量的实际。同一个业务性能有不同的代码实现。设想一个场景，咱们对外提供了一个 RESTful API 接口，是不是只有咱们能以标准的形式提供这个 RESTful API 接口，代码的实现形式和品质就变得不重要了？
从短期来看，如果一个 API 能疾速地提供性能以驱动业务增长，那么它就就是一个胜利的 API。不管其设计得如许俊俏，代码品质多差，只有不影响性能，将来就有改良的空间。可是从长期来看，API 是要可能面向变动而疾速拓展的，如果咱们不能不便地在 API 中拓展性能，那么它就真的会影响业务了。只管重构的代码能够帮忙咱们走向更好的架构，然而在业务进度不合理的状况下，咱们只能在旧的、俊俏的代码上一直堆砌性能。直至有一天，咱们欢快地抉择重写零碎。
在本节里，咱们将探讨代码中的一些根底标准，他们更多地关注代码的可读性，而不是代码的品质，咱们会在前面的章节里关注代码品质。为了晋升代码的可读性，咱们须要做到以下的几方面：
标准代码组织构造
- 对立代码格调，即源代码的书写格调
- 组件、函数等命名标准
- 开发工具标准
光看这几点要求，总感觉仿佛多了很多条条框框。只管这种统一性会扼杀团队的多样性，然而对于代码档次的格调对立是相当有必要的。
在这些实际中，有些并不仅仅是实际，他还反馈了架构的模式，如代码组织构造 —— 从代码的组织构架上，咱们能够真真切切地感触到他与零碎架构的相似之处。因为利用内的代码复用采纳组件化的架构，所以咱们应该隔离不同的组件。比方，在 Angular 生成的组件 component 中，咱们就能够看到一种组件齐全独立的存在模式。
本文由博客一文多发平台 OpenWrite 公布！
