为什么我要规范所有团队用同样的架构开发项目?

　　前阵子在上架构与框架设计的课程时候，提到几件事情。我说...

　　►要设计出好的架构不难，但真正能够实施(implement)在团队中的却很不容易。

　　►架构设计是一种取舍，没有绝对完美的做法，有得，就有失，架构师除了要有足够的技术能力，更重要的是，要有足够的沟通能力。

　　►架构设计只有一件事情最重要，就是能够实施(implement)，无法实施的架构，再美也是枉然。(不能实施的因素有很多，除了设计的好坏，更多的时候是架构师是否能够同理开发人员技术程度，以及能否在导入时突显这个设计的优客人)

　　►架构与框架的设计与导入，不仅仅是建构开发团队的基础，更是一种引导或限制，让开发人员被框在某一个规范中，在有限制的状况下自由发挥(我甚至补充，在软件开发和项目管理的世界中，过度的自由是一种罪恶) 。

　　我无法在有限的课程时间中，解释某些事情。因此，趁着有空且记忆犹新，我想来谈谈我们过去一两年做的架构设计，以及为何我要求几个团队中，所有的成员(PO/PM, SD/SM, Developers)都必须采用这样的架构。

　　===================================

　　先讲讲背景...

　　最近这几年，我们在Web开发上扬弃了从服务器端产生HTML的方式，而改采接近SPA(Single Page Application)的model来进行项目开发，也因此，整个ASP.NET MVC，严格说起来，我们只有用WebAPI，其他的部分都是通过我们自己开发的框架(Framework)来搭配与运行。

　　简单的架构图如下：

　　在这个架构底下，Framework 本身负责 Services Layer(中间橘色的那块)、Client 端对服务器端 Server Components 的调用(调用)、以及 Cross-Cutting Components(左方竖着的那块)。

　　采用此Framework 架构的开发人员，只focus 在底下2个部份的开发，而将其他部分交由这个Framework 处理，分别是：

　　1、Server Components 开发

　　Server Components 以.NET Assembly(.dll)的形式开发，开发人员可以建立标准 的.NET 4.5.x Class Library，通过引入 Framework Server Component Nuget Package 来建立 Visual Studio Project。开发后的.dll会被布署到上图中最底下蓝色的那层Backend Application Service Layer中。

　　2、Client 端 UI 开发

　　Client 端 UI 有各种不同的形式，如果是网站可能是 HTML Pages，如果是 Windows Desktop application，则可采用 WPF 或 Windows Form 开发技术。如果是 Mobile Device，则可能是 Windows Store App, Windows Phone App, 或是 iOS/Android Apps…etc.。

　　不论是何种形式的前端Project，均可通过引入相对应的 Nuget Package，取得 BackendServiceClient 这个共用 Component 来进行 Server Component 的调用，以及开发 Client 端所需要的各种 Helpers/Utilities。

　　通过这样的开发方式，你会发现，这和你以前习惯的开发方式 -- “开发人员直接打开Visual Studio 2013，用微软内建的范本来写程序…”会有着很大的不同。

　　首先，我们只让开发人员写两个部分的Code，分别是:

　　1、ServerComponent(.dll)

　　2、Presentation(UI)

　　我们称之为ServerComponent的部分，本质上就是Class Library，也就是.net的assembly(.dll)，其中的具体内容就是一个一个的Method(我称为ServerMethod)。

　　除此之外，其他的源程序我们都已经通过framework所封装，包含身分验证、日志(Log)的储存、例外处理(exception Handling)、权限与安全性…等。都由Framework中的AOP机制来达成。

　　所以我们的开发人员在进行ServerComponent的撰写时，毋须担心或过度的处理cross-cutting concern部分的机制。撰写源程序时，只要继承自我们提供的BaseClass，并专注在business logic的撰写即可。cross-cutting concern部分的机制，有我们开发好的一整组Attributes可以用。(例如，只消在ServerMethod挂上WriteLog attribute，该Method即可具有log的功能，挂上Exception Handling attribute即可自动处理例外发生时的纪录、retry、或alert...)

