前言

　　离开实习的那家公司已经有一个月了，但这篇文章却迟迟没有写完，或者是找工作让人折腾，或者还是自己太懒了，趁这两天有一阵缓冲期，抓紧时间把这段经历做个总结吧。在正式开始之前，首先介绍一下我实习的这间小公司的一些概况吧，这家公司做的是ERP产品，使用的技术是Winform/C#。在这实习的两个月时间里，Winform给我的感觉是适合做桌面快速开发，但我还是不太喜欢这门技术，觉得Winform的前后台开发比较耦合，对界面的展现相当乏力，据闻微软推出的WPF会是WINFORM的一个替代品，可见在未来WINFORM的使用率会逐渐下降。boss是一个新西兰海归，本身也有10年开发经验了，现在回国创业。期间在与boss交流的过程中，发现一个有趣的事情：在新西兰那边软件开发行业微软的技术很流行，原因是微软与那边的大学合作紧密，采取了一系列激励学生从事微软技术开发的措施：开设专门学习微软技术的课程，计算机学生可以免费获得Windows正版认证，如果在学校的微软课程中学习成绩优异，还可以获得额外的奖品，boss说他曾经在微软的技术课程中考到了第一名，然后就被邀请到新西兰微软总部领取了一台XBOX游戏机，可见，微软在那边的推广力度还是很大的。为什么微软愿意花这么大资金投入呢？相信没有人愿意做亏本生意。boss提到在新西兰那边，版权是受到法律严格保护的，如果员工发现公司没有使用正版软件，是可以直接告公司的，所以那边的公司基本都会用正版软件，微软的投入不是没有回报的。同时新西兰的IT行业起步不是很早，所以在微软的高推广力度下收效非常可观。

　　闲说了这么多东西，接下来开始进入正题吧，首先要介绍的是工具篇。

工具篇

 “功欲善其事，必先利其器。” 作为一个开发者，除了具备优良的编程理念和敏锐的思路，同时应该能熟练地使用一些工具，内外兼修，工具的使用能大幅度地提升开发效率，带来的效益是很可观的。在实习的这家公司里，开发用的是Visusl Stdio 2010 和 SQLServer 2008。对于数据库而言，我没接触过其他DBM，所以不好对比，但是一提起VS，仿佛我眼中就冒出火光了，对，这是我接触过最强大，最具生产力的开发环境，没有之一。对于这两个常用的开发环境，这里就不在多说了，接下来将介绍一下其他的工具。

     1. ERStudio

　　在未使用ERStudio前，我一直是直接在SQL-Server的Query窗口中写CREATE TABLE语句，说实在话，我很喜欢这样的开发方式，毕竟一切都在代码的可控制范围内。但手动写CREATE TABLE对于TABLE少的情况下还好，一旦TABLE的数量比较多的时候就比较难办，因为很难看出表与表之间的联系，容易遗漏东西。ERStudio具有强大的数据库建模功能，可以自动生成CREATE TABLE语句，同时还可以查看已建好的数据库的结构，印象比较深的一次是使用ERStudio把数据库中的大概30张表拉到可视化建模界面显示，表与表之间的联系能够清晰地展现出来，对于了解整个模块的数据库设计提供了非常好的图形界面。

      2. Team Foundation Server

　　 TFS作为一个团队开发服务软件，只需部署到服务器上，然后让每个开发端的VS的团队资源管理器连接到服务器，这样就能进行团队开发任务了。确切来说，TFS大概可以分为两个部分，一个是源代码管理，另一个是开发任务管理。对于源代码管理，在日常开发中经常用到的操作有获取最新版，签入代码，签出代码，解决冲突等。当然TFS还提供了很多强大的功能，这里就不一一列举出来了。

　　

　　对于每个开发者而言，使用源代码管理器，不仅可以专注于自己所负责的模块的开发情况，也可以及时地获取最新版本，同时源代码管理器还保留了历史开发版本，具有很高的安全性，对于团队项目来说这真是必不可少的一个工具。

      TFS对于软件开发管理方面同样提供了很好的支持，使用开发任务管理，你可以建立自己的任务列表，设置每个任务的优先级，预计完成时间，开发标记（未开始，开始，已完成，阻塞），以及注释等等。在之前做个人项目开发的时候，自己是没有做提前规划的习惯，基本上是突然想到什么就做什么，开发任务很凌乱，所以效率确实不怎么样。而开发任务管理可以帮助你整理任务，跟踪你的开发情况，记录每天的工作情况，久而久之你也许会惊喜发现自己的开发效率会在潜移默化中逐渐提高，至少对于我自己使用过后的感受是这样子的。以致后来自己在做个人开发的时候，也喜欢使用开发任务管理软件，不过我不是使用TFS，毕竟这是针对团队开发而言的，对于个人使用有点过于庞大而且部署复杂，所以我自己使用的是一款叫做 TODOLIST 的免费软件，我非常喜爱这个东西，因为它确实很好用，所以在这里推荐给大伙。

     

     微软的TFS功能很强大，同时也是一个收费软件，如果想使用免费的SVN，可以参见Mercurial，著名问答平台StackOverFlow就是使用这个版本管理软件。

     3. SQL Server Profie

