第一个成功的公司项目已经进入稳定阶段，实施也越来越流程化，有一些经验教训也得总结总结了。
首先是需求分析，这一项是大头，关系着项目的成败，成功地项目一定是充分听取了客户的需求的结果，然而事情做起来是那么的困难。因为客户有时候都不知道自己想要什么样的东西，所以很多时候唯有把握个大概的需求，随即投入设计阶段，等ui/功能都出来，这时候客户的二次需求开始井喷，这个流程应该这样这样，这个操作不是这样的，这个东西应该加多个设置，默认不出来，等等等等。。经常性的推倒重来后，对信心是个打击，对耐心是个摧残，然而对自身设计能力的提高却是显而易见的。需求就是需要时时沟通，有时候还得反复问清楚，客户需求的描述不一定就是那么清晰，可以理解，客户也是人嘛。作为设计人员，时不时地抱怨也是情有可原。可以说，项目就是在客户与开发人员之间反复沟通的情况下，才有可能从源头上把握项目的根脉，一条条的捋清楚，项目最终的原形才会慢慢露出水面。我接触的这个项目3年前已经立项，3年过来，共进行了3，4个版本，才有了今天这个稳定版，项目经理付出了艰辛的努力，我们这些设计人员也不断得到提高。
设计阶段，是产品是否健壮性的关键，有一个重点要说的就是,归类能力一定要不断提高，灵活化的设置不是将简单问题复杂化，而是必须的。先说说比较喜欢的模块,第一个是多语言模块,因为这个系统服务的是欧洲市场,所以多语言是必须的,基本上有两种多语言形态,一种是界面多语言,就是各种出现在界面上的按钮文字,提示等.另一种是数据多语言,也就是有一些数据是可被用户配置,并最终显示在页面上的.这两种形态如何很好的结合在一起呢?而且客户要求可对多语言内容进行翻译.于是我们最终设计了这样的结构
1.对于界面多语言
数据库结构设计:
1.language - 存储多语言, 关键字段 - language_code(en for english,cn for chinese...)
2.multilang_variables - 存储多语言变量
3.multilang_content - 存储多语言变量对应的多语言内容，关键字段(language_code,multilang_variables_id,content)，很简单，一个变量可对应多种语言的内容．
文件结构设计
<全局多语言模块类文件> #这是一个虚拟的模块,有模块编号
|
<模块类文件>
|___ 进入一个模块页面的初始化阶段,就会load入所属模块的多语言类.类名: multilang_模块id ,继承自全局多语言模块对应的类
基本流程是开发员可在多语言添加对应模块下多语言变量和内容,入库后,可动态化将数据各个模块的多语言数据动态生成php类文件，分别部署在不同的语言文件夹下．
最终成型的文件如下
/project/language/en/global.php,这个文件存储的是各模块通用的多语言变量．
class MultiLangGlobal
{
public $g_add = 'Add';
}
/project/language/en/member.php，这个是某个具体的模块的多语言类文件
include_once dirname(__FILE__)."/global.php";
class MultiLang_member extends MultiLangGlobal
{
public $first_name = 'First name';
}
这样在具体使用多语言时，只要在一个通用配置文件里，自动引入相应模块的多语言即可．
/project/admin/?module=member&action=list
$module = getModuleName();
include "/project/language/".$_SESSION['language_code']."/Multilang_".$module.".php";
2.对于内容多语言
在最初参考了几个开源项目后，最终决定使用以下设计
数据库设计:
1.multilang_table - 存储使用多语言的表,关键字段table_name(存储数据表名)
2.multilang_info - 存储多语言内容,关键字段:language_id(关联language表，表明数据为何种语言),key_id(关键key),content(多语言内容)
基本设计思路是这样的，比如有一个表，叫category分类表，表内数据需要为多语言数据，可翻译。那么multilang_table将有一条记录，字段table_name值为'category'，而multilang_info将与multilang_table关联(根据multilang_table_id pk关联)，然后记录category_id值(key_id字段)，category的内容(content字段),当然还有语言id.通过这两个表，就知道某个表某条记录的多语言值。
通过这两项设计，就实现了用户可方便翻译的需求，如果让用户在几十上百个多语言文件里去一个个翻译，那用客户的话说就是this is a disaster,如果客户能在系统按模块来翻译，不仅清晰，而且开发这边很容易扩展功能，比如批量翻译，比如批量导出导入等等。
当然目前多语言模块还是有一些不够完善的地方，比如如何让用户清晰的知道哪些是改动的多语言变量，注意，改动主要是指添加/修改。因为项目不断在扩展功能，一个开发人员开发一个新的模块，就有可能添加不下10个多语言变量，而且进行一些流程回顾，为了操作更清晰，也很有可能会改动一些描述信息，这个时候就需要一种机制能够让客户清晰的知道哪些是已经改动的多语言变量，以便客户也快速的更改翻译.还有目前内容多语言都是嵌入在所属模块页面内，而并不是和界面多语言归并到同一个多语言管理模块进行管理，这也造成一些混乱，这些问题都比较棘手，需要进一步进行研究，设计。
还有一个属性设置模块，比较灵活。需求是这样的，客户需要针对不同类型的房子，设置一套属性，比如如果是别墅类型的，将有其一套属性，类似多少间浴室，多少张床，有无婴儿床，冰箱什么牌子。。。如果是公寓类型，就有另一套属性，有些可能和别墅一样，有些又是自己独有的属性，这些东西显尔易见，都需要一套强扩展性的设计来满足需求。根据客户反馈的信息，我们将属性设计为一个有3级的树形分类，最上一级是根，下面可建立不同的分类，然后每一种房屋类型与这一级分类关联.分类下又可建不同属性.这样每种类型房屋都可引用相同或不同的属性分类，很好的解决了问题。当然这一个模块还是有不足的地方，主要是功能方面，因为产品服务不同企业，譬如导入导出，copy属性等等功能是必要的，要不然实施起来颇为不便,目前仍没有时间去着手开发。至于设计方面，客户方还是比较满意的，比较清晰，他们也很快可以上手，当然这少不了后期的编码，以及ui设计。
还有一些模块的设计也不错，待有时间再仔细补上。
接下来是编码阶段，这是最烦人的阶段，有时候为了避免推倒重来，经常会在现有的代码架构上缝缝补补，由于前期估计不足，模块开发周期又要求比较短，定期的代码重构依然没能解决代码混乱的局面，这里面持续而反复的需求是一方面，代码设计的缺陷也是一方面。期待能有下一版本的开发时间，相信需求稳定后，再进行一次设计，代码的扩展性将有进一步提高。
至于实施，真是项苦差事，实施人员总在感叹，要是有这么一项功能该多好啊,要是这个流程设计得简单点就好了...等等等等，每每听到这样的声音，我们开发设计人员都感觉很无奈，有些功能游离于客户需求之外，你认为它不重要么，其实很重要，让功能更加完善而利于操作,让实施人员少做一份工作，不就提高了工作效率，缩短了产品上线的时间了么。当然这些也是需求的一部分，需要时间，人手。有时候刚想着手设计，客户一纸需求飞将过来,得，还是先把客户布置的作业先做了吧。
还有另一个参与过的项目，我是主要设计，编码人员，总体设计得不尽人意，混乱无章，有自己的原因，也有决策者的原因，这个将撰文分析一下。