　　而前端UI(Presentation Layer)调用服务器端ServerComponent的部分，也是通过我们所建立的Services Layer与前端API。且不管前端用哪一种开发方式，是Web/Desktop/Mobile甚至是iOS或Android，都以同样的一个Helper(BackendServiceClient)来调用服务器端ServerComnponent中的Server Method(via ExecuteCommand)，也就是说，不论是开发哪一种前端，前端对于后端Business Logic调用的写法几乎完全相同。

　　前端开发人员需要发挥的就是UI的处理与特性，后端开发人员需要撰写与掌握的就是Business Logic。

　　简单总结一下，通过这样的架构:

　　1、后端开发人员需要会的技能是 C#, OOP, ORM(EF), 以及domain know-how

　　2、Web前端开发人员需要会的技能是 HTML/JavaScript(or some js framework)

　　3、Windows desktop开发人员需要会的技能是 XAML/C#

　　总的来说，我们尽可能地压低开发人员所需要的skill set，这样的目的是确保开发成本降低，并且让交接与维护更为容易。

　　我要坦白说一句，这对于开发人员来说不一定100%是好事(但放心，我们并没有苦待开发人员，我们有架构设计与RD单位，让具有RD个性、特质、与能力的开发人员，反而更能够有另一条更有挑战也更有趣的升迁管道)，但这对于项目管理来说，却是一个很大的利基。当每一个案子都用这样的方式和架构来开发时，你会发现每一个项目的源程序写法与架构都完全相同，在交接或维护时，立刻可以看到优客人，管理效率提升到PM会偷笑的程度。

　　如果依照过去的作法，每一个案子(或产品)都由该案子的Architect来从头设计架构，你会发现长期下来这根本是一个灾难。

　　首先，先不管坊间framework的变化程度(你想想从ASP.NET WebForm到ASP.NET MVC才几年? 再想想AngularJS从1.x到2.0的改变...)，也不管架构师本身的素养和能力。当每一个案子的特性不同，架构师往往会很“尽责”的去设计出贴近这个案子的开发架构，并且“顺手”就把最近学到的新技术给硬生生地塞进去。

　　你会发现很有趣的事情，在过度自由的开发环境中，同一个架构师(或同一个团队)，所经手的三个案子，可能会有五种不同的设计。每一次都有新的“改进”，而每一次“改进”，就意味着某些过去的作法被顶翻与抛弃，然后架构师又会持续在新的案子中加入了新的元素(或技术、或pattern)，企图让校能更好，让开发更方便，或是让XX更OO、让ZZ更YY....总之架构师或SD会告诉你...加入这个...加入那个...各种好处不在话下。

　　如果案子不用维护，那当然没有任何问题。但你有碰过不用维护的案子吗? 是了，少到几乎没有，所以开发完成之后，往往才是灾难的开始。

　　特定的开发技术，特定的前端框架，这对于开发来说都是机会，但也都是风险，对于维护来说则都是成本。即便用了某些框架，可以很快的完成某些功能，但，以后呢? 如果开发过程中碰到规格变更呢? 这些隐含的成本往往PM和开发团队都不太关心，但这却是日后无法结案或无法维护的主因。

　　也因此，最近这几年，我们力求统一开发架构，让每一个项目(甚至产品)的开发，都用完全一样的Framework(我们自己开发的Framework)，当有新的技术或是更好的作法，我们会邀请前线的开发人员，反馈给架构设计单位，并且每季定期释出框架(framework)升级。由于开发工具的进步，现在我们将框架通过nuget package来导入，升级时开发人员只需要update package即可自动升级。

　　正如同我前面所说的，架构和框架设计是一种取舍，这样做让开发团队自由发挥的空间减少，却让后续维护与交接的成本有效的降低。然而取舍，是一种需要智慧的决定。

　　有机会，我会再谈谈在企业和团队中导入开发框架时，所会碰到的阻碍和因应方案。

本文来源 我爱IT技术网 http://www.52ij.com/jishu/45469.html 转载请保留链接。