总结项目上的一些问题 这个帖子主要想总结一些项目开发或实施当中出现的问题，希望大家不要再出这样的问题而影响项目的开发或实施。
这帖子也希望我来抛砖，能引出一些玉来无关的回帖希望不要出现，以后能方便大家浏览与查看，我先说一些我这几年遭受打击而明白的道理。第一大类技术问题： 不要在商业软件中使用最新的或不成熟的技术。 花哨的技术实现方式，不一定在那里都是可以使用的，比如EJB、WebService、DCOM等等，不是说这些东东不可用，是要说你要看用在什么样的项目中，用户要求是什么，这样用有没有什么好处，能不能提高开发效率，降低项目风险，适合不适合开发团队的素质，还有公司的技术基础积累等等一系列问题才能决定。
在这几年的管理工作中明白的道理就是：“做项目一定要用我们会的，容易实现的，安全稳定的，对环境要求低的，实现方式去完成我们要完成的项目功能。”
大家以后不要从一开始做就注定是失败或不易使用的产品与项目，这不是一个专业程序员或管理者要作的。
有一句我记的很清楚：“不要拿着吓人的工资，做着吓人的工作，往往结果也很吓人。”第二大类用户环境问题： 不要忽略用户环境的问题 这是一个比较笼统的概念，面也比较广，主要在这里想说的是用户的软件运行环境，就是在开发项目或产品的设计时期注意了新技术采用，也要对这方面问题要严加注意，我曾经就把系统设置从INI改变成为ADO连接的Access数据库设置，一开始以为这样效果会好，保密性，安全性会好的多，可事实说明我做的改动是愚蠢的，主要在两个方面：
1.用户在软件使用中根本就不会去改动INI设置文件，采用数据库后的安全性，反而使修改个设置还要通过启动程序来解决，因为数据表中的数据都是经过加密后存入的，由其是数据库连接，如果一开始数据库连接是错误的，光是启动到报错再进入修改就够受的了。
2. 用户操作系统的问题，大面积的用户安装把这个最重要的问题暴露无疑，有些用户的系统中ADO根本就有问题，结果不能操作数据库，从数据库中提取不出设置数据！Kao~~ 安装系统时还要拿上Offic2000给用户修正这种问题，您还不要想着不带盘，一般系统安装盘我都带着，要不白跑一趟是小，要是正赶走上出差在外地 嘿嘿~~
所以不要程序做好的就成了，或来个干净的系统测试一下就没有问题了，用户那的系统千奇百怪据不胜据呀。第三大类第三方控件问题： 不要用没有做过比较全面测试的或使用口碑不好的控件。 这种比较全面的评测工作一定要做好，不要等到用户大面积出问题时再解决，有时可能你所采用的这个控件以成为你的系统核心，大量的代码就是围绕它来写时，哇哈哈，你的问题可就大啦，系统设计的好，比如控件与务业功能是通过接口来实现的，那花的功夫就少些，如果没有分离，那和重新写就没有什么区别了，后面的工作量嘿嘿~~
这几年我也吃过这方面的亏，拿来一个控件，一看，嘿！！就是我想要的功能，结果放进去后软件用了一段时间问题就出来了，由这个控件生成的文件时不时有“自动损坏”的功能，用户叫苦不断：“我填了那么长时间，那么多数据，就这么不能用啦？！！”Kao!!叫我怎么解释？？！我的软件又没有操作这种文件的能力，都是通过这个控件来的，我怨呀我。第四大类测试与成熟度问题： 在做程序时模块化的代码或类一定要通过BT的测试，才能使用在产品中。 这个就不想多说什么，这里面有公司的原因，有人的原因，也可能会有市场的原因。反正不成熟的东东会在用户“大量实际测试”中出现种种毛病，叫你焦头烂额。
在这里要注意的是多种技术粘合品可能最易出问题，比如以前我做过的一个项目中的一个功能：数据库与FTP联合实现一种功能，就是FTP收到文件后，有一条记录才能入库，要保证文件与记录的对应，FTP因为多方面的原因是不稳定的，所以这个功能就很易出错，而这个项目中大多数功能都是FTP与数据库的结合，所以也就导致软件整体运行不稳定 -_-#第五大类代码问题： 做为专业程序员，代码一定要有文档，拿怕是只有最基本的单元说明性文字与代码中的注解，不要在代码中写不易看懂、不易调试的代码。 这个问题是我最不原意看到的，我想大家做为程序员，最不想接手的就是这样的代码或项目吧？！遇到这种问题无非有两种结果：1.它被我征服；2.我被它征服；我想大家大部分都是后者。
做为专业的程序员，代码一定要有条理，你不想你走后，这堆代码的价值就等于0了吧，我想在现在的中国，这种情况还是大量存在的。第六大类版本控制问题： 项目开发中一定要有版本控制的观念与相关管理手段。 你有版本控制的观念与相关管理手段吗？hehe^^，不一定非要用版本管理工具，而是版本的真正管理观念！对于软件产品这种问题非常关键，你的产品是不是总是做不完？是不是总是改不完？是不是有很多大体一至，但又有一些小差别，而且放的目录还非常乱?你公司的销售能不能很方便的找到打好包的最新各类版本？
大家还是多想想吧。第七大类业务问题： 市场关系与业务一定要搞好，市场与开发不能脱节。 市场与关系(在中国没办法)决定了产品或项目是否成功，在目前中国改革还不深入的情况下真实存在的，这是不可避免的，咱们咱不谈它，说说市场与开发脱节的问题，市场人员不太可能与开发人员水平接近，所以一些中、小公司就会有这样的情况，搞市场的不知道开发的在做什么，有什么进步，而搞开发的不知道市场的需求与反溃，两边的没头苍蝇:p，有些公司有项目经理呀什么的做为中间人解决这个问题，可现实是大部分公司对这部分人没有明确的分工，常常是一身兼多职，这也没办法，中、小型软件公司都差不这个样.....问一下同时要做几种工作你能做好吗？
这帖子也希望我来抛砖，能引出一些玉来无关的回帖希望不要出现，以后能方便大家浏览与查看，我先说一些我这几年遭受打击而明白的道理。第一大类技术问题： 不要在商业软件中使用最新的或不成熟的技术。 花哨的技术实现方式，不一定在那里都是可以使用的，比如EJB、WebService、DCOM等等，不是说这些东东不可用，是要说你要看用在什么样的项目中，用户要求是什么，这样用有没有什么好处，能不能提高开发效率，降低项目风险，适合不适合开发团队的素质，还有公司的技术基础积累等等一系列问题才能决定。
在这几年的管理工作中明白的道理就是：“做项目一定要用我们会的，容易实现的，安全稳定的，对环境要求低的，实现方式去完成我们要完成的项目功能。”
大家以后不要从一开始做就注定是失败或不易使用的产品与项目，这不是一个专业程序员或管理者要作的。
有一句我记的很清楚：“不要拿着吓人的工资，做着吓人的工作，往往结果也很吓人。”第二大类用户环境问题： 不要忽略用户环境的问题 这是一个比较笼统的概念，面也比较广，主要在这里想说的是用户的软件运行环境，就是在开发项目或产品的设计时期注意了新技术采用，也要对这方面问题要严加注意，我曾经就把系统设置从INI改变成为ADO连接的Access数据库设置，一开始以为这样效果会好，保密性，安全性会好的多，可事实说明我做的改动是愚蠢的，主要在两个方面：
1.用户在软件使用中根本就不会去改动INI设置文件，采用数据库后的安全性，反而使修改个设置还要通过启动程序来解决，因为数据表中的数据都是经过加密后存入的，由其是数据库连接，如果一开始数据库连接是错误的，光是启动到报错再进入修改就够受的了。
2. 用户操作系统的问题，大面积的用户安装把这个最重要的问题暴露无疑，有些用户的系统中ADO根本就有问题，结果不能操作数据库，从数据库中提取不出设置数据！Kao~~ 安装系统时还要拿上Offic2000给用户修正这种问题，您还不要想着不带盘，一般系统安装盘我都带着，要不白跑一趟是小，要是正赶走上出差在外地 嘿嘿~~
所以不要程序做好的就成了，或来个干净的系统测试一下就没有问题了，用户那的系统千奇百怪据不胜据呀。第三大类第三方控件问题： 不要用没有做过比较全面测试的或使用口碑不好的控件。 这种比较全面的评测工作一定要做好，不要等到用户大面积出问题时再解决，有时可能你所采用的这个控件以成为你的系统核心，大量的代码就是围绕它来写时，哇哈哈，你的问题可就大啦，系统设计的好，比如控件与务业功能是通过接口来实现的，那花的功夫就少些，如果没有分离，那和重新写就没有什么区别了，后面的工作量嘿嘿~~
这几年我也吃过这方面的亏，拿来一个控件，一看，嘿！！就是我想要的功能，结果放进去后软件用了一段时间问题就出来了，由这个控件生成的文件时不时有“自动损坏”的功能，用户叫苦不断：“我填了那么长时间，那么多数据，就这么不能用啦？！！”Kao!!叫我怎么解释？？！我的软件又没有操作这种文件的能力，都是通过这个控件来的，我怨呀我。第四大类测试与成熟度问题： 在做程序时模块化的代码或类一定要通过BT的测试，才能使用在产品中。 这个就不想多说什么，这里面有公司的原因，有人的原因，也可能会有市场的原因。反正不成熟的东东会在用户“大量实际测试”中出现种种毛病，叫你焦头烂额。
在这里要注意的是多种技术粘合品可能最易出问题，比如以前我做过的一个项目中的一个功能：数据库与FTP联合实现一种功能，就是FTP收到文件后，有一条记录才能入库，要保证文件与记录的对应，FTP因为多方面的原因是不稳定的，所以这个功能就很易出错，而这个项目中大多数功能都是FTP与数据库的结合，所以也就导致软件整体运行不稳定 -_-#第五大类代码问题： 做为专业程序员，代码一定要有文档，拿怕是只有最基本的单元说明性文字与代码中的注解，不要在代码中写不易看懂、不易调试的代码。 这个问题是我最不原意看到的，我想大家做为程序员，最不想接手的就是这样的代码或项目吧？！遇到这种问题无非有两种结果：1.它被我征服；2.我被它征服；我想大家大部分都是后者。
做为专业的程序员，代码一定要有条理，你不想你走后，这堆代码的价值就等于0了吧，我想在现在的中国，这种情况还是大量存在的。第六大类版本控制问题： 项目开发中一定要有版本控制的观念与相关管理手段。 你有版本控制的观念与相关管理手段吗？hehe^^，不一定非要用版本管理工具，而是版本的真正管理观念！对于软件产品这种问题非常关键，你的产品是不是总是做不完？是不是总是改不完？是不是有很多大体一至，但又有一些小差别，而且放的目录还非常乱?你公司的销售能不能很方便的找到打好包的最新各类版本？
大家还是多想想吧。第七大类业务问题： 市场关系与业务一定要搞好，市场与开发不能脱节。 市场与关系(在中国没办法)决定了产品或项目是否成功，在目前中国改革还不深入的情况下真实存在的，这是不可避免的，咱们咱不谈它，说说市场与开发脱节的问题，市场人员不太可能与开发人员水平接近，所以一些中、小公司就会有这样的情况，搞市场的不知道开发的在做什么，有什么进步，而搞开发的不知道市场的需求与反溃，两边的没头苍蝇:p，有些公司有项目经理呀什么的做为中间人解决这个问题，可现实是大部分公司对这部分人没有明确的分工，常常是一身兼多职，这也没办法，中、小型软件公司都差不这个样.....问一下同时要做几种工作你能做好吗？
解决方案 »
- 求一个线程格式的写法
- 如何删除和添加dbgrid中列
- 朋友叫我帮他写个木马程序，万一他用这个程序做了坏事，我是否会被抓？
- 继续卖身：我都快没命了，哪为好心人帮帮我，怎样查看mp3文件的代码，还有怎么实现wav压缩为mp3或是其他的文件格式都可以（希望您能施舍
- 想做个一般进销存系统，请问有关服务端软件的设计方法
- 如何在installshield中包含Jet引擎？
- Delphi中 MTS多层应用程序系统（应用服务器和客户端）为什么不能同时在本机上运行？
- 请问如何改变Application对象创建的隐藏窗口的窗口过程？
- gprs 的接受服务端程序，打开时间一长，就会在资源管理器显示未响应，cup使用率100，接受不了数据。请多多指教
- 关于键盘、mouse的问题！！help me!
- Delphi 2005有谁拿到了吗?散分!
- 请高手指点,不甚感激...
大家还是多想想吧。
－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－这些太好，就因为这个原因，专门写一个升级的程序。版本在不停的修改，还好有自动升级，不然更惨。搞的我好晕！刚开始用cvs，不是很会用。以前用sourcesafe。
======================================
終于還是显身了！老婆都騙到手了、還這麼扣門児。給誰留着呢？ hehe...
我觉得，这是与几个方面有关的：
1，上层领导不重视：多数小型的软件企业，上层都是重眼前利益，抓开发周期，导致很多软件没有编制好良好的文档就匆匆推出给用户。
2. 需求分析及用户确认的环节存在失误：其实这是与第一个方面密切相关的，为了能更快的看到东西（急功近利的人不在少数），在没有明确需求或需求分析不完全的情况下就开始了开发，当然出来的东西会不能满足需要，而这就直接导致了软件的频繁更新，文档跟不上也是很正常的事情。
3. 开发人员本身轻视文档的价值：现在很多小公司就那么几个人，需求分析、架构设计、开发等等都是一两个或少数几个人完成，而开发人员在开发之余，大多数（我觉得）都不会有心情写文档。尤其是自己开发的东西，处处都觉得使用起来很简单，使用的方法是用户理所当然就应该会的，而导致用户文档内容空泛。确实很多时候用户是不会主动去看文档的，但是对于客服人员而言，用户手头有一份文档，也可以减轻一些压力，至少可以叫用户去看了，而不只是用嘴讲。另一方面，对于产品而言，一份FAQ也可以起到非常大的作用。