软件作坊模式工件应用论

软件作坊模式工件应用论

软件作坊模式是指一个小规模或零散的团队负责不同类别系统的开发、维护、测试等软件工作，强调的是单兵作战、个人全能型的模式。软件作坊模式下，单个程序员由于工作需要可能时而是需求调研、时而是自己选择开发平台进行系统开发、时而是接手他人系统进行维护、时而又是负责第三方软件的测试工作。对该模式下的团队来说，开发平台的多样性、辅助工具的随意性、软件工程化的低程度、系统转接维护的高难度等，一方面对程序员的能力要求存在矛盾；另一方面对团队的职能是极大影响。尤其在负责他人或第三方软件厂商转交的工作中，上面的弊端完全显现出来。

这种模式在当前非纯软件制造企业的IT机构普遍如此，外包大型软件、内产小型系统，尽管或多或少都采取了软件工程中一些规范化作法、流程和工具，但一旦成员变动，转交工作时由于不同的作法和工具，所产生的结果对负责承接工作的人来说是不可移植、不具有可读性和可理解性的，结果是从头开始整理系统。这和软件工厂模式是不一样的，该模式下，统一的开发平台、统一的工具、统一的文档。

基于统一的开发平台，在技术上而言，可移植可重用的软件模块便会在内部流转而不需要每个程序员去单独开发，同时，每个程序员独立负责一个模块开发在速度、效率、技术含量上都会有质的不同，更重要的是，统一的开发平台只要代码编写规范便会产生可读性很高的代码，而且由于都处在同样开发平台上，转接工作不需要承接者学习或熟悉或重新搭建一个平台。比如统一在J2EE平台上开发。但一个本来熟悉.net平台的程序员，突然要去承接J2EE平台的代码来开发和维护，显然是不可取的。在软件作坊模式下，就有可能产生这种情况，可能原来开发系统的某程序员是熟悉.net平台的，于是在.net下开发了，现在转交另一程序员，而该程序员则熟悉J2EE平台，这个时候该程序员由于工作需要就不得不重新学习.net平台才能胜任这份工作。不同开发平台的切换对技术的深入是不利的。

统一的工具、统一的文档、统一的流程效用是一样的。比如UML工具Rational，学习这个工具的成本是非常高昂的，不能为了一个系统去熟悉使用这个工具，但如果是统一的则任何适合使用的工具去学习都是必需的。这就好比如一个印鉴，这些统一的方式构成了一致的模子，不管谁来操作，结果都是一样的。任何程序员，输入是上一流程传来的标准化成果，输出的是下一流程需要的标准化成果，这中间程序员所作的就是在统一基础上用统一的方式加工输入产生输出。“标准、开放、共享”始终应该是IT精神的核心。软件工厂中每个程序员就是生产流水线上的一员，不需要理会太多，只需要拿起手上统一的器械加工到手上的半成品再转交给下环节。

对于程序员而言，软件工厂模式和软件作坊模式究竟哪个更有利于发展不再本文论述之内，软件作坊模式也不一定要采用软件工厂模式，由于工作性质不同，也不能同而化之。本文要论述的是如何在软件作坊模式下建立“统一”的意义，贯彻“标准、开放、共享”的IT精神。如何为之呢？笔者认为发挥工件的作用或可达到目的。何谓工件，笔者定义为取之工具部分，裁剪为适合可用之玲珑简化工具。软件工程的之一目的在于建立于对工作成果的共同理解，所以任何流程、任何说明（文字或图形）只要能达到效果即可，正是基于这一认识，笔者认为可以在软件作坊模式下裁剪一套简单而可行的工件，供团队成员使用。

无非是要描述工作成果以达成共同理解，在软件作坊模式下，不凡多采取表的形式来表述成果。笔者在本文所建议的工件大多是以表的形式体现成果。这里提取几大软件工程阶段所需的工件，需求阶段的叙事表、设计阶段的类点卡和类序表；对于架构说明，笔者建议和开发平台一起介绍，并就开发平台搭建作说明；在代码编写阶段，适当的规范是必要，但不需刻究，只需在类序表和类点卡的设计中补充说明各属性和函数作用，以便接手者尽快切入系统；测试阶段尤其是面临第三方软件的测试，测试文档建议结合早前需求和第三方提供的功能和性能说明以测试用例形式表现，集成测试则采用案例测试进行。本文这里重点说明需求阶段的叙事表、以及贯穿设计、代码、维护阶段的类序表和类点卡和开发平台与架构图说明。

