当前位置:首页 » 服务器技术
开发技术指南» 文章正文
    引言: 1. 你们的项目组使用源代码管理工具了么? NT-SIZE: 1
 

 

 ·php5 中, 对象引用的注意问题    »显示摘要«
    摘要:php5 中, 对象引用的注意问题 /******************************/author:大龄青年 e_mail:wenadmin@sina.com/*****************************/ 笔者比较笨,哪错了,哪里说错了您就忍忍吧! -_-! 在php4年代, 对象的引用是通过一个简单的 "&" 符号来实现的.在php5中($obj1 = $obj2;)默认就是引用的方式, 不......
    摘要: .net matters...xml注释、迟绑定 com 及其它原著:stephen toub翻译:abbey 下载源代码:netmatters0406.exe(173kb)原文出处:.net matters:xml comments, late-bound com, and more(msdn magazine june 2004)  注:此文在 msdn 杂志上有更新。本文也一并给出。参见:编辑更新。有关更新的详细信息请参照原文。 我......


一個成功的項目必勝的條件
1. 你们的项目组使用源代码管理工具了么?

应该用。vss、cvs、pvcs、clearcase、ccc/harvest、firefly都可以。我的选择是vss。 【相关文章:(代码级)Java性能的优化

【扩展阅读:从创建一个应用程序到制作一个安装包的详细

【扩展信息:UDDI FAQs

2. 你们的项目组使用缺陷管理系统了么?

应该用。clearquest太复杂,我的推荐是bugzilla。

3. 你们的测试组还在用word写测试用例么?

不要用word写测试用例(test case)。应该用一个专门的系统,可以是test manager,也可以是自己开发一个asp.net的小网站。主要目的是track与browse。

4. 你们的项目组有没有建立一个门户网站?

要有一个门户网站,用来放contact info、baselined schedule、news等等。推荐sharepoint portal server 2003来实现,15分钟就搞定。买不起sps 2003可以用wss (windows sharepoint service)。

5. 你们的项目组用了你能买到最好的工具么?

应该用尽量好的工具来工作。比如,应该用vs.net而不是notepad来写c#。用notepad写程序多半只是一种炫耀。但也要考虑到经费,所以说是“你能买到最好的”。

6. 你们的程序员工作在安静的环境里么?

需要安静环境。这点极端重要,而且要保证每个人的空间大于一定面积。

7. 你们的员工每个人都有一部电话么?

需要每人一部电话。而且电话最好是带留言功能的。当然,上这么一套带留言电话系统开销不小。不过至少每人一部电话要有,千万别搞得经常有人站起来喊:“某某某电话”。«人件»里面就强烈谴责这种做法。

8. 你们每个人都知道出了问题应该找谁么?

应该知道。任何一个feature至少都应该有一个owner,当然,owner可以继续dispatch给其他人。

9. 你遇到过有人说“我以为…”么?

要消灭“我以为”。never assume anything。

10. 你们的项目组中所有的人都坐在一起么?

需要。我反对virtual team,也反对dev在美国、test在中国这种开发方式。能坐在一起就最好坐在一起,好处多得不得了。

11. 你们的进度表是否反映最新开发进展情况?

应该反映。但是,应该用baseline的方法来管理进度表:维护一份稳定的schedule,再维护一份最新更改。baseline的方法也应该用于其它的spec。baseline是变更管理里面的一个重要手段。

12. 你们的工作量是先由每个人自己估算的么?

应该让每个人自己估算。要从下而上估算工作量,而不是从上往下分派。除非有其他原因,比如政治任务工期固定等。

13. 你们的开发人员从项目一开始就加班么?

不要这样。不要一开始就搞疲劳战。从项目一开始就加班,只能说明项目进度不合理。当然,一些对日软件外包必须天天加班,那属于剥削的范畴。

14. 你们的项目计划中buffer time是加在每个小任务后面的么?

不要。buffer time加在每个小任务后面,很容易轻易的就被消耗掉。
...   下一页
 ·oa架构设计之启示    »显示摘要«
    摘要:最近帮公司开发oa系统,由于是项目经理,所以参与了系统的架构设计。偶有感想,便付于纸面。 有何不妥之处还望各位指点。 第一:需求分析一定要仔细,越明确用户的需要越可能较好的把握架构的设计,因为需求确定软件架构。 第二:要从用户角度考虑各种与软件和软件架构有关的因素,这些因素是: 1)架构的简单性,这和设计机器设备时要保证结构简单(从而可以使用户简单维护,用户不懂机器设计!!)的原理是一致的。但是这也带来了简单复杂性,为何?打个比方:现代的pc体积......
» 本期热门文章:

©2000-2007 All Rights Reserved. 最佳浏览:1024X768 MSIE