读《走出软件作坊》交流-架构师.pptVIP

架构师 架构师 《走出软件作坊》读书活动 概念 架构表述了一个系统的基本组织结构、基本组成构件和互相的关系，以及构件于外部环境间的关系。 架构师的特征 掌握核心技术 深入技术内部原理，而不仅仅停留在表面。 了解产品特性 了解行业特点，了解业务知识。 了解软件趋势 很多情况是技术要求不高，但不要形成技术轻视观，不要产生核心技术学习无用论的思想。 创新技巧 能把手里这些技术巧妙的利用，以解决自己的问题。 架构师的职业素养 权衡与平衡 抽象、建模与设计 预见性和前瞻性 化繁为简 模式与重用 质量、效率与资源 敏捷、迭代与演进 技术从业者的职业规化 成长经历 上升之路 对技术从业人员的其它建议 Page * * 架构师是个很神圣的词。盖茨，世界首富。微软，世界最大最富有的软件公司。盖茨是微软的首席架构师。 架构师是技术职业发展的最高境界，在往上走就有管理职能了，如技术总监和CTO或研发总裁之类的头衔。 软件架构代表了系统的组织结构。这包括将系统分解为不同的部分、界定它们之间的连接、确定它们之间的交换机制、并且为后续的设计提供指导性的原则。 出自UML的著名原创者James Rumbaugh、Grady Booch 及 Ivar Jacobson (即架构界俗称的“三个火枪手”)。 软件架构表述了一个系统的一个或一系列组织结构。这包括了软件构件、这些构件的外部可见特征，以及这些构件之间的关系。 出自Bass Len、Paul Clements、Rick Kazman 在2003年出版的经典的《架构的实践》一书。 软件工程领域基本上没有一致的有关“软件架构师(Software Architecture)”的定义。很多公司也没有这样的职位；有些公司虽然有这样的职位，但却说不清楚这个职位所要求的技能和工作职责；另外但我们对比不同公司关于该职位的描述时，也能看到其中的不一致，例如Microsoft公司与Motorola公司对架够师的职位表述就很不一样。更常见的是这些职位描述严重混淆了很多概念，例如：当年的Rational公司就混淆了“软件架构师”与“高级程序员”的概念。 方案架构师、系统架构师、软件架构师、企业架构师、总工、首席架构师、Java架构师、微软架构师及.NET架构师，WEB架构师 技艺高超：技术精湛、业务精通； 平衡能力：软件技术和业务并重，技术的兼容和演进。 核心技术： 产品特性：”各种技术要做到的就是帮助企业软件生产，如何更快更省力气、质量更好、市场竞争力更强“。技术是为产品服务的，脱离商业产品的技术，只应该留在实验室。深刻理解行业特点，精通业务模型，才能做出差异化，有竞争力的设计。 软件趋势：新技术的出现肯定是为了能更好的解决特定领域的问题。需要时刻关注技术趋势，大多数技术总会在特定的时候为已所用，当然要有一定的判断力，不能人云亦云。 创新技巧：当然，你想把你手中的技术能用活，你必然是理解这项技术的来龙去脉和这项技术的适用领域，还要深入理解这项技术的工作原理，还要清楚的认识到你要解决的问题领域，否则，你无法把你的技术和你要解决的问题结合在一起。 软件架构师必须学会的第一件事情是：懂得如何进行权衡，在各个相互矛盾的设计要素、限制和约束条件之间巧妙地取得平衡。 一位软件架构师必须主动地选择工作在合适的抽象层次上。在必要的情况下，他/她必须能够脱离具象的编程语言（如 Java、C++、VB.Net、JavaScript、Ruby 等等）进行思考，能够透过现象看本质，准确抓住事物的本质。 往前多看几步，考虑一下面向未来问题和潜在风险的应对之道。 为什么我们要白白耗费资源，开发出冗余的、重复的、七绕八拐的低效程序？软件架构师必须带领他/她的程序员团队，始终坚持对软件架构艺术之美。 节省工作量的最好一个办法就是重用。软件模式的应用本质上是对软件设计思想、设计知识的重用。 在有限的，甚至往往是“窘迫”的时间进度、经费和人力资源等重重压力之下，带领团队开发出真正符合客户需要的、高质量的，同时又具有长久生命力的软件产品或系统。 高质量的、好的软件架构从来都不是一蹴而就的。传统的瀑布型是开发导致国内外大量软件开发项目失败的主要杀手。转为采用迭代递增、演进的方式来设计和发展软件架构，这是过去 30 多年来世界软件工程界以及软件架构师们学到的最宝贵经验之一。 CTO是Chief Technology Officer的缩写，现代公司管理制度中的首席技术总监。 项目经理只需通晓业务就可以了。（言外之意是项目经理必须有一定的技术基础，或是说有研发背景） 技术好的人做主程；技术好、口才好并且有责任感，做架构师；如果再有商业头脑，就适合做CTO。 研发部经理，一个管理职能大于技术职能的岗位。 ”有人跟踪调试了一下午也找不到错误的，找我；有人不知道这个错误