博客
关于我
强烈建议你试试无所不能的chatGPT,快点击我
【转载】架构师的行为准则(二)
阅读量:5848 次
发布时间:2019-06-19

本文共 2178 字,大约阅读时间需要 7 分钟。

先确保解决方案简单可用,再考虑通用性和复用性
 

      系统的复杂性往往是架构师基于通用性复用性的设计而引入的,很多具体问题往往不需要通用性和复用性的解决方案。如果存在多个可实施方案难以取舍,先简单后通用原则可以成为最终的评判标准。架构师提供具体解决方案时,无需排斥通用和灵活,但是如果过早脱离具体情况,只会迷失在无限的可能性里,被复杂的配置选项、超负荷的参数列表、冗长罗嗦的接口,以及存在缺陷的抽象所淹没。先简单满足需求,当重复需求再次发生时,通过重构来达到复用是一种不错的方式。
 


架构师应该亲力亲为
 

      架构师干久了往往会脱离技术本身,迷茫在抽象之中,这是很危险可怕的。架构师要取得其他同事的信任,应该比业务人员更懂业务,比开发人员更懂具体的编码,比测试人员更懂如何有效地测试,就像航班的主驾驶员,虽然不需要亲自操作,但经验丰富,持续地监视着情况,一旦发现异常随时采取行动。架构师应该项目的交付和质量负有最终的责任。架构师应该尽可能地参与项目,不能把技术决策和方向上的难题拆分出扔给别人,需要采取更务实的办法,比如亲自动手研究或和其他成员讨论。
 


持续集成是架构师的重要任务
 

      普通的开发人员会focus在各自负责的小模块,只会对单个模块负责,而架构师需要对整个系统负责,持续集成是一种对整个系统进行有效控制的好方法,架构师有责任让它运行起来。
 



避免进度调整失误
 

      虽然保障进度是PM的职责,但变更要发生的时候,作为对技术最有发言权的架构师应该站出来,把变更的必要性和风险进行仔细分析,最大限度地支持PM的决策。
 


取舍的艺术
 

      我们做系统,特别是互联网系统,绝不是做一个变形金刚,而是做一个有缺陷但却满足了现阶段商业需求的系统,因此架构师需要有取舍的艺术,你的架构是能用有限的资源满足最迫切的需求,舍掉那些看是光鲜却无太多用处的东西。
 


打造数据库堡垒
 

      在上层的程序设计中,架构师一般都会推崇先简单实现,然后在逐步重构的敏捷方式,但对于较为稳定的后端数据库,我们需要采取更为谨慎的态度,因为数据库是整个系统的基石,无论是业务设计还是技术设计都得保持它的稳定性,这是整个系统稳定的基础。我们往往会发现这么一个现象,当程序第一版上线后,数据库里表只会增加不会删除,也不会删除多余的字段,每次数据库变更都会引起所有人的紧张,也会使得本已混乱的数据库设计更为混乱。
 


重视不确定性
 

      优良的架构能够从整体上降低设计决策的重要性,糟糕的架构则会使得常常突出选择的重要性。如果出现两个合理地选择,架构师应该停下来,设法找出介于两者之间的、具有更低重要性的决策,了解两者之外还存在其他选择,比决策结果本身更有价值。
 


不要轻易放过不起眼的问题
 

      项目的失败或线上故障往往是由于项目过程中的不起眼问题所引起,比如一些特殊的边界情况,而这些问题绝不能指望开发主力们去发现和解决,因为他们的注意力都会focus在主要矛盾上,作为时刻监控项目的架构师应该担当起发现这些“小bug”的义务
 


让大家学会复用
 

      架构师有义务提高开发人员可复用地解决问题的意识,比如以上几种措施:
 

  • 让大家把自己能复用的代码及时共享给他人 
  • 加强复用代码的易用性,避免误用 
  • 让大家认识到已有资源好过自己动手 
  • 架构文档的抽象程度要适中
      架构师写架构文档常常很纠结,写得太高层次的话就太空洞,无切实的指导意义;写得太具体的话,比如指明到类的各种UML图,就会很约束开发人员。文档要写到什么程度,关键在于满足他人的需求,比如业务部门想从文档中得知系统各功能的实施可行性,因此你的文档要能体现各主要功能是如何满足的测试人员想知道系统内部如何流转如何对系统进行测试,因此你的文档要体现系统主要模块的运行流程系统可测试性开发人员需要知道系统各自模块的划分和之间的交互规范,因此你的文档要体现模块化设计PM需要知道这个项目有哪些风险点,因此你的文档要体现风险点识别如何规避DBA和运维人员需要知道系统的数据量性能情况,因此需要指明系统如何应对大数据量的情况。关键一点,架构师不是为了设计而设计,是要想清楚别人为什么要看你的文档,怎样满足别人的需求。
 


先尝试后决策
 

      设计中有很多需要决策的点,很多架构师喜欢在象牙塔里凭借经验做决策,感觉这就是架构师需要干的。其实,这样的做法往往会让你很被动,不如延迟决策,把需要决策的点抛出来,让大家去尝试,在实践比较中,其实无须决策,正确的选择自然就出来了,这样也更能拉近你和大家的距离,提高大家的积极性和你的权威性。
 


掌握业务领域知识
 

      架构师的角色任务在于理解业务问题、业务目标、业务需求、并设计技术架构来满足它们。掌握业务领域知识将有利于架构师选择合适的架构模式,更好地制定针对未来的扩展计划。
 


coding是属于设计范畴
 

      很多人常常把软件开发类比于传统行业,把coding比作是生产过程,因此很多一线开发人员称作自己为代码工人,很多架构师也是这么认为,只是把开发人员当作实现自己设计的生产工具而已。其实coding相对于传统行业应该属于设计范畴,真正生产过程实际上是由工具来完成的编译、构建和发布过程。架构师更应该把coding当作设计来看,从纸上的设计到coding后的代码还有很多设计点可挖,同样的输出的背后也许来源于完全不同的coding,其软件成品的价值也是完全不同的。 

原文地址:

转载地址:http://hbkjx.baihongyu.com/

你可能感兴趣的文章
Ubuntu下口袋妖怪终端主题安装
查看>>
我的友情链接
查看>>
jquery判断对象是否存在
查看>>
commons-pool实战之 PoolableObjectFactory和ObjectPool
查看>>
高性能WEB开发之flush让页面分块逐步呈现
查看>>
xp重做系统时蓝屏解决方法
查看>>
Maven常用的命令
查看>>
IOS Core Animation Advanced Techniques的学习笔记(三)
查看>>
神州数码 路由器CHAP认证
查看>>
SharePoint2013 中集成AD RMS 与Office Web App 2013集成
查看>>
Windows与Linux下重置MYSQL的Root密码方法
查看>>
好程序员web前端带你了解JS的作用域链
查看>>
除了模拟手术教学,VR在医疗领域如何应用?
查看>>
JVM性能调优之如何书写高效优雅的代码
查看>>
谈数据中心“容灾和备份的区别”
查看>>
linux的LVM
查看>>
hive报错(2)udf无法找到第三方的类
查看>>
HashCode
查看>>
盘点5款Ubuntu监控工具解决CPU暴增问题
查看>>
java 测试IP
查看>>