架构的目标就是为了支撑业务增长,就是提升软件系统的服务能力。可是话虽说 如此,但真实却要做很多取舍。比如对初创团队而言,其产品是否解决业务问题这一 设想还没得到确认,就立即去构造一个高性能、高可用的分布式系统,这样的架构目 标远超出业务发展的需求,最后的结果就是浪费大量人力物力,却得不到任何起色。 架构师需要审时度势,仔细衡量正确性、大规模、可用性三者的关系,比如今年业务 蓬勃发展日均订单 300 万,基于对未来的可能预测,明年可能有 3000 万的订单,那 么架构师应该要着重考虑大规模和可用性。而且每一点提升的程度,也需要架构师衡 量把握,比如可用性要达到 2 个 9 还是 3 个 9。
回顾自己以往的工作很多时候就是因为没有确立架构目标导致浪费了组织很多资 源,比如在之前的创业团队中,由于本人有一定的代码洁癖,经常会花费很多时间和 同事计较代码质量,这样本可以更快上线的功能却需要被延迟,当时过度追求正确性 的行为是与创业团队快速验证想法的业务需求不匹配的。
另外一点比较深刻的案例则是在本人担任一个技术团队负责人的时候,在一次述 职报告的时候,leader 问我对接下来团队工作有什么计划?我当时说了一堆什么改进 代码质量,每天晨会,任务透明化,建立迭代机制等等,然后就被各种批驳一通。当 时团队基本以外包人员为主,人员水平较差,开发出来的金融系统也是千疮百孔而这 条业务线最重要的业务价值则是按计划实现潜在投资方的需求,争取拉到投资。所以 不久 leader 就召集测试架构的相关人员与我这边一同梳理对核心功能的测试工作, 将研发、测试、上线的流程自动化。
另外一点比较深刻的案例则是在本人担任一个技术团队负责人的时候,在一次述 职报告的时候,leader 问我对接下来团队工作有什么计划?我当时说了一堆什么改进 代码质量,每天晨会,任务透明化,建立迭代机制等等,然后就被各种批驳一通。当 时团队基本以外包人员为主,人员水平较差,开发出来的金融系统也是千疮百孔而这 条业务线最重要的业务价值则是按计划实现潜在投资方的需求,争取拉到投资。所以 不久 leader 就召集测试架构的相关人员与我这边一同梳理对核心功能的测试工作, 将研发、测试、上线的流程自动化。
资源来源于《职业发展黄金手册》
https://developer.aliyun.com/topic/download?id=793
版权声明:本文内容由阿里云实名注册用户自发贡献,版权归原作者所有,阿里云开发者社区不拥有其著作权,亦不承担相应法律责任。具体规则请查看《阿里云开发者社区用户服务协议》和《阿里云开发者社区知识产权保护指引》。如果您发现本社区中有涉嫌抄袭的内容,填写侵权投诉表单进行举报,一经查实,本社区将立刻删除涉嫌侵权内容。