　　SQL Server Profile 是一个监控SQL Server运行的组件，需要安装SQL Server企业版才会有这个组件。使用这个组件的一个很重要原因是为了监控SQL和存储过程的执行情况，因为实习的这家公司使用自己开发的框架，封装了很多数据库底层操作，所以有时出BUG了，需要查看某个存储过程或SQL到底执行了没有，这时候SQL Server Profie 就派上用场了。

　　4. SQL Promt

　　使用了SQL Promt后，我发现我越来越离不开它了。不知道SQL Server 2012对于T-SQL智能提示的支持做得怎样，至少在我本机的SQL Server 08 Express R2的智能提示确实不怎么样。SQL Promt是可以运行在SQL Server上的一个收费插件，提供了强大的智能提示功能。实习的这家公司很多业务逻辑需要写成存储过程，对于两三百行的存储过程如果智能提示很差的话，对于编写者而言将是一个灾难，因为我自己一开始没有用这个插件，对比两个开发模式，所以我深有体会，使用Promt可以大大提高开发效率。

技术篇

　　1. 12层的开发框架

　　传统的开发框架基本分为最基础的三层：界面UI层，业务逻辑层，数据访问层。12层的开发框架是建立在传统三层之上的，首先最底层是基础层，分别定义了项目的界面，业务逻辑，数据访问的基础组件，供上层使用。层与层之间的调用也是有严格限制的，即上层只能访问下层的东西。也许你会觉得12层好像很多余，使用传统三层不也可以吗？其实这就要牵涉到ERP的问题了，虽然ERP已经有一系列的标准操作，但不同的行业，细分到不同的公司，却希望能有个性化定制，切实符合公司实际应用场景，如果使用传统三层，那么有关个性化的部分会与公司的ERP通用产品紧密地耦合在一起，这是不利于后期维护和功能扩展的。12层的开发框架就是为了解决这个问题的，基础层之上是标准层，标准层之上是行业层，行业层之上是公司层，这样客户个性化定制的功能就主要集中在上层了，这就避免了耦合，从而也能最大程度地重用代码。

　　2. 面向集合的SQL

　　相信很多开发者跟我一样，因为对于面向过程的熟悉，很容易把面向过程的思想也带到SQL中来。比如说现在为一张表生成测试数据，面向过程的思想会这样做：这还不简单嘛，写个WHILE循环，设定一个循环变量，一次插入一行数据，然后就翘起双手坐等结果出来。这样子的方案确实能解决问题，但又有没有考虑过效率问题呢？如果按照一次一行的处理方式的话，SQL Server会为每一行Insert生成一个事务处理，一旦处理的数据量很大，速度是非常慢的。不如让我们把视角从面向过程转到面向集合，来看看面向集合又可以怎样实现吧。

CREATE TABLE customer(    cust_id       INT                    NOT NULL,     cust_name  NVARCHAR(20) NOT NULL,     cust_no       VARCHAR(10)   NOT NULL,     CONSTRAINT pk_cust_id PRIMARY KEY (cust_id)     );/*当对测试数据的随机性不做要求的时候可以这样做*//*已知有一张表history有1000行记录*/INSERT INTO customerSELECT 'teroy',             'no1'   FROM history h1 CROSS JOIN             history h2--这样就插入了1000×1000行数据了

　　当然这个例子还不足以说明面向集合思想的应用场景，要讲明白面向集合的思想还需要很大的篇幅介绍，这里也就点到为止了，毕竟我自己也处于接收面向集合思想的初级阶段，就不敢继续班门弄斧了，想要了解更多可以点击：。

　　3. 使用脚本模板和界面模板

      很多时候，在进入功能开发的前期，我们都要做一系列基础的工作，比如新建一个Form后，引入必要的命名空间，添加必要的界面控件等等。这些工作确实耗费时间，那么这时候就应该考虑使用模板了。我接触过两种模板，一种是T-SQL模板，另外一种是界面模板。创建T-SQL模板应该来说比较简单，只要一点小技巧就可以了，那就是在SQL Server的Query窗口写完模板后，存为文件后就把文件设置为只读。而界面模板的话，就需要使用到VS提供的导出模板功能，具体这里就不进行介绍了，随便一搜就可以查到相关的资料了，不然的话记得《VS 2010高级编程》这本书也有详细地提到过，可以参考下这本书。　　

/*-----------存储过程模板------------Anthor:------Date:-------------------------------*/SET ANSI_NULLS ONGOSET QUOTED_IDENTIFIER ONGOIF OBJECT_ID(N'','P') IS NOT NULLDROP PROC proc_GO-----编写你的存储过程位置-------CREATE PROC proc_ASBEGINEND

