标签：架构 项目 代码 API 日常 规则 架构师

架构师日常（三）

周末开始研究项目源代码了，这关系到一个经常被问到的问题：架构师到底应不应该写代码，我来举例说明：

成为架构师最初的几个项目，我基本都是从写代码过来的：

• 第一个项目，.NET平台，根据客户各地区不同的业务规则模板，基于规则引擎创建灵活可定制的查询。这个项目核心就是规则引擎和动态SQL脚本，所以我采用了正则表达式，正则这一块儿交给了我们上海那边的一位年轻同事，他学习能力很强，基本80%的规则引擎内容都是他开发完成的。但是这个工作开始的阶段，我还是需要做一个简单的原型跟客户团队和我们团队的业务负责人解释规则引擎和动态查询是如何工作的。

• 第二个项目，基于WordPress做一个Headless的内容管理系统CMS应用，用来管理数字资产，后台存储使用亚马逊云的S3对象服务，我写的代码原型包括：

  • 搭建WordPress曝露RESTful API
  • 实现跟企业单点登录SSO的集成
  • 实现S3文件对象的上传、下载（其中下载使用即时签名URL的方式保证下载URL被他人拿到无法访问）

• 第三个项目，因为第二个项目的原因我们又接到了一个企业级业务战略资产的CMS项目。这回要求使用Drupal开发，我写的代码原型包括：

  • Drupal页面及服务的模块化开发方法演示
  • 趋势图的动态生成（类似Gartner的技术趋势S曲线图）

• 后面的项目包括：数据上传数据湖、SAP API系统集成、AWS和Azure的无服务REST API、NoSQL数据库使用、ElasticSearch搜索引擎的使用等等都写了不少的代码。

架构师写代码与开发人员写代码当然是不同的，架构师需要从架构的角度审视代码，比如是否满足可扩展性、性能、安全等方面的要求。而当这些代码下发给开发人员使用时，也就保证了架构满足类似方面的需求。

那架构师还需要参与哪些代码工作？包括但不限于：

• 开发运维Pipeline的配置，比如我现在的项目可能就涉及到CI/CD Pipeline要实现参数化和Mono Repository（单一代码仓库）的模式。
• 代码评审，业务代码还好，主要是一些技术性代码。说小了包括如何操作字符串文本，说大了到如何集成数据湖等等，各种代码的技术性方面都要多少看一看。但不需要每个代码都看，也不需要时时看。比如两个Sprint下来检查一次，主要看看是否按照架构设计的方向在走，用的库有没有技术性问题比如性能方面，是否健壮，有没有维护团队，许可有没有问题等等。其实做事的方法很多，主要是架构师或高级架构师在组织层级的企业级架构经验比较多，知道很多企业级的技术合规性问题如何解决，但是到下面的架构师或开发人员，因为跟企业上层的企业架构距离比较远，做事的时候难免有偏差。比如企业在AWS云上的无服务计算策略是使用API Gateway + Lambda实现，而团队跟新，使用ECS + Fargate实现，这就跟企业架构定下的规则有所冲突，而在后期评审、运维上就会被质疑，因为从成本上考量确实前者比后者更有优势，不过也要视场景而定，毕竟不同的服务有不同的限制。
• 代码重构，这个是我强烈建议架构师进入既有项目的时候需要考虑是否需要重构，如何重构，究竟是需要Re-Factoring还是Re-Platform或者Re-Arch。如果你进入项目的时候没发现平台或架构问题，一个发布下来再做可能就已经晚了。

标签：架构,项目,代码,API,日常,规则,架构师
来源： https://www.cnblogs.com/richardcuick/p/16128462.html

本站声明： 1. iCode9 技术分享网（下文简称本站）提供的所有内容，仅供技术学习、探讨和分享；
2. 关于本站的所有留言、评论、转载及引用，纯属内容发起人的个人观点，与本站观点和立场无关；
3. 关于本站的所有言论和文字，纯属内容发起人的个人观点，与本站观点和立场无关；
4. 本站文章均是网友提供，不完全保证技术分享内容的完整性、准确性、时效性、风险性和版权归属；如您发现该文章侵犯了您的权益，可联系我们第一时间进行删除；
5. 本站为非盈利性的个人网站，所有内容不会用来进行牟利，也不会利用任何形式的广告来间接获益，纯粹是为了广大技术爱好者提供技术内容和技术思想的分享性交流网站。