去年某次会议上聊到了架构师要不要编码的问题,但是由于这个话题并不是当时的讨论重点,所以不了了之。最近又在关注架构,所以将真个问题翻出来重新整理了思路。
工作中讲过两类架构师,一类是常见的工作与交付项目上的,还有一种视角要更高的架构师。我讨论的是前者,即工作在日常交付项目上的架构师。
我认为架构师应该将编码作为工作的一部分。
[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-cdXhcLav-1582453276562)(01-img/01.png)]
1,将需求转为架构、并落地实践需要架构。
软件复杂且抽象,架构的抽象描述能在设计上解决或者有助于解决一些问题。但是现实中偏离目的的项目实施比比皆是。架构师通过编码可以了解到是否实现和设计背道而驰,从而降低技术风险,并促使架构演进。
2,了解项目真实情况,而非只是"看起来","听上去"那样
正如"用户表达出来的不一定是真需求",开发者描述出来有时候并不是真的问题重点,很可能只是表象。所以能够让团队更好的解决问题,就需要清楚知道是什么、为什么,一定的编码功能,也能让架构师与项目保持同步,从而实现架构演进。
3,保持一定的水平的水准,才能更好的进行设计。
现在技术繁杂,虽然有些团队限定了技术栈,但是为了保持与时俱进,架构师能够通过部分编码工作来获得练习和与时俱进。有句话 “如果你只有一把锤子,那么看所有的问题都是钉子”。技术上的宽度和深度同样重要。这样架构师才能更好地接下来的设计中得到学习和改进。并不仅仅停留在 PPT架构师
上。
4,与团队一起工作,能够更好的帮助开发者了解架构设计的思路和目的,也起到了未来架构师培养的作用。
开发人员的焦点与架构师不同,开发人员的焦点更多的是如何在代码上,例如面型对象编程、类、接口、SOLID、重构、自动化测试等。因此对架构的理解并一定和架构师的构想一致,架构师在承担部分编码工作的时候,还能是开发者维持和架构设计的一致。并在日常沟通中培养起未来的架构师。
5,不要把全部时间都用来编码
是的,不管是哪种架构师,都不应该把全部实践用来编码,因为架构师有其自身的职责。编码只是其职责的一部分,架构师还应该架构驱动力、软件设计、技术风险管理、架构演进、质量保证上,承担相应的责任。
架构师应该将编码作为工作的一部分,但是并应该把全部实践用于编码。至于编码参与多少可以根据项目情况来决定是参与的多还是少。