一个外乡人的故事


夏天很热的一个日子里,一个外乡人沿着一条路在行走。他走着走着,来到一个人跟前,此人正在路边敲碎石头。

“你在做什么?” 他问那个人。

那个人抬头看着他: “我在敲碎石头。你以为我看起业像在干什么? 现在不要妨碍我,让我继续干活。”

这个外乡人继续沿着路走

不久他遇到了第二个在大太阳下敲碎石头的人。

这个人正在努力工作,汗滴如雨。

“你在做什么?” 外乡人问道。

这个人抬头看他,露出微笑。“我在为谋生而工作,” 他说, “但这个工作太辛苦了。也许你能给我一分更好的工作?”

外乡人摇了摇头,继续前行。没多久,他遇到了第三个敲碎石头的人。太阳正是最炙热的时候,这个人非常卖力,汗流如注。

“你在做什么?” 外乡人问道。

这个停了一下,喝了一口水,微笑着抬起他的手,指向天空。

“我在建一座大教堂。” 他喘了口气说。

外乡人看了他一会儿,说: “我们正打算开一家新公司。你来做我们的总建筑师怎么样?”

-- 摘自架构之美


软件行业架构师两个定义


系统架构师是一个既需要掌控整体又需要洞悉局部瓶颈并依据具体的业务场景给出解决方案的人。具体来说是一个确认和评估系统需求,给出开发规范,搭建系统实现的核心构架,并澄清技术细节、扫清主要难点的技术人员。主要着眼于系统的“技术实现”。因此他/她应该是特定的开发平台、语言、工具的大师,对常见应用场景能马上给出最恰当的解决方案,同时要对所属的开发团队有足够的了解,能够评估自己的团队实现特定的功能需求需要的代价。 系统架构师负责设计系统整体架构,从需求到设计的每个细节都要考虑到,把握整个项目,使设计的项目尽量效率高,开发容易,维护方便,升级简单等。


架构师是软件行业中一种新兴职业,工作职责是在一个软件项目开发过程中,将客户的需求转换为规范的开发计划及文本,并制定这个项目的总体架构,指导整个开发团队完成这个计划。架构师的主要任务不是从事具体的软件程序的编写,而是从事更高层次的开发构架工作。他必须对开发技术非常了解,并且需要有良好的组织管理能力。


软件行业互联网与常规企业的区别


互联网项目(偏灵活及扩展性)

盈利方向:以产品服务为导向,以产品吸引用户,从中挖掘盈利模式

迭代频率:快速迭代,快速呈现产品,不断更新产品符合业务发展及用户需要

业务复杂度:由于面向全互联网,复杂度越大用的人越少

瀑布流方式并不适合互联网,架构师的做事方式也不同与企业架构


企业项目(偏积累复用性)

盈利方向:技术服务以需求方为导向,普遍对内部及合作方服务

迭代频率:以客户需求为导向,一般周期很长

业务复杂度:以客户需求为导向,普遍业务逻辑复杂

适合瀑布流方式及螺旋模型


架构师内部方向


系统架构师:

服务器 负载,可靠性,伸缩,扩展,数据库切分,缓存应用


应用架构师:

理解业务,梳理模型,设计模式,接口,数据交互


架构师不是万能的


擅长沟通的,不见得技术很强

擅长展望的,不见得细节完善

擅长攻关的,不见得会规划

擅长设计的,不见得会实现

擅长理论的,不见得能落地

擅长推动的,不见得细节可控

擅长总结的,不见得会创新

不擅长的事情怎么办?很多方法能解决!!


互联网团队特点


努力目标:产品做得好,技术玩的欢

迭代快,效率高,业务逻辑清晰明了,扩展强,

迭代次数过多,需要定期整理迭代代码整理精华及总结。

一个人精力有限,不能面面俱到

高手凤毛麟角,即使有,也因为精力有限也只能解决几个问题

产品是一个整体,技术团队也是一个整体,所有细节的优秀才会成为一个优秀的产品,优秀的团队


架构是要靠团队做出来的


保持和架构的沟通,架构通过团队的沟通总结出方向

