架构师的97种习惯

草率提交任务是不负责任的行为

以维护流程通畅为重,以浪费他人时间为耻。要做到这一点,务必在系统内晚上的自动测试功能,纠正开发人员的行为。

沉下心来改善系统的生产效率,缩短流程,避免各行其是,才能缩短开发时间。采取一切可行的措施,例如运用模拟方法、降低依赖性、细致划分系统模块,等等。总之要杜绝一切草率提交任务的年头。

业务目标至上

在商业化的背景下开发企业应用,架构师必须成为业务部门和技术部门之间沟通的桥梁,周旋调解,兼顾双方的利益,同时用业务目标来驱动项目开发。业务目标和实际的开发条件应该成为架构师主持制定决策的参照系统。

按照通常的业务惯例,在启动一个软件项目之前,应当制定计划,明确对投资回报率的预期。架构师必须把握这个预期,并估计该项目的商业价值,避免作出错误的技术决策,造成经费超支。每当要权衡取舍时,无论是与业务部门讨论是否应该实现某项功能,还是与开发团队讨论技术上的设计与实现,都应该把高投资回报率当作目标。举例来说,架构师必须谨慎地站在业务团队一边,拒绝开发团队选用价格不菲的软件和售后服务成本过高的技术。

用业务目标驱动项目开发,才能包装软件开发团队的长远利益。

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

普遍存在一个问题,它们的设计一味强调通用性而不考虑具体应用,导致出现许多令人困惑的可选项和不确定因素,这些功能常常不是被闲置,就是被误用,甚至毫无价值。多数开发者开发的是专用系统,无限制的通用性对™的帮助不大。通过经验提炼的简单方案,远胜过不切实际的通用性。

如果存在多个可实施方案难以取舍,“先简单后通用”原则可以成为最终的评判标准。挑选基于具体需求的简单方案,放弃鼓吹通用性的复杂方案。

提炼通用性可以使我们更加接近问题的本质,通过分析已有案例可以获得清晰、简洁、有依据的规律和方法。

虽然很多架构师重视通用性,但这样做是有前提条件的。并非所有人都需要通用性,愿意为它掏钱,具体情况要具体分析,有针对性的解决方案才有价值。

架构师应该亲力亲为

称职的架构师应该通过示范领导团队。他能胜任团队的所有工作,从网络布线到配置构建流程,从编写单元测试到担任测试工作。对技术缺乏全面理解的架构师,充其量只是一个项目经理。团队成员通常具备深厚的专业知识,很难想像不懂技术的架构师如何赢得大家的信任。众所周知,架构师是业务团队与技术团队直接的接口人,他必须理解各种技术问题,无锡频繁求助他人,才能代表技术团队发言。同样,架构师还要懂得业务知识才能督促技术团队满足业务需求。

架构师就像航班的主驾驶员,看起来不是很忙碌,但他经验丰富,持续地见识着情况,一旦发现异常随时采取行动。项目经理(副驾驶员)负责日常的管理工作,将架构师从烦琐的杂务和人事管理中解脱出来。架构师对项目的交付和质量负有最终责任,没有威信很难展开工作,威信与项目的成败密切相关。

称职的架构师应该至少熟练掌握一种专业工具(例如一种IDE),它们应该身先士卒。按道理说,软件架构师应该会用IED,数据库架构师应该会用ER工具,信息架构师应该会用XML建模工具。而一位技术/企业架构师,起码应该熟练运用哥哥层次的工具,从使用wireshark检测网络流量,到利用XML Spy给复杂的财务信息建模--无论简单还是复杂的都该掌握。

时间: 2024-10-22 21:28:08

架构师的97种习惯的相关文章

周爱民:真正的架构师是没有title的(图灵访谈)

周爱民,现任豌豆荚架构师,国内软件开发界资深软件工程师.从1996年起开始涉足商业软件开发,历任部门经理.区域总经理.高级软件工程师.平台架构师等职,有18年的软件开发与架构.项目管理及团队建设经验,曾任盛大网络平台架构师.支付宝业务架构师,是 Borland Delphi 产品技术专家,也是 Qomo 开源项目(JavaScript)的发起者.2003年5月被美国 Borland 公司授予「Borland Delphi 产品专家」称号,并授予「论坛特别贡献奖」.著有<大道至简——软件工程实践者

如何从普通程序员晋升为架构师 面向过程编程OP和面向编程OO

引言 计算机科学是一门应用科学,它的知识体系是典型的倒三角结构,所用的基础知识并不多,只是随着应用领域和方向的不同,产生了很多的分支,所以说编程并不是一件很困难的事情,一个高中生经过特定的训练就可以做得到.但是,会编程和编好程绝对是两码事,同样的程序员,有的人几年之后成为了架构师,有的人却还在不停地coding,只不过ctrl-c.ctrl-v用得更加纯熟了.在中国,编程人员最终的归途无外乎两条:一是转向技术管理,它的终点是CTO:二是继续深入,它的终点是首席架构师,成为CEO的人毕竟是少数.如