为在软件作坊模式下，为建立软件开发人员与业务需求人员以及承接的其他软件开发人员之间的理解和共识，可采用叙事板和叙事表形式。叙事表示意如表1叙事表。

叙事表中的字段可以任意填加所需要来补充说明以建立共同理解。优先级指该功能完成的等级，点数是指完成工作时间，一般以天为单位。这个表简单明了地列出系统所需要完成的需求，并就需求进行等级和工作量估算，有利于业务需求人员和软件开发人员建立理解，同时对于承接的软件开发人员来说，功能的序列说明有利于其寻找相应的代码实现点并尽快理解业务需求。

表1叙事表

序列号	叙事名	叙事描述	优先级	点数（估计）
1	登陆	通过id和密码登陆	2	1

       实际上，在软件作坊模式下，外包下与软件公司的交流还需要建立在软件工程体系下，这里强调的是内部软件开发人员自产系统下建立工件应用的意义。而叙事表就是建立在软件开发人员之间以及与业务需求人员的标准工件之一。原则上就是：能够达成理解，并可以移交，符合一定标准设计。这就是自做工件的原则，以这个原则，软件作坊模式下的软件开发维护团队可以自我设计标准工件在内部流转，并使之成为成员自觉完成工作的成果标志。工件既是工具，同时也是成果。如叙事表，表设计的字段和意义本身就是为了实现需求描述的一个工具，而其同时也是需求描述的成果。不需要另行使用需求分析方面的工具，降低学习成本，同时又能保证沟通和理解的进行。而实际上软件工程最大的意义就在于用标准化工具产生标准化成果，这样某人完成的成果便可以移交到另一个人去完成下步工作。而软件作坊模式应用工件意义也正是如此，保证成员间的工作成果是可移植，相互间可理解。

确定需求后，设计上最重要的是确定架构以及实现架构所需的开发技术平台。这个在软件作坊模式下转交工作尤为重要。笔者这里没有比较现成的工件设计。但有两点需要在这方面的工件应用上涉及：架构图和开发平台搭建说明。为架构建立一套可开发的平台是必要的，同时应该给予开发平台主要插件应用的开发说明，如工作流程开发中，jbpm的应用。需要给出简单开发说明；如数据库开发中hibernate的应用；又如解析XML的DLL应用。

在详细设计和开发以及测试维护中，对于代码需要做功能或类上的说明，这里笔者给出了两种工件以应用。类点卡如图1类点卡示例。类点卡主要说明所完成的功能函数及其属性，如果有修改，则用时间表示其版本的前后。类序表主要是类之间关系及其与数据表关系的说明。类点表主要是完成类个别的说明，类序表则说明了类间关系。这两种工件可以合在一起，目的是软件开发人员明确代码中类的作用及与其他类的协作关系，及与数据表的互动关系。这两种工件设计的侧重点在于不需要非直接开发的人员能够尽快理解类关系及其具体类的功能，同时能对应起相关的表。类序表见表2类序表示例。

类名

类功能、业务方法、异常处理、安全方法、属性或变量。 给出代码中的类名、函数名、属性名。

图1类点卡示例

其他说明，如版本修改时间和修改者。

表2类序表示例

序列号	类名	控制类	协作类	数据表
1

       本文立意的出发点即在于软件作坊模式下，如何保证工作成果的可移植、可理解，而实现则在于工件的应用。至于具体工件的提出则依赖于具体软件作坊模式下的团队组成以及软件工作的侧重点，是维护还是开发。对电信下面的软件部门来说，基本都属于软件作坊模式，设计怎样的工件以应用应当受到重视，否则长期累积的系统爆发出问题的一天将是难以解决的。强调可理解、可移植是设计工件的前提，同时也是软件作坊模式最大的缺陷。