队员经常提出自己碰到的问题,并分享给大家,思维碰撞促进发展

产品经常提出设想和规划,能够使得架构符合未来发展需求

运维经常提出隐患及分析,能使得架构快速拆分模块

定期做总结归纳以此分析问题,解决问题

团队成长、就是每个人的成长、每个人成长眼界自然增长

团队的成功、就是产品的成功,产品的成功就是公司的成功

公司的成功可以给你加光环,但光环不代表自己的能力代表经历

图片1.jpg/


架构师会做什么?


方向规划:有想法和技术展望目标,制定短期目标

架构设计:集思广益来设计,归类总结,根据讨论结果制定规范。设计不仅仅是技术相关(业务流程,业务方向,模块划分组合,框架设计,流程纰漏等),设计出来还是需要实施的。

技术攻关:疑难技术点攻关,将问题集中化解决,提供平台化解决方案以及选型决策。

解决疑难问题:发现各类型问题(不仅仅是技术),通过规范,演讲,绘图等方式解决隐患。

互动沟通:部门之间沟通,开发之间沟通,产品之间沟通,市场沟通,沟通后产出图形化文档及设计。

关注点:秩序,统一,规范,稳定,高效


架构师团队内做的事情


沟通能力:各个方面都要了解,人人想法及规划都要知道,了解产品思想,用了什么方法实现的

组织能力:组织推动各种技术的改进及功能的完善

谈判代表:左右两难的时候的调解人

设计模块及业务:通过图形化设计发现开发后才会发现的业务问题

成本规划:通过过往经验评估成本及步伐

愿望收集:不断收集建议及愿望,一步步实现

传播布道:不断参与行业交流,提高理论及技术知识科普分享团队


互联网常见架构优化项


目的:通过各种方式,强化产品运行速度及效率及体验等

缩短开发周期,归类设计减少重复造轮子

工具化所有环节,数据归类所有数据

优化服务器利用率,减少服务器资源浪费

强化服务器稳定性,设计完善的服务器监视预警

图形化文档管理关键点,缩短产品及业务的成熟时间,规范业务模块间的关系。

拆解复杂业务及任务,组合高依赖业务,减少开发细节模糊点


如何成长为架构师?


行业动态要了解,时刻关注技术更新

开发时先设计然后在做,做好后总结

关注公司业务动态,结合产品观察

关注系统运维及相关技术

关注业务划分技巧及目的

清晰化自己掌握的技术的用途

多沟通


开发的发展的几条路


偏管理:

做项目管理、总监、CTO


偏技术

做架构、技术专家、领域专家


例子:如何做好业务完善设计?

通过沟通获取需求 -> 了解目的及未来规划 -> 图形化想法及业务基础图形进行分析

从用户感觉分析业务 -> 从开发方向分析模块特性 -> 与团队讨论预防遗漏点


例子:如何做好技术设计及设计沟通?

分析数据基础对象绘制ER图 -> 了解业务流程对数据对象的影响 

业务场景及数据表结构设计 -> 通过图形分析问题并完善结构  

分析性能及扩展性及使用方的需求 -> 数据增长量设计分析


设计中注意要点


问题拆解,明确知道关键点是那些,围绕核心思想进行设计

避免过度设计,现在需要多少就做多少

灵活及扩展性越强的模块越容易复杂

相互依赖过多的模块要合并

相互依赖模块之间要做隔离为以后升级适配留路

隔离不仅仅隔离依赖还需要隔离适配临界点(如第三方接口)

系统单点要备份,监控

层级多了会以性能及效率为代价,少了则不好维护,掌握平衡即可

不能过分追求一个极致,谁也不能预测业务下一步

不知道所有业务场景慎重设计,应以整体产品方向为设计依据


开发如何更好的沟通?


发现问题,分析问题原因时

阐述所有相关信息,碰到什么问题,目前情况什么样,并做演示

通过输入,输出判断结果分析原因

通过图形化讨论更好理解

术语不是所有人都知道其意义,不如白话沟通

有不知道的地方,及时拉所有相关人加入讨论分析

代码如果没有注释,只能知道动了那些数据

图片4.png/


本文来自:穷游网-徐长龙