1：关于自定义控件的研发和使用
随着开发项目的增多，一个公司或者一个研发小组都会积累一些常用的控件，如何管理和重用这些控件也是一个非常值得大家讨论和研究的一个问题。在此，我提出我的一些建议。
首先在公司内部，控件必须和源代码一起发布。如果使用的控件功能比较单一，源码也
不是很复杂，建议不要直接引用DLL，而是把这个控件的项目添加到解决方案中。这里有一个原则就是“控件是为了项目服务，但项目不能受制于控件。”。如果项目中直接使用
了控件的源码，那么如果你觉得这个控件用起来不是很爽，那么直接修改它。
我在这里要着重说明一下，我指的控件是在项目开发过程中，为了封装一些业务逻辑而设计的一些可以重用的组件。这些组件的应用范围非常狭窄。只适合使用在同一个公司，或同一类项目中。同时也经常需要变动。这些控件往往也没有任何文档，而且也许最初的设计者也早已经离开了公司。对于这些只适用于公司内部的组件，我建议加载源码使用。
（举个例子）
为了在配置文件中保存的是加密过的数据库连接字符串，我写了一个加密控件。其他同事在使用了这个控件一段时间后，认为我的加密算法过于简单，于是我把源码发给他，让他在原来的基础上自由修改。在我的下一个项目中，我就使用了经我同事修改过的加密控件。同时因为我加载了源码，我又在原来的加密算法上添加了一些方法，使得这个控件同时也可用在用户登录的验证上。 在这种情况下，加载源码的方法是多么的灵活和方便啊
如果控件本身逻辑和代码都比较复杂，除非你相信在出现问题时你能找到帮助，或者你能了解其中80％以上代码的含义和使用的算法，否则建议不要使用这种控件。因为使用这种控件往往会成为日后系统维护的泥沼。
2：关于中型项目的人员配备问题
这里我只讨论中型项目。因为截至到目前为止，我没有正真亲历过大项项目，因此没有针对大项项目的发言权。呵呵。任何一个项目，必须保证整个系统体现的是概念完整的设计理念。概念完整性的受益者将包括最终用户，系统开发者，培训人员。为了保证这种完整性，做出需求确定的必须是少数，甚至一个人。我建议在中型项目中采用一个项目经理加一个结构师进行需求分析，框架设计。项目经理和结构师必须有非常良好的沟通，包括分析问题的风格，对开发的理解等。PM和结构师是最早参与项目的两个人，他们之间的不一致会直接影响项目的开发方向。
这样做有以下几个好处
(1) 因为PM和结构师都了解项目的整体构架，设计理念，即使中途有一个人退出，也不会对项目造成致命的打击。
(2) PM着重对项目的进度，人员安排，成本控制进行管理，而结构师着重对设计理念，系统的可扩展性，和软件质量进行管理。两种管理方式互相制约互相融合，折中出来的设计方案将是最优的。
3：开发文档的建立
一个项目的开发接近尾声了。公司质管部也开始对各类文档开始进行审核。这时候我们往往会突击赶制文档，文档的编制此时也成为令人厌烦的繁重任务。这样产生的文档往往也是质量非常低劣的。作为一个项目的管理者，如何改变这种状况呢？一个聪明的做法就是在项目启动初期，即刻正式生成若干文档，即使有些文档可能非常的简单，甚至只有标题。
ok。现在文档的框架有了，接下来就是填空了。随着项目的不断推进，文档的内容也日渐丰富。最重要的是这些文档都是日积月累出来的，这就叫做“化整为零”，“蚂蚁搬家”。噢，后面的那个词好像用的不太恰当。
我建议最小的项目文档集合包括如下几个：
(1) 需求文档。没有那个客户会一股脑把他们的需求倒给你。所以这个文档需要不断的补充和完善。
(2) 项目计划。俗话说计划终赶不上变化。因此我们必须不停地修正这个计划。
(3) 框架设计。这个世界上不存在一挫而就的成功的框架设计。修修补补永远是我们软件设计的主题。
(4) 设计元素说明。程序员就位准备动工了，如果你连一张像样的施工图纸说明也不给，那么这么多程序员就准备百花齐放，最终的产品将是典型的四不象。
4:要学会舍弃
Brooks 在《人月神话》中明确提出了迭代开发的概念。我本人基本上也一直在使用这种方式在开发软件。这里套用《人月神话》书中的一段话“（作者）常常会被屏幕上的第一幅图案，第一个可运行的系统对团队士气产生的鼓舞效果而感到震惊”。的确，当你开发出完成一个原型后，虽然里面功能很弱，甚至几乎就是一个空的构架，但是往往会激励我们继续去完善他，修改他。
回到标题。一个只是为了试验功能而做的原型，如果当初设计的时候，没有很好地考虑他的可扩充性，可维护性，那么一定要学会舍弃，彻底抛弃这个原型，另起炉灶，重新开发一个新的原型。有了这个被抛弃的原型的经验，相信下一个原型将更完善。同时因为是另起的炉灶，没有原来混杂代码的困扰，开发效率反而更高。
举个例子，我刚进公司的时候，接到的任务是做一个UDP的通讯程序。因为原来从来没有使用dotnet 技术开发过Socket通讯，于是我首先尝试着做了一个可以互相通讯的程序。算是原型吧。但是没有加入任何实际的业务功能。只是能够通讯。当我准备在这个通讯程序中加入业务逻辑时，我发现我碰到难题了，因为当初设计的时候，只是考虑功能，整个程序的构架很凌乱。虽然当时项目的工期非常紧张，但我还是重新建了一个解决方案，并且把原型中我认为是可靠的代码拷贝到新的程序中，重新构造了一个通讯程序，但是我在这个程序中，预留了添加业务功能的接口，使得整个程序的结构非常清晰，可扩展性也非常强。
如果当初我坚持在原来的原型基础上扩展功能，那么也许日后维护这个程序将是一个非常糟糕的工作。
