代码之旅：基础规范

在设计架构的时候，要考虑由下而上的模式，底层的实践最终会影响整个系统的架构。再好的架构，若是没有辅以有效的工程实践，那么最终咱们获得的只是一只空有其表的架构方案。能自下而上影响软件架构的，就只有代码了。

代码自己是一种难以衡量的实践。同一个业务功能有不一样的代码实现。想象一个场景，咱们对外提供了一个 RESTful API 接口，是否是只要咱们能以规范的方式提供这个RESTful API 接口，代码的实现方式和质量就变得不重要了？

从短时间来看，若是一个API能快速地提供功能以驱动业务增加，那么它就就是一个成功的 API。不论其设计得多么丑陋，代码质量多差，只要不影响性能，将来就有改进的空间。但是从长期来看，API是要可以面向变化而快速拓展的，若是咱们不能方便地在 API 中拓展功能，那么它就真的会影响业务了。尽管重构的代码能够帮助咱们走向更好的架构，可是在业务进度不合理的状况下，咱们只能在旧的、丑陋的代码上不断堆砌功能。直至有一天，咱们愉快地选择重写系统。

在本节里，咱们将讨论代码中的一些基础规范，他们更多地关注代码的可读性，而不是代码的质量，咱们会在后面的章节里关注代码质量。为了提高代码的可读性，咱们须要作到如下的几方面：

• 规范代码组织结构

  • 统一代码风格，即源代码的书写风格
  • 组件、函数等命名规范
  • 开发工具规范

光看这几点要求，总以为彷佛多了不少条条框框。尽管这种统一性会扼杀团队的多样性，可是对于代码层次的风格统一是至关有必要的。

在这些实践中，有些并不单单是实践，他还反应了架构的模式，如代码组织结构 —— 从代码的组织构架上，咱们能够真真切切地感觉到他与系统架构的类似之处。因为应用内的代码复用采用组件化的架构，因此咱们应该隔离不一样的组件。好比，在 Angular 生成的组件 component 中，咱们就能够看到一种组件彻底独立的存在形式。

本文由博客一文多发平台 OpenWrite 发布！