　　4. 调试程序

      很多时候程序运行出BUG了, 通过抛出的异常信息无法定位到BUG，这时就需要使用调试功能了。VS提供了强大的调试功能，基本组合为F5+F10+F11+设置断点，在敏感位置插入一个断点，按下F5，程序运行到断点处就会跳回IDE界面，这时已运行代码变量的值都可以在程序中查看了，按下F10为执行下一条语句，如果程序有调用另外的函数，按下F11则可以进入所调用的函数中。调试程序也是开发人员必须掌握的基本技能之一。

　　5. SQL编写规范以及脚本的命名

　   有关良好的编程规范所带来的好处这里就不在老生常谈了，“优秀的代码是写给人看的”这句经典的话已经涵盖了方方面面。其实，良好的编写规范的养成并不困难，除了学习编程规范的技巧之外，还要在开发中践行这些编程规范，保持对写优秀代码的追求，这就可以了。这里简单介绍一下有关T-SQL编程的几个小技巧：

• 关键字大写，对于SQL的保留字如FROM，WHERE，AND等等，都使用大写；
• 使用缩写，比如内联一张表可以用INNER JOIN, 也可以直接使用JOIN，这时就应该选择JOIN，尽量减少代码；
• 留空换行的选择，来看一个对比：
  //单行写完的SQLSELECT * FROM table WHERE table_id = 1//留空换行的写法SELECT *  FROM table WHERE table_id = 1//稍微复杂的SQLSELECT a.*,       b.table_num  FROM table1 a  JOIN table2 b ON a.table_id = b.table_id WHERE a.table_id = 1

  对于越复杂的T-SQL，留空换行的写法可读性会大大提高。这个技巧的一个重点是对齐，这里就不再过多描述了。

　　  对于团队开发而言，每个人都需要写T-SQL脚本，并放到一个模块的文件夹中，这样在部署的时候需要运行一个小工具，就可以运行整个文件夹中的T-SQL脚本了。然而这样却有一个问题：我们知道T-SQL脚本的创建是要求有先后顺序的，总不能在CREATE TABLE语句之前先往TABLE加入初始数据吧，所以为了让脚本有序，需要在脚本命名的开头写上一个序号，同时要注意到一点是最好以5或10的递增顺序写序号，比如00010_CreateTableStudent_Teroy.sql, 00020_InsertIntoTableStudent_Teroy.sql 等等。这样命名是为了应付有时中间遗漏了什么脚本没写，就生成一个中间序号比较00005_CreatePrimayKeyOnStudent_Teroy.sql放到文件夹中，如果以1为增量，就不能这样实现了。

非技术篇

　　1. Visio & OneNote

　　 需求人员将ERP界面需要制作的东西画在Visio上, 同时将对应的业务逻辑写在OneNote上, 做为开发者, 就以这两个东西为基准进行开发工作，所以实习期间除了打开VS和SQLServer外，这两个东西也是必备品。Visio提供了专业的可视化处理，确实很好用，特别提一下OneNote，OneNote是一个可分享的笔记本，能更好地提供协作沟通功能，一个比较赞的功能是，它可以在每一个功能描述点之前添加一个打勾的选项，所以当你完成了某个功能点的时候，就顺便在之前的勾打上，这就可以记录你的完成情况，尽量避免了功能遗漏。

　　2. 沟通交流的艺术

　　作为开发人员，跟需求人员沟通交流是家常便饭的事情，ERP开发更是如此。我接触的开发模块是财务模块，这是一个专业性很强的东西，因为你必须充分了解会计上的东西，不然开发工作将会一头雾水，所以很多时候都需要和需求人员探讨会计上的种种业务员需求。

　　沟通交流也是一门学问，在我一刚开始进行沟通的时候，经常是等到需求人员噼里啪啦讲完一大堆后，但我还是似懂非懂，提出疑问后，然后又需要别人再重复地讲多一遍，这就是低效的沟通交流。那么如何提高沟通的效率呢？问题如果发生在自己身上就要寻求方法解决。首先，在于别人做沟通交流的时候，请保证自己一定要全神贯注，仔细地听，认真地思考，这是高效率沟通的第一道保障；及时提问，当遇到自己不理解的地方，请立刻提出问题，不要等到别人噼里啪啦讲了一大堆后再一起提问，因为你记不住这么多问题，而且东西经常是一环扣一环的，一个地方出现了断点，那么后续关联的地方肯定也是无法理解的，如果这时再让对方继续讲，岂不是一堆空气话？提问表达尽量简洁而且易于理解，当遇到不懂的问题的时候，打断对方，这时你不需要立马抛出问题，因为没经过认真组织的语言容易让人费解，你可以稍微经过思考，组织好你的语言，争取精简而有力地阐明问题；在你最终弄懂了这些问题的时候，在对方继续讲述之前，可以适当地做一些标记，以防之后的遗忘。