程序员到架构师需要的编程基础

程序员到架构师的进阶之路是非常艰辛和漫长的,不但需要掌握很多高级的知识技能,还需要有过硬的基础知识.<Java架构师指南>就是这样一本指导小白到架构师进阶的书.本文摘取了这本书中的第一章节,主要介绍Java程序员走向架构师的基础知识,还有开发环境的搭建.通过本文的学习,可以大致了解程序员的进阶之路,也可更加深刻地认识到程序员的发展方向. 点此链接购买纸书 本书特别适合Java Web领域的开发人员以及刚步入职场的新手.本书通过讲述Java架构师必备的知识技能,让广大读者在原有知识的基础上更上一

.NET 高级架构师0003 架构师之路(2)---架构师的职责

2 架构师的职责 近来看到CSDN上有个CTO俱乐部,里面聊得是不亦乐乎.我怀着无比崇敬的态度,拜读了一下牛人们的发言.里面有个哥们发起一个话题:"CTO, 你多久没有写程序了?".有人回答:"不写代码的CTO,属于......这公司问题大了!".看到这里,我就赶紧撤了,怕忍不住反驳几句,反而遭到牛人们的群殴.试想,一个上点规模的IT公司,还得靠CTO来写程序的话,那是不是才叫问题大了呢.当然,我没有做过CTO,所以我有我的不同看法,而且还愿意表达出来,无知者无畏.

软件架构师与架构师

软件架构师 软件架构师这个称呼不是拍脑袋想出来的,是有国际标准(ISO/IEC 42010)可查的.架构师是软件开发活动中的众多角色之一,它可能是一个人.一个小组,也可能是一个团队.微软对架构师有一个分类参考,我们参考一下,他们把架构师分为4种: 企业架构师EA(Enterprise Architect).基础结构架构师IA(Infrastructure Architect).特定技术架构TSA(Technology-Specific Architect)和解决方案架构师SA (Solution

架构师的职责

架构师的职责 近来看到CSDN上有个CTO俱乐部,里面聊得是不亦乐乎.我怀着无比崇敬的态度,拜读了一下牛人们的发言.里面有个哥们发起一个话题:"CTO, 你多久没有写程序了?".有人回答:"不写代码的CTO,属于......这公司问题大了!".看到这里,我就赶紧撤了,怕忍不住反驳几句,反而遭到牛人们的群殴.试想,一个上点规模的IT公司,还得靠CTO来写程序的话,那是不是才叫问题大了呢.当然,我没有做过CTO,所以我有我的不同看法,而且还愿意表达出来,无知者无畏.我情

2.6.1 测试架构师

<微软的软件测试之道>第2章微软的软件测试工程师,微软采取了一种独特的不同于业界其他公司的软件测试方法.公司的测试工程师的数目比开发工程师多.而且我们对所有的测试工程师都强调其软件工程技术能力.本节为大家介绍测试架构师. AD: WOT2014:用户标签系统与用户数据化运营培训专场 2.6 测试职种的发展道路 有些公司认为测试是低级工作,开发职位才是一个测试工程师将来可能发展的方向.但在微软,测试职位和开发职位是平等的,并且具有同样多的职业发展机会. 2.6.1测试架构师 微软于1999年设立

好好讲一讲,到底什么是Java高级架构师!

一. 什么是架构师 曾经有这么个段子: 甲:我已经应聘到一家中型软件公司了,今天上班的时候,全公司的人都来欢迎我. 乙:羡慕ing,都什么人来了? 甲:CEO.COO.CTO.All of 程序员,还有会计.司机都来了. 乙:哇,他们太重视你了,人才啊,这么多人迎接你! 甲:没有啊,就一个人! 乙:靠,#%¥$%... 很多的创业公司,一人身兼数职的情形还是很常见的.至少,我是经历过的,一个人包办了所有的开发过程,连测试我都做了,绝对的一条龙,但是经常踩钢丝.骑独轮车总会有失足的时候,结果有一次

直击架构本质:优秀架构师必须掌握的几种架构思维

介绍 架构的本质是管理复杂性,抽象.分层.分治和演化思维是我们工程师/架构师应对和管理复杂性的四种最基本武器. 最近团队来了一些新人,有些有一定工作经验,是以高级工程师/架构师身份进来的,但我发现他们大部分人思维偏应用和细节,抽象能力弱.所以作为团队技术培训的一部分,我整理了这篇文章,希望对他们树立正确的架构设计思维有帮助.我认为,对思维习惯和思考能力的培养,其重要性远远大于对实际技术工具的掌握. 由于文章内容较长,所以我把它分成两篇小文章,在第一篇<优秀架构师必须掌握的架构思维>中,我会先介