圆木菠萝罐

Basic Training结束了，9.1日开始Advanced Training，现在将这上班一个月学到的东西整理一下，因为公司的安全制度，所以在公司总结的东西不能带出来，现在只能靠回忆。这样也好，回忆出来的东西更加真实反映了所学的。

按照软件工程的基本流程，可以将整个项目分为几个阶段：Requirement Analysis, Project Plan, System Design, Documentation, Coding, Testing, Release.

Requirement Analysis

客户的需求是在一个文档中体现出来的，因为是training project，所以没有客户。通过分析文档，客户需要一个网上商城的项目，能够进行商品的管理，用户的管理，订单的管理等等，基本算是一个网上商城所需要的最基本最基本的功能。在需求中，我提出疑问，要不要加入用户注册功能，因为需求文档中没有说明。后面的QA session也告诉我这其实是Bug，因为属于“本应该有但需求文档中又没有的功能”。
另外客户需要一个User Service，要求要有Winform的管理平台。简单说就是用户双击桌面上的.exe，然后对数据库的客户进行管理。这部分要求用WCF实现，并且Client用C#实现。
整个的需求分析阶段是对分析能力的考验，你需要站在客户的角度来分析客户到底需要个什么东西，还好我们的客户需求文档是由Trainer写的，比较清晰。真实客户可能根本说不清楚自己需要什么，到时候也是对项目人员的考验。

Project Plan

当客户告诉你说，我们2个星期后要看到成果，你会怎么办？当然要做个详细的计划。而且这和上大学不一样，老师会告诉你这阶段你该做什么，到公司没人告诉你，你要学会自己安排。你可以前面安排得紧，后面安排得松，你可以选择每天加班到凌晨，也可以选择每天5：30回家（只要你有能力），公司24小时营业，如果你认为你是铁打的……扯远了。不过，到现在发现加班不是个好事，经常加班只能说明你的效率慢，能力不够。有本事每天按时下班，工作做得漂漂亮亮，那是最厉害的。
Plan就是对项目的每个阶段的时间估计，需要做什么，会遇到哪些Risk，遇到后怎么解决。特别是时间估计，这点在Plan中很重要。在后来我们的总结中，Trainer介绍经验，一般你的时间估计要比你认为“正常”的时间多一到两个时间单位。比如，我认为做Product模块要2天，但是时间估计要写3天或者4天，因为你不能保证在此模块中你遇到非常cost time的issue，所以要稍微延长些，以保证自己不会delay，经常的delay会给自己不少压力而且客户觉得你不Professional。

System Design

这部分考察工程师的抽象和设计能力。简单的说就是把客户的需求转化为软件系统的表述。根据客户的需求，我来设计相应的架构，从整个软件系统的大框架，到小模块的具体构成，以及coding时要采用的架构。这些整体设计不涉及details，只是各个模块的架构，然后可以把他们组合在一起。这一部分一般会和文档结合在一起。

Documentation

文档部分一般包含两个文档：Functional Specification, Technical Specification.
Functional Specification就是功能说明书，一般是对客户的需求进行总结。将客户口头或者简单文字描述的“场景”转化为清晰的模块架构。这文档不包含任何技术术语，只是对功能的描述，对模块的设计。文档里面包含有Use case（用例）以及各种模块的描述（包括总括和各种功能的描述）。Functional Spec 会给客户看，估计到真实项目中还会给客户签字确认。后面的QA session也说过，这里的设计很重要，如果前期不设计好，后面要改架构，时间和资金的cost会非常大。

Technical Specification就是技术说明书。一般是根据Functional Spec来写的。针对Functional Spec里面描述的模块，根据自己的System Design的抽象，将这些模块转化为技术接口的描述。接口的描述包括接口的功能描述，接口的方法头，接口的时序图，接口的运行过程描述。除此之外，还有对整个软件架构进行技术上的描述，包括分层（比如三层架构），数据库设计等等。总的来说，Technical Spec描述技术架构，但是跟技术语言和具体的技术实现details无关。你可以把Technical Spec给.NET, Java, PHP团队来分别实现。

这部分文档编写用了我们一个半星期，因为原来从来没有人做过，只有一个模版。模版每部分写什么也需要靠自己来悟，Trainer先不会告诉你，让你自己的理解来写，之后会一起来review和discuss怎么写好。

Coding

没话说，就是编码了。结合Technical Spec来写就对了。不过现实中很多人包括我也没有完全按照文档来编程，因为很多东西文档期间都没有想到。

首先来说三层架构，就是DAL, BLL, UIL层。DAL（Data Accessor Layer）数据接口层，所有对数据库的操作（写数据，读数据）都在这一层完成。BLL（Business Logic Layer）业务逻辑层，所有与业务相关的算法都写在这一层。比如说“删除一个用户的同时要删除这个用户的所有订单”。UIL（User Interface Layer）用户接口层，就是我们说的界面。所有的界面的元素，以及界面上的逻辑和验证都在这一层完成。

一开始一直以为自己是三层架构，后期才发现自己是两层架构，就是把DAL和BLL写在一起去了。然后先前低估了UI层的时间，其实UI层很多东西很复杂，包括那天研究gridview到凌晨4点，还是自己效率太低了。其实分层的好处是方便日后的维护以及架构的清晰，虽然说时间和代码量都要比两层或者不分层多得多。但是越到后期效果就越好。

使用存储过程。第一就是为了防止拼字符串太费力，拼得费力看得也费力。第二就是用存储过程不会出现当UI层输入非法字符的时候导致的安全问题。之前就没有用存储过程，然后到了后期全部改工程量很大。不改又容易出现安全问题，所以只好在验证上下足功夫。

还要注意一点是，开发的时候一定要开发完一个模块就立马测试一个模块。我之前是先把所有的逻辑层写完，然后再写UI层。这样有个隐患就是，逻辑层的错误和UI层错误要一起处理，而且当项目很大的时候容易让人抓狂。所以最好的办法就是写完一个模块就去实现一个模块，然后测试它，然后再下一个模块。比如“AddProduct()”写完DAL和BLL层后，立马做个简单的UI层界面，把算法调用，然后去数据库看有没有这个Product（测试）。

WCF Service以及Winform编程也就那样，感觉微软的东西会一样之后，其他的都差不多。不过要深入还是要下功夫的。

I18N，国际化和本地化，体力活。不过要在文化上进行国际化和本地化还是很有挑战的。

log4net。主要是对所有的Exception进行日志记录。

Testing

测试，对软件进行测试非常重要，是在给客户之前的一个保障。基本我们是在QA session，然后我的作品有幸被公测，其他的同事或者QA team的报bug，我就在那里debug。虽然说开发的时候很注意UIL层的验证，可是后来发现bug最多的依然是UI层。

Unit Test。基本是由工程师自己写的模块测试程序，用NUnit实现。

然后在测试阶段，软件工程师要时刻去debug QA报上来的bugs。

Release

Release Note, 告诉客户和QA怎么去配置环境。
Config Tool, 将基本的参数（服务器名字，用户名，密码，数据库备份文件地址，web.config地址）提供给客户输入，然后只需要按一个按键便可以实习所有环境的配置。用C# Winform实现。数据库方面用的是SQLDMO的COM组件实现。

其实感觉 Basic Training 目的是让我们搞清楚软件开发的流程，学习技术是无止境的。