开发人员练就百般武艺为了啥?

业务领域,是软件的核心价值所在
服务器君一共花费了284.991 ms进行了6次数据库查询,努力地为您提供了这个页面。
试试阅读模式?希望听取您的建议

业务领域,是软件的核心价值所在。

敌人还是朋友:项目经理和架构师

无论是买成型的软件产品,还是出资开发项目,客户投资的是软件的业务价值。项目经理直接为这个目标负责,尽量少的成本,尽量短的时间,生产出高业务价值的软件产品。架构师则是跨越单个项目,长期为这个目标负责。

项目经理与架构师是天生的敌人,短期看这是对的,长期来看,他们是真正的朋友,是战略朋友。没有项目经理项目会死得很快;还而没有架构师,公司会死得很惨。

项目经理的角色和作为,我仍比较容易理解。一则,他以短期为目标,人都是短视的,所以项目经理的角色比较接近人的直觉;二则,项目经理的活动也是我们常见,常说的,例子故事较多。而对架构师,我们却颇多误解,至少也是含混不清。

我曾经问过很多开发人员,你的五年计划是什么?几乎无一例外的回答都是想成为一名架构师。特别是在校学生,几乎是脱口而出。这是一个有意思的现象。我的理解是:

  1. 他的职业方向是技术方面,想在技术上有所建树,架构师是一个明显的技术标杆,从这一角度,我很肯定他们的回答。
  2. 业界对软件职业两条线,项目轻理和架构师,这个理论已经深入人心,也不错。
  3. 架构师成为脱离,“并发苦海"的代名词,颇值商榷。

架构师不是一个只管“架构”的家伙,他更是一个集大成者。各种技术,无论高雅还是低俗都是他囊中的武器。还有低俗的技术吗?有的,非常多连刚入门的开发者都觉陈旧的好东西。

什么,继承,你老土了吧?开口只会说设计模式都不敢说你是做开发的。现在,都是云,云开雾照的云。NoooooSQL一听这名字就得劲。否定错误就是正确,这世上哪有没有瑕疵的东西。所以,我们的口号就是否定一切!好了,扯太远了。

是的,架构师的工具装中应该有琳琅满目的各种称手的工具。但这只是从一个视角看架构。我们很多时候盯这些工具本身盯得太紧。看工具或者技术本身,如何的眩丽、如何的酷毙。今天,我们来换个角度,看看工具和技术的目标,他为谁服务。标。

从Repository到Domain

首先,仓储模式(Repository)。Repository不是DAL!虽然它们如此的接近,有的架构设计设置就把它们合二为一了。Repository用于对象持久化,DAL是从数据库中操作数据。仍然迷惑,看不出两者的区别?

让我们来一个思维的游戏:

  1. 一般三层架构的文章用来解释DAL层的好处,用数据库的变更做例。比如:之前系统是用ORCAL数据库,现在要换作SQL Server。如果,我们使用了DAL这一层,就可以很容易实现,而不触及系统其它。
  2. 我这里需要你设想另外一种变更,从数据库存储数据,切换到用文件系统,如CVS或XML文件放数据(如果你要想的更高级一点,更酷一点,可以想想用云储存)。这时候,DAL这一层的隔离已经没有办法解决了。而是要更上层,这就是我们的Repository。

所以,可以说Repository和DAL是两层。自然,这增加了复杂度,你确实需要衡量你系统是否必要。另外,nHibernate可以很好的担当了DAL的角色,同时对Repository的支持也很好。应用得当,可以减少很多工作量。

再回到Repository的描述,Repository用于对业务域对象持久化。细心的人可以发现,我加了三个字”业务域“。

从MVC到测试

其次,MVC。MVC不是三层架构。虽然看起来它也分三块,但决对不是。另外,MVC中的M不是业务域,决对不是,虽然有些系统实现采取了这种方式,把MVC的M和业务域对象合二为一,但是原则上它们完全不是一回事。微软用VM(View Model)代替M还是有点意思的。

MVC最大的目的和功能,是把最终界面相关(V的部分)的东西最大限度的隔离出去,因为这部分是不可测试的,而那些仍然与界面相关,含有大量逻辑(算法?)的部分抽象出来,或者放入C中,或者放入M中。使得可测试的代码的边界,尽可能推到UI的最前沿。虽然,慢慢现有不少UI测试自动化工具的出现,功能还不错,但是与单元测试,代码直接接口的测试相比,效率和质量还是不可同语。

仍然回到对目的的思索。MVC是为什么?为了测试?恐怕还是不最终的目的,测试又是为了什么呢?

从自动化测试到Domain

