android架构师之路
A. 我干了5年android程序员了，怎么往架构师转，需要具备哪些技能
前端工程师+程序员+系统管理员+对各种技术灵活搭配的能力+模式总结=架构师
这些就是一个架构师所需要具备的技能
台湾android教父高焕堂出了个叫《android从程序员到架构师之路》的课程也许会对你
B. [转载]如何成为一名架构师[转]
架构师是一个神秘而又神圣的名词，作为软件开发领域的设计师，架构师承载着太多的责任和挑战。对于一个程序员或者工程师来说，架构师就像是一个目标，一条道路，抑或是一座山峰。如何能够成为一名合格的架构师？架构师应该具备何种素质？而架构师又是如何做到持续不断的成长和提高的呢？带着这些问题，我们请到了五位InfoQ 中文站的编辑，同时也是各领域出色的架构师或者咨询师，来谈谈他们心中的“架构师修炼之道”。他们是：宋玮：InfoQ 中文站Java 社区首席编辑王瑜珩：InfoQ 中文站.NET 社区编辑，ThoughtWorks 咨询师 赵劼：InfoQ 中文站.NET 社区编辑，微软最有价值专家，现任某创业团队架构师张龙：InfoQ 中文站Java 社区编辑 李明：InfoQ 中文站Ruby 社区首席编辑，现任某通信公司架构师1)在你的心目中，架构师意味着什么？张龙：架构师是一个项目组的灵魂人物，他决定着整个系统的技术选型、整体架构以及模块划分，同时还可能担当与领导层的沟通角色，从某种意义上来说，架构师在很大程度上决定着项目的成败与否，正所谓火车跑得快，全靠车头带。 王瑜珩：对我来说，架构师一直是一个很迷惑人的词，似乎每个人的理解都多少有些不一样。我认为架构师更像是一个投资家，需要权衡各方面的利益和风险，反复思量，最后给出一个现实可行的方案，争取用最小的风险获得最大的利益。 李明：我觉得，架构师不仅仅是一个头衔，更是一份责任。所谓“在其位，谋其政”，我倒是觉得架构师更像是父母，而系统和项目则如同子女一般，需要架构师耐心的呵护和培养。完成一个项目，绝不是架构师工作的全部。通过代码重构和架构改造，让这个项目如同有了生命一般逐渐成长起来，这才是架构师最终的目标。2)架构师应该具备何种技能或者素质？宋玮：架构师应该具备一定的业务知识和业务分析能力，能够准确地把握需求。要有较强的学习能力，对于新出现的技术、框架和工具，能够快速掌握。扎实的基本功，能够把握住技术方向。良好的沟通能力，能够清楚地表达自己的意图和想法。李明：代码能力绝对是很必要的。我见过太多只懂得画图的架构师了，“识大体不拘小节”这个说法，在架构师身上并不适用。作为一名架构师，在系统的性能和可扩展性上，要有足够的敏感性，既要充分利用现有资源，又要为长远做好打算。另外，对业务的理解是很多技术架构师所忽视的地方，只要彻底了解业务需求，技术才能派得上用场。赵劼：在我看来，一个合格的架构师需要具备开放的眼光，各种平台、系统、项目随手拈来皆可组合，唯一的目标则是针对合适的环境选择合适的做法，这显然需要在成本和质量之间进行权衡。作为一个架构师，应该具有很好的“弹性”，在真正的环境中，很少会遇见与过去一模一样的情况，因此也需要架构师能够大胆尝试，灵活应对，使用踏实而严谨的做法来进行推测。一个架构师也必须有着足够的沟通和交流能力，把自己的想法使用合适的方式告诉别人，并且根据别人的反馈进行不断调整自己的观点。没有东西是永远正确的，但是一个人往往会倾向于自己的结论，而作为一个合格的架构师，需要有能力认识到自己存在的缺陷，使用各种方式进行弥补。王瑜珩：架构师需要高瞻远瞩着眼未来，从外部功能与内部架构两方面来考虑可能面临的变化。诚如周爱民所说，架构师要在开发1.0 版的时候就想到2.0、3.0，甚至更远。然而在考虑未来的同时，也不能脱离现在，不能由于对未来的设想而大幅提高现在的开发成本，万一未来并没有到来，所有对未来的投资都将毫无意义。因此架构师需要平衡投资与风险之间的关系，以适当的风险来获得最大的利益。架构师需要有良好的沟通能力，才能将自己的想法展示给开发团队中的每个人，确保整个团队对系统架构的理解是一致的。架构师不能脱离实际，设计一个无法实现或成本很高的架构。同时对于一个实际的团队来说，也需要了解团队中成员的能力，知道何种架构可为，何种架构不可为。张龙：很多优秀的架构师都是从一个优秀的开发人员转变过来的，但优秀的开发人员未见得都能成为合格的架构师。与架构师相比，开发人员所需担当的任务相对狭隘的多，其最大的目标就是编写出精良的代码、做好充分的测试以及撰写高质量的文档等；而架构师所要面对的则相对宽泛得多，除了过硬的技术之外，还需要有良好的表达能力，同时还要有宏观的驾驭整个系统的能力。3) 架构师需要不断修炼和提高的是什么？宋玮：扩充知识面，学习了解众多技术及框架的特点和适用范围。了解非功能特性的相关技术和方法，包括可用性、容错性、可扩展性、可伸缩性等等；了解系统安全性方面的技术和框架以及系统性能和状态监测方面的知识及工具。除了技术方面，还架构师还应扩展自身的业务知识，不断提高业务分析能力。想要做到持续不断的学习，保持对各种技术、框架、产品的浓厚兴趣是必不可少的，另外还要掌握他们各自的优缺点及相应的适用场景。学习途径和方式则是多种多样的，但是有一点是可以肯定的，架构师们相互间经常交流对成长是非常有益的。InfoQ 的《架构师》就提供了一个很好的交流平台，通过大家的广泛参与，相信《架构师》能够在分享经验、促进交流方面起到积极的作用。李明：我觉得这个问题可以从两个方面去谈。一方面，架构师要紧跟技术潮流，了解技术的发展和趋势，利用新技术、新方法来提升团队的生产力，将技术转化为收益。这就要求了架构师平时要多关注所在领域或社区最新的新闻和报道，最简单有效的方式莫过于每天都看看InfoQ 中文站了。而另一方面，架构师要培养自己的专业领域。虽然从技术的层面上说，很多解决方案放之四海而皆准。但是，从业务的角度来说，很多行业的解决方案放到另外一个行业中，未必行得通。这就要求了架构师必须对所属行业的业务十分了解才行，这也是一个平日里需要修炼的地方。赵劼：架构师的学习过程是痛苦也是美好的，一个合格的架构师应该可以从学习过程中找到，至少是追求“架构之美”，把架构当作一种“艺术”来对待，并且可以把这种美给传播出去，带领技术团队把这种美变成产品，让更多人体会得到。张龙：架构师之路是崎岖的，充满了荆棘与挑战，但这却是无数开发者的梦想。架构师是多项技能与素质的综合体，每一位以此为目标的开发者都需要在平日的工作中不断提升自己，在这里我衷心的祝愿架构师这个梦想能照进每一位有心人的现实。对于合格的架构师应该具备的素质和技能方面，张龙还给出的详细的列表：有人曾说过，20 几岁的编程天才好找，但30 多岁的优秀架构师难寻。架构师何其难？除了敏锐的洞察力之外，我认为一个好的架构师必须具备如下几方面的素质：过硬的技术能力：有人说架构师就不需要编写代码，只需设计整体架构就行了。但我认为这是很片面的，试想一个人如果长时间不写代码，他还能具备持续的技术敏感度么？当然了，这里所说的写代码并非一般开发人员的行为，而是让自己保持住对代码的感觉。还有人说架构师不一定是技术高手，这一点我很同意，但他一定是个优秀的开发者。 良好的沟通能力：这一点尤为重要，因为架构师需要与项目组的开发人员以及领导层不断交换意见，向对方传递自己的设计意图与思想，没有良好的表达与沟通能力是很容易出现问题的。这一点在沟通方式并非母语的企业中尤为明显。 良好的软件工程素质：虽说架构师不是项目经理，但我认为他需要对软件开发过程有清晰明确的认识，这里的开发过程是个泛指，也许是RUP，也许是XP，是什么无所谓，但这种工程素质是每个优秀架构师必备的品格之一。 宽广的知识领域：架构师的眼界一定要开阔，绝对不能局限于眼前的小范围事务，否则极易出现“鼠目寸光”的后果。这就需要架构师不断学习，这里的学习既包括技术上的，同时也包括业务上的以及沟通上的。 领域知识：架构师务必对自己所从事的业务领域有深刻的认识，他未必要成为业务专家，但他一定要对业务知识有深刻的理解。很难想象经常从事金融领域项目的架构师能轻松设计好电信领域的项目架构。知识需要积累，业务也是这样的。处理系统非功能性需求的本领：架构师尤其需要对系统的性能、容错、并发等非功能性需求方面有独到的认识与解决办法。一个项目到了后期，往往都是这些问题成为整个项目的瓶颈，这时架构师就要发挥其优势了。通过上面诸位的发言，我们可以看出，架构师得是一个“全才”，不但在技术上和业务上要做到“两手抓，两手都要硬”，更是得需要持续不断的修炼和学习，才能成为一名合格的架构师。虽然这是一条充满挑战的道路，但也同样充满了乐趣与收获，正所谓“无限风光在险峰”，读者朋友们，你们做好准备了吗？
C. Android 开发有哪些新技术出现
建议先看看android架构师之路的教程。
基本OOP知识
业务内涵的分析抽象&表达
Messager框架与IMessager接口
Native核心服务的Proxy-Stub设计模式
D. 谁能分享下百度云，安卓开发视频教程，
我有
《Android架构师之路
网络层架构设计与实战》
《Android
专项测试
Python篇》
《Android应用发展趋势必备武器
热修复与插件化》
《Android自动化测试实战
Java篇
主流工具
框架
脚本》
这几个视频教程可以吗
E. 如何从程序员到架构师
程序员到架构师的技术成长之路分为几个典型的阶段：工程师 - 高级工程师 - 技术专家 - 初级架构师 - 中级架构师 - 高级架构师，总的成长原则是每个阶段都需要“积累经验、拓宽视野、深度思考”。
F. web架构师学习之路，有大神能指条明路吗，已coding3年！熟悉设计模式。要看什么书，学习什么知识
我认为吧，像架构师啊，设计师这类的吧，不在于他掌握了多少技术，会使用多少技术，关键在于它深刻理解他目前所使用技术的特点和原理，比如设计模式，他深知每个设计模式的特点，通常在怎样的业务场景下使用之类的！这是技术层的！接着来就是业务层的，你特别熟悉你目前所做的项目的业务，来龙去脉。其实最关键的还是业务性的，技术性的了解大概，然后真的用的时候可以查资料，做实验之类的，业务是在架构师的心里，没有资料可寻的，然后他的工作就是把这些业务需求用技术把他们关联起来！这些都不是那本书上能给讲的，而是平时多积累，多思考吧！
当然开始你也可以找本关于架构师之类的书，或者网上的资料，这些都很好找，这些书不是看了你就可以成为架构师，而是给你一个做架构师的思路，然后慢慢再从工作实践中积累吧！
G. 系统架构师有没有前途，待遇怎么样。
你好，互联网架构师是行业内紧缺的Java高端人才，待遇属年薪百万级。
1、Java构架师之路
对于工作多年的程序员而言，日后的职业发展大部分人无非是转型管理和晋升架构师两种选择。
架构师在公司中担当着“IT架构灵魂人物”的角色，因为他们不仅做着架构师的本职工作，还同时做程序开发，写核心代码。另外，架构师依旧是技术高手，编程能力依然是一流的。
对于架构师和项目经理，不同能力的人，不同的公司，薪资水平都不尽相同。但就这两个职位而言，都需要具备非常高的编程技能。
希望我的回答对你有帮助！
H. android从程序员到架构师之路的作品目录
Part-1: 从架构到代码的过程
1.1 敏捷与架构的完美组合 敏捷开发的原则和价值观 开发、架构、测试之关系 架构在敏捷过程里的角色 架构师在敏捷过程的职责 过程观点：(需求)测试做<反馈>，敏捷(过程)做<迭代>； 分合观点：(架构)设计做<分>，(代码)开发做<合> 测试触发反馈，反馈带动迭代，迭代驱动<架构à代码>重构 迭代促进了<架构师&开发者>的心灵沟通与携手协作 举例：架构师如何设计敏捷的起始架构(Simple Solution) 加法设计：围绕问题( Problem)和愿景(Vision)，产生创意构想(Creative Idea) 减法设计：创意爱上限制(Creativity loves constraint) 1.2 代码是架构的外貌，永远青春 架构师与开发者的合作成果：架构+代码=软件(系统) 架构是软件的骨架、代码是软件的外貌 架构是软件的核心 架构的用意：创新组<合> 架构设计的焦点：接口(Interface) 设计决策具有<未来性>，系统才能适应未来 1.3 设计与开发的分工合作 架构设计的目的是：组合 架构师做<分>，支持开发者做<合>，合作实践(系统)组合 分得妙，就能合得快(即：分之以为用，合之以为利) 分得妙，就能得好接口(Interface) 架构师的核心工作：接口设计(Interface Design) 开发者的核心工作：依据接口，开发(系统)模块并整合 有许多种开发者：如App开发者、底层系统开发者等 1.4 敏捷思维：尽快呈现架构的外貌 接口设计是<物>的组合设计 接口设计是<事>的分工设计 架构师设计多种接口来支撑分工与组合 架构师心中的4种接口：SI、PI、API和UI SI：本架构与外部系统之间的整合接口 PI：本架构与内部挿件(Plug-in)之间的接口 API：本架构与应用程序(App)之间的接口 UI：App与用户的互动接口 l 依循敏捷原则，接口迅速落实为代码，尽快呈现外貌
1.5 EIT造形：接口美丽的外貌 认识EIT软件造形 EIT造形：呈现核心设计的外貌 EIT造形的<I>可涵盖三种：SI、PI、API EIT造形的<E>代表本架构 EIT造形的<T>代表本架构的配件(即插件：Plug-in) 1.6 一群<E&I>美妙的组合是：框架(Framework) 认识GoF的设计模式(Design Pattern) 随着敏捷的迭代过程，EIT造形会逐渐增加 如何巧妙组合渐增的EIT造形：擅用设计模式 组合起来，就成为软件框架了 如何迭成多层级(Layer)的框架体系：以Android为例 Part-2: 从Android框架代码中学习设计
2.1 基础设计模式(Pattern)的代码：以Android为例 Template Method模式：IoC(控制反转)机制 Observer模式：接口设计 Abstract Factory模式：两个EIT造形的组合 Adapter模式：封装接口 Composite模式：实践组合 Façade模式：组合体的接口设计 EIT造形是原子，设计模式是分子 更多EIT造形的组合模式：以Android代码为例 2.2 从 UI框架入手 View体系的架构设计(使用Template Method模式) Activity-View的架构设计(使用Factory模式) Layout-View的架构设计(使用Composite模式) WMS(WindowManagerService)-View的架构设计 WMS-SurfaceFlinger的架构设计 Surface-Canvas(画布)的架构设计 SurfaceView与OpenGL的3D绘图架构设计 ListView框架的设计 2.3 跨进程(IPC)架构设计 Android 的IPC幕后设计：BD(Binder Driver)驱动架构 以IBinder接口包装BD驱动的服务 包装IBinder接口的Proxy-Stub设计模式 Proxy和Stub类别的代码 设计Proxy和Stub类别的API 如何自动生成Proxy和Stub类别代码 IBinder & AIDL方法 方法(一)：Implementing a Binder 方法(二)：Using a Messenger 方法(三)：Bound Services 2.4 Java与C/C++两层框架的设计 JNI(Java Native Interface)代码开发要点 JNI的数据型态(Data Type)转换规则 JNI的线程(Thread)模式：JNIENV类的设计 正向通信：Java函数调用本地C函数 反向通信：本地C函数调用Java函数 Android HAL架构设计 HAL(Hardware Abstraction Layer)的意义 理解runtime与HAL Stub 撰写HAL Stub代码 Stub调用Linux Kernel的方法 2.5 核心服务的框架设计 认识核心服务(Core Service) 核心服务都是在开机过程中，由Android的INIT进程启动的 包括Android Service和 Native Service两种 以Java语言撰写的，就称为Android Service 以C++撰写的，就称为Native Service 亲自撰写一个核心服务 撰写一个C++类别 继承BBinder基类，继承得来IBinder界面 提供接口给Java层(透过JNI)调用 2.6 JUnit测试框架的设计 Android的测试工具，都是基于JUnit测试框架的 JUnit框架也是由许多EIT造形所组成；其TestCase基类是<E&I> 从基类衍生出各子类，如ServiceTestCase就是扩充的<E&I>；其内涵的setUP()和tearDown()函数就是<I> 可撰写<T>(即Test case)代码，来启动TDD机制 可使用TestSuite基类来管理一群相关的<T>(即Test case) Part-3: 梳理你的架构设计思想、方法和模式
3.1 复习设计概念与技艺
概念复习 说明框架的起源、分层与其“无用之用”效果 阐述应用框架魅力的泉源：控制反转(IoC, Inversion of Control)机制 深入认识控制反转机制 主控者是框架，而不是应用程序 现代应用框架：采取广义IoC观念 框架的重要功能：提供默认行为(Default Behavior) 技艺复习 抽象(无之)与衍生(有之) 打造框架：细腻的抽象步骤 基本步骤： 细腻的手艺(一)：数据抽象 细腻的手艺(二)：函数抽象 细腻的手艺(三)：将抽象类别转为接口 善用类的继承(Inheritance)机制 设计基类的抽象函数 抽象是手段，组合是目的 UML复习 UML的3种基本图表：类图、顺序图和用例图 以UML表达设计模式和框架 EIT造形的两种表达：UML图和代码 3.2 架构设计的需求分析方法 基本设计技能：把轮胎拔掉 伟大的雕刻师罗丹( Musée Rodin)说：”把不必要的部分去掉” 买主需求：想想为什么(why)汽车架构师会决定把轮胎拔掉呢? 其背后的理由是：买主来了，才知道买主对轮胎的偏好或特殊需求。只有等到买主决定和挑选了轮胎之后，才能将轮胎装配上去。 探索买主需求 为什么把轮胎拔掉呢? 为什么火锅店的桌子要挖洞呢? 为什么餐厅要分开<食谱>与<点菜单>呢? 3.3 接口设计模式 什么是接口(Interface) 在OOP里，将接口定义为一种特殊的类别(Class) 在Java里，将”纯粹抽象类别”称为接口(Interface) EIT造形的接口表示为<I> <I>可以合并到<E>里 谁控制<I>? <E>成为控制点 引擎<E>à<I>à驱动轮胎<T> 如何控制API ? UI与API 被动型API与主动型API API与商业模式 API决定控制权&金流 没钱就改版，改版就有钱 以HAL为例，说明API = 话语权 谁拥用接口的制定权，谁就掌握控制点，就能获得较大的话语权 从API看控制力量的强弱等级 把控制力传播出去 Part-4: 亲自<敏捷+架构>、并迭代出代码
4.1 情境范例：”手机访问TV/STB” 愿景：多屏互动、幸福家庭的实践 亮点：许多智能设备大量进入家庭，在家里的Android TV建立一朵私密云，来整合窗外多个云平台和手机移动终端，变得流行起来。 情境：手机远距访问TV，透过TV打开家中的壁灯开关 架构：基于<手机+TV>的大小机相联、大小屏幕互动的新架构 设计：设计TV里的框架<E&I>、撰写插件<T> 技术： 在外的家庭成员透过手机浏览器(Browser)上网访问家庭云，您可以在家庭云里，安装一个i-Jetty网页容器(Web Container) 此时，I-Jetty里的HttpServlet就是另一个<E>，而它的doGet()等函数就是<I> 您写的servlet代码就是I-Jetty的<T>，它接受手机的访问 4.2 实际开发：依循敏捷、落实为代码
<架构设计>阶段的敏捷迭代 Step-0. 准备测试计划 订定此阶段的测试方案(Test Case) 以Android手机Browser为测试方案的执行软件 Step-1. 设计敏捷过程的起点架构：Simple Solution 通信协议：手机与TV采HTTP通信 软件接口：TV端的EIT造形与手机端Browser对接 设计：以UML表达EIT造形 代码：赚写I-Jetty的Servlet来实践EIT造形 Step-2. 启动TDD机制、进行迭代 从手机来实机检测TV里的EIT造形的接口代码 依循TDD的反馈，迭代Step-1和Step-2的活动 <代码开发>阶段的敏捷迭代 Step-3. 准备测试计划 订定此阶段的测试方案：基于用户需求(Requirements) 以Android手机Browser为测试方案的执行软件 Step-4. 以上阶段Step-2产出的EIT造形为起点架构 Step-5. 依循测试方案，展开细节设计和代码开发 撰写Android App代码：基于Android应用框架 I-Jetty的<T>调用Android的App App透过JNI调用Android的Zigbee驱动代码 Zigbee驱动透过Dongle发信号给壁灯开关 Step-6. 启动TDD机制、进行迭代 从手机来实机检测TV里的有关代码 依循TDD的反馈，迭代Step-5和Step-6的活动，直到完成 4.3 继续敏捷迭代、开发新功能
新功能1：手机控制TV里的Camera拍照片 TV/STB内的i-Jetty含有servlet代码，让手机可以远距来访问它 TV/STB则内含Camera驱动，能控制摄像头硬件 运用EIT造形和敏捷迭代，开发软件来整合家外的手机与TV/STB上的摄像头硬件，让家庭成员随时从手机来打开TV/STB的摄像头，拍了照片送回到手机上呈现出来 展开敏捷过程，直到完成 新功能2：手机控制TV将照片送上云端(Cloud) TV/STB将Camera拍摄的照片送上云端：例如Google的GAE等 基于WiFi通信协议 展开敏捷过程，直到完成 Part-5: 架构设计应用：支持跨平台
5.1 三个架构设计策略 三个实施策略： 策略-1：把它”EIT(设计)”了 策略-2：挟天子以令诸侯 策略-3：建立中间件(middleware) 5.2 跨芯片(小)平台：采取<策略-1>
情境A：先有别人的(小)平台，然后才建立我的平台 小平台是指别人的平台，该平台的变化决定于别人 为了跨平台，就不宜直接使用别人的平台 您设计<E&I>，而且设计<T>来包容别人平台的变化，这就称为：把它”EIT(设计)”了。 情境B：先建立我的平台，然后才让别人来扩充(Extend) 这反过来，让别人设计插件<T>来扩充(extend)您的<E&I> 别人为了保护他自己，也会将插件分成两部分：<壁虎尾巴>与<壁虎身体> 万一您的<E&I>有变化时，这只壁虎(插件)便能弃尾求生，让<壁虎身体>跨您的<E&I> 5.3 Android版本(大)平台：采取<策略-2> Android升级和版本变更频繁，终端必须随之而更新 Android是一个多层级<E&I>结构，各层都是由Google所开发，Google是强龙，位居天子角色，其设计<I>来控制您的插件<T> 您可以拿EIT造形搭配Proxy-Stub设计模式，规划Stub类别(曹操类)，制定自己的<I>，让<T>脱离Android的<E&I>所牵制；实现”挟天子以令诸侯”的效果 5.4 跨自己的平台(建立中间件)：采取<策略-3> 随着您的公司业务成长，您的平台版本变更频繁；如何包容自己平台的变化呢? 您可以规划一个上层平台<E&I>来吸纳自己平台的变化 此平台又称为中间件，其提供稳定的<I>(又称API)，也保护自己平台的变动自由度，实现”没钱就改版，改版就有钱”的效果 中间件还能提供您的专有API，来凸显自己平台的独特性 Part-6: 架构设计的成功案例分享
6.1 案例：重构PhoneGap的架构和代码 议题：PhoneGap目前只搭配HTML5的Web App 如何重构PhoneGap的架构和代码 让PhoneGap也能搭配一般的Native App 现况：目前PhoneGap的架构设计 HTML5 & PhoneGap可以让UI更容易跨平台 其依赖Browser和PhoneGap的插件<T>来吸收平台的差异化 如果插件很多时，PhoneGap里的PluginManager负责管理之 UI事件是从WebView传送到PhoneGap的插件<T> 目标 即使不采用HTML5，也能使用PhoneGap来管里插件 一旦不使用HTML5，PhoneGap就不再搭配WebView 于是，PhoneGap转而搭配一般的View，如Button等 UI事件(Event)改从一般的传送到PhoneGap的插件<T> 收获 如何拦截App的启动事件(onCreate事件)和UI事件 以EIT造形加快理解PhoneGap框架的结构 深刻领悟<I>的设计要领：如IPlugin接口设计 熟悉从<重构设计>到<重构代码>的过程 6.2 重构的设计思考 重构范围内共有3个EIT造形的美妙组合 第1个造形：{ Activity-DroidGap } 第2个造形：{ WebView-CodavaWebView } 第3个造形：{ PluginManager-Plugin-<T>} 熟悉从<重构设计>到<重构代码>的过程 因为不再搭配WebView，所以前两个EIT造形都必须重构 第3个造形最复杂 上上策是：不重构第3个造形，其内涵和接口代码都保持不变 成功地让第3个造形跨到重构的新平台(即前两个造形) 6.3 案例的成功关键和启示 关键：在于上述的设计思考 洞悉：心怀EIT造形去观察架构 技巧：从<I>观察重构的变动震幅，找出上上之策 启示：优越架构，带来易于重构的机会，创造了系统未来性