单元测试,行为测试,集成测试, 众多名词,我不想讨论它们之间的差别,作为一类概念,从名称上,他们只呈现了一半的内涵。还有一个重要部分被漏掉“自动化”。自动化单元测试, 自动化集成测试,才更为准确。自然,这里我也不讨论非自动化测试,如功能测试,验收测试。

自动化测试的好处是不言而喻的。前文中MVC提到的测试,就是指提高自动化测试的覆盖率。对整个系统来说,达到100%的覆盖率是根本不可能的。在这个大前提下,我们很容易忽略提高自动化测试覆盖率的重要意义。90%与70%只是数字的区别?让我么走近一点,把系统拆分一下再看。整个系统不能达到100%,具体是那部分不行呢?前面提到的View是一个,数据库又是一个,不是完全不能测,理论可以,实际有些麻烦,不值当。还有就是一些外部功能,如发邮件,读写文件。文件操作这个看来经常用到的功能块却是单元测试的大敌。所有这些排除后,再回头看看,我们可以说剩下的100%能测试,也必须测试,不然就是架构和设计的问题。

剩下的这100%中,很大部分就是业务领域模型,重中之重,难中之难,也是值中的超值。

代码工厂=CRUD?

前面的Responsitory也好,MVC也好,看似复杂,其实简单,他简单在逻辑固定。昨天,我花了一个小时,完成了一个简单类的添加,现实的功能,从前端controller(我叫command)到服务层,业务类,再到Respository及数据库,只花了一个小时。因为逻辑简单固定,相当于一个表的CRUD。很多推广的所谓一站式解决框架,都是用这种情况的典型案例,特别是微软,从VB开始,到现在的Entity Framework,最酷的演示就是只要添加几行数据定义,一分钟,从界面到后台完成。当然,这比我昨天的手工作业要快得多。但是回到实际的商业软件开发,从来没有基于这样的高效而能一天完成一个项目。不是吗,如果按一分钟一个界面或者一个数据表,一个有100个表的项目已经足够大了吧?这样简单做个乘法,我们不是100分钟就可以搞定了吗?实际呢,不用说100分钟,就是100个小时也不够。所以,这样的演示根本没有含义,可是,很多人却乐此不疲。

我以前公司,有一位架构师,在iBatis的基础上,完成一个所谓框架,可以已经创建的数据表,自动生成业务对象,和CRUD的代码。然后骄傲的宣布,80%的开发工作已经完成。可是之后,项目又开发了两年。如果说是80%的代码量,我可以说是,80%的工作量?我怀疑。

这正是我们很多架构师没有意识到,或者不愿意承认的事实,框架设计好了,架构搭建好了,这才刚刚是个开头,而远远不是结束。

这是百般武艺亮尽的结束, 是业务领域探险的启程。

本文地址:http://www.nowamagic.net/librarys/veda/detail/1809,欢迎访问原出处。

不打个分吗?

转载随意,但请带上本文地址:

http://www.nowamagic.net/librarys/veda/detail/1809

如果你认为这篇文章值得更多人阅读,欢迎使用下面的分享功能。
小提示:您可以按快捷键 Ctrl + D,或点此 加入收藏

大家都在看

阅读一百本计算机著作吧,少年

很多人觉得自己技术进步很慢,学习效率低,我觉得一个重要原因是看的书少了。多少是多呢?起码得看3、4、5、6米吧。给个具体的数量,那就100本书吧。很多人知识结构不好而且不系统,因为在特定领域有一个足够量的知识量+足够良好的知识结构,系统化以后就足以应对大量未曾遇到过的问题。

奉劝自学者:构建特定领域的知识结构体系的路径中再也没有比学习该专业的专业课程更好的了。如果我的知识结构体系足以囊括面试官的大部分甚至吞并他的知识结构体系的话,读到他言语中的一个词我们就已经知道他要表达什么,我们可以让他坐“上位”毕竟他是面试官,但是在知识结构体系以及心理上我们就居高临下。

所以,阅读一百本计算机著作吧,少年!

《计算机程序的构造和解释(原书第2版)》 艾伯森 (译者), 裘宗燕 (译者), 等 (译者)

《计算机程序的构造和解释》(原书第2版)1984年出版,成型于美国麻省理工学院(MIT)多年使用的一本教材,1996年修订为第2版。在过去的二十多年里,《计算机程序的构造和解释》(原书第2版)对于计算机科学的教育计划产生了深刻的影响。第2版中大部分重要程序设计系统都重新修改并做过测试,包括各种解释器和编译器。作者根据其后十余年的教学实践,还对其他许多细节做了相应的修改。《计算机程序的构造和解释》(原书第2版)自出版以来,世界各地已有100多所院校采用《计算机程序的构造和解释》(原书第2版)做教材,其中包括美国斯坦福大学、美国普林斯顿大学、英国牛津大学、日本东京大学等。

更多计算机宝库...