随笔 - 12  文章 - 1 评论 - 176 trackbacks - 1
<2005年7月>
日一二三四五六
262728293012
3456789
10111213141516
17181920212223
24252627282930
31123456

与我联系

搜索

 

常用链接

留言簿(4)

我参与的团队

随笔档案

相册

最新评论

阅读排行榜

评论排行榜

拟在公司内实行的开发规定，敬请大家指正和补充

 软件开发流程（框架性草稿，细节还需要完善，修改中）
 
团队组成
每个团队开发设立一名项目经理，一名配置管理员，至少一名业务顾问和若干项目组员组成。
进展控制
在开发前先根据项目要求设定一个总体的完成期限，并且根据经验设置若干个项目里程碑，里程碑规定了项目进展所达到的要求，在整个开发流程中采用迭代循环的方式进行渐进式开发，每次迭代周期控制在2-3周左右，每次迭代前确定迭代目标，一般是把需求优先级最高和技术风险最大的用例首先实现，每次迭代都要以得到一个达到迭代目标并明确可运行的版本为结束标志。
需求分析
原则上不限制需求分析过程，但是建议采用UP流程进行需求分析，必须编写详细的文本方式的用例说明（UML图形为可选件）。进行需求分析时采用头脑风暴会议方式，要求项目组所有人都必须参加和讨论。所有的用例和设计都必须保存到配置管理库中。
软件开发
采用敏捷开发过程和持续集成。
测试先行，在写功能代码之前必须先写TestCase，由功能代码和测试代码都由同一个人完成。编写测试代码的时间要占整个编码时间的一半以上。
单元测试行覆盖率要达到90%以上。
每天下班以前必须签入当天的工作代码，并通过单元测试
每次签入必须说明签入结果，比如增加成了什么功能，修复了什么BUG等等。
任何时候组员都采用结对方式，两人同时使用一台电脑。
除非迫不得以，尽量不要采用IDE的DEBUG方式来进行单步跟踪，而是采用记录日志和设置断言的方式来进行DEBUG。
每次发现BUG，尽量修改单元测试以至让单元测试可以检测到该BUG的存在。
会议要求
每次会议必须记录下需要解决的问题和会议结果，并且用摄象机录制整个会议过程，并存档。

posted on 2005-07-31 22:16 linkin 阅读(2338) 评论(44)  编辑 收藏 网摘

FeedBack:
#1楼  2005-07-31 22:29 idior      
? 太简短了吧
  回复  引用  查看    
#2楼 [楼主] 2005-07-31 22:33 linkin      
能想到的比较重要的就是这些,没想到的还望补充:)
  回复  引用  查看    
#3楼  2005-07-31 22:44 kwklover      
感觉有点不太实际，除非贵公司比较大，项目经费比较多拉


  回复  引用  查看    
#4楼  2005-07-31 22:45 ChuPaChuPs [未注册用户]
除非迫不得以，尽量不要采用IDE的DEBUG方式来进行单步跟踪，而是采用记录日志和设置断言的方式来进行DEBUG。
-----------
想问下这是为什么啊,不大懂...
  回复  引用    
#5楼  2005-07-31 23:17 birdshome      
joke?
  回复  引用  查看    
#6楼 [楼主] 2005-07-31 23:24 linkin      
kwklover:
公司不大,经费也不多 :)
不过我不知道哪里需要耗用很多费用?两个人才用一台电脑,应该是节省了费用吧?

ChuPaChuPs :
因为在程序交付之后出现了问题是不可能让你单步跟踪来解决的,你判断和解决问题的方式只能依靠系统日志,而许多程序员都不习惯写日志信息,出了问题就单步调试,而这种制度则逼迫你必须输出很多足以找到并解决问题的详细的日志信息.这样才能在程序发布之后可以快速的定位并解决使用中出现的问题.

birdshome :
不是开玩笑,这个是我心目中最理想的开发过程
  回复  引用  查看    
#7楼  2005-07-31 23:52 birdshome      
一个软件公司，最大的成本是人，不是固定资产。
  回复  引用  查看    
#8楼  2005-08-01 07:28 waxwork3      
关于DEBUG方式，希望有更详细的解说。
  回复  引用  查看    
#9楼  2005-08-01 07:45 idior      
如果是真的倒是想去你公司了 :)
  回复  引用  查看    
#10楼  2005-08-01 08:23 双鱼座      
好文章，感觉总体上还不错。不过有几点我表示怀疑。
一、“编写测试代码的时间要占整个编码时间的一半以上。”这一点是基于什么？为什么必须一半以上？
二、“功能代码和测试代码都由同一个人完成。”认为不太合理。更合理的是：最好由不同的人来分别完成。这样有利于从不同的角色来看待同一个问题。
三、“任何时候组员都采用结对方式，两人同时使用一台电脑。”无法理解。程序员写代码不是一种机械劳动，需要强化独立思考。两个人结对...如果是我则无法展开思维，因为没法保证两个人的思维完全同步。
四、关于bug。先确定什么是bug、什么类型的bug，不能强行规定程序员采用什么方式除错。在满足TestCase的前提下应该可以采取任意的方式除错。虽然我也对单步跟踪也很不满，但是我不得不承认，大部分情况下单步跟踪除错(利用中间结果来判断)效率是最高的。另外bug与testcase间不一定有必然的联系，所以“必须”修改不够合理。
五、采用摄像机录制会议过程，感觉没有这个必要。但是整理好的会议文档是非常必要的。你录制了长长的会议记录，你必须先准备好对以下三个问题的回答：什么时候看？由谁看？为什么要看？

感觉比较精彩的是“头脑风暴”。不过，我觉得在程序员开始写代码前应该对WBS和项目跟踪作出规定(例如每个任务的最大时限为24小时)，避免进度失控。
对大项目的分块或者分层应该作出规定。
还有，Team内沟通比较重要，除了Team会议外，应该对沟通方式、什么时候沟通作出规定。
  回复  引用  查看    
#11楼  2005-08-01 08:41 yinh      
xp的思想是好的，我觉得结对编程其实也真的是很精彩的一种思想，我也想使用之。
但正如你所说，这是你理想中的开发规定，所以，可能注定不能完全实施成功，除非你的开发组人员素质真的就特别高。其中肯定是有些不能实施的，现在在国内似乎实施结对编程的很少吧，倒是其它的还可以。
  回复  引用  查看    
#12楼  2005-08-01 08:58 James      
你完全可以参照RUP、CMM/CMMI,XP来制定适合你自己的开发流程。
而且有了规定，还需要检查机制(review)，否则如何知道是否按规定执行？

感觉你提出的这些只是一些原则性的东西，基本没有可操作性。
制定任何规定是必须要有可操作性的。
  回复  引用  查看    
#13楼  2005-08-01 09:04 jhyc [未注册用户]
任何时候组员都采用结对方式，两人同时使用一台电脑。

这点比较费解？？为什么要这样呢？经费紧张？？
  回复  引用    
#14楼  2005-08-01 09:07 DotNetFresh      
双鱼座:
一、这是根据Martin Fowler所说的时间做的规定，也就是说，测试代码至少要和功能代码量相当，这条的目的并没有办法严格控制，但是这条规定其实是为了强调组员一定要认真对待单元测试，具体的量化指标在下一条：覆盖率必须达到90%以上。
二、单元测试是白盒测试，必须要由了解程序细节的人来编写才有意义，不过由不同的人来编写测试和功能代码我倒没有实验过，不过一般介绍单元测试的书中，都强调单元测试必须要由程序员本人来编写。你在这方面有实际的经验吗？希望共享：）
三、结对编程很多人无法理解，但是我在实际项目中实践过，效果是好的，开发效率不一定比两个人两台电脑要差，并且还起到互相监督的作用，比如上班偷偷聊QQ，看网页等情况。
四、谢谢你的建议，我已将“必须”修改为尽量。另外关于单步DEBUG的问题，我觉得这是一个习惯问题，很多国外的开发团队一般都不使用单步跟踪，而且太依赖单步DEBUG，会对发布的项目造成调试非常困难的问题。
五、摄像机录制会议的问题，主要是一个补充资料，因为文本方式的会议记录可能会遗漏一些当初人们看起来并不关键的问题，并且记录也只能记录一个大概，而摄象机则能记录下几乎任何细节问题，人的信息交流有时候仅仅是靠一个表情，一个动作，甚至一个眼神。这里的前提是采用摄象机来录制会议并不会增加太多成本，特别是在现在DV很普及的情况下。
  回复  引用  查看    
#15楼 [楼主] 2005-08-01 09:15 linkin      
James ：
我提出来的都是我个人认为可具有操作性的，不知由具体的那些规定不具备可操作性，还望兄台明示，谢谢。
  回复  引用  查看    
#16楼  2005-08-01 09:29 zhumk      
不过一般介绍单元测试的书中，都强调单元测试必须要由程序员本人来编写。

我没有实践过，不过我看的书上好像都是说结对编程时单元测试都是由另外一个人编写的，莫非我看错了
  回复  引用  查看    
#17楼 [楼主] 2005-08-01 09:36 linkin      
设计类的一种机制
因为是通过接口进行开发，所以不太可能利用类的内部功能。但因为我是目标类的开发者，我有到其内部工作的“窗口”，所以测试并不是个真正的黑箱。仅凭这一点就足够推断出需要开发者本人在编写目标类的同时负责测试的开发，而不是由其他任何人代劳。

[原文]http://www-128.ibm.com/developerworks/cn/java/j-ant/index.html
  回复  引用  查看    
#18楼  2005-08-01 09:56 hehe [未注册用户]
我觉得可行不高
我们公司是做企业软件开发的，楼主说的单元测试代码占整个代码的50%，个人觉得有点太死，这要看在做什么样的产品，如果是在做框架，或者工具，这可能需要这么多，但一般的业务软件，写这么多的test case根本没必要，一是时间不容许，到项目紧的时候，估计你自己都没力气去写那个了。楼主把问题想得太理想了，真正在实际项目中，你上面说的很多方法都是行不通的，除非你是老板）
  回复  引用    
#19楼 [楼主] 2005-08-01 10:17 linkin      
关于编写单元测试花费这么多时间到底值不值得的问题,其实也是目前国内大部分软件企业的误区,事实已经证明,不写单元测试在开发后期的调试BUG所耗费的时间远远大于编写单元测试的时间,并且没有单元测试的代码几乎也没办法进行重构和修改,维护也有很多问题.
  回复  引用  查看    
#20楼  2005-08-01 11:01 idior      
@linkin
不管怎么样个人还是觉得太理想化， 希望你在半年后在写同一篇文章，如果你还保持现在的观点， 请告诉我贵公司的名字。 :)
  回复  引用  查看    
#21楼  2005-08-01 11:03 肯.索夫特      
正所谓理论过多，实际过少，除非你们公司是在印度，否则本计划注定失败。
失败点1：
团队组成
每个团队开发设立一名项目经理，一名配置管理员，至少一名业务顾问和若干项目组员组成。
如果公司的项目多，必然会出现非标准配置的团队。就会首先破坏本规定。导致本规定不严肃。失败。
失败点2：
需求分析
原则上不限制需求分析过程，但是建议采用UP流程进行需求分析，必须编写详细的文本方式的用例说明（UML图形为可选件）。进行需求分析时采用头脑风暴会议方式，要求项目组所有人都必须参加和讨论。所有的用例和设计都必须保存到配置管理库中。
需求分析是需求分析师的专项工作，没有必要全项目组成员进行讨论，说实话，让他们进行讨论也是浪费时间。头脑风暴会议方式的基本要求是什么，相关方面的专家，在大家对业务流程不了解，也不可能都了解的情况下，这是不可能实现的。
 
失败点3：
不可否认，你对开发阶段了解得最多，也写得比较详细，也安照了ISO的要求对细项进行了量化，如：单元测试行覆盖率要达到90%以上
但是你有什么措施以保障这些规定可以得以执行，难道你想一个人对所有项目进行检查，那我可以保证你除了上WC的时间，其它的时间都得做这个工作了。

失败点4：
你所推崇的双人结队编程方式，在现实中是不可能实现的。难题一、如何结队。让一个高程带一个低程？？？还是让二个水平差不多的Coder一起工作？？？
对于你说的
结对编程很多人无法理解，但是我在实际项目中实践过，效果是好的，开发效率不一定比两个人两台电脑要差，并且还起到互相监督的作用，比如上班偷偷聊QQ，看网页等情况。
要注意的是，你所管理的是人，不是机器，如果有人上班偷偷聊QQ，和看网页的，请检查自己的工作是否做得不够，一个技术总监是有责任保证员工的工作饱满度，不要将什么过错都推给下属，否则的话，我想你已进入员工的Bad Leader的列表了。
 
由此可以看出，你可能刚刚接触到管理工作，或刚刚从一个Coder升级成为技术总监或类似的什么工作。但是做为一个技术总监，并不是把什么所谓的开发方法堆积就可以达到效果的。
重要的是，如何从公司的现状出发，制定一个适合的工作制度，不但要考虑到BOSS的管理需要也要考虑到员工的接受和认知程度，制度的制定，不是一个人拍一下脑袋就可以做出来的，也不是从网上COPY下来改改就可以的，放弃那些想法，多和下属员工以及上级BOSS进行沟通，以期达成一个大家都信赖的制度，好的制度不是一朝一夕就可以制定出来的，而是经过长期的实践形成的。记住这一句话：流于形式，无法执行的制度，不管他多么先进，多么的有效率，那也过是一个可笑的，留于纸面的一纸空文。


  回复  引用  查看    
#22楼  2005-08-01 11:08 idior      
肯.索夫特 说的很有道理啊， 肯定是过来人了
  回复  引用  查看    
#23楼  2005-08-01 11:17 说实话，不针对人 [未注册用户]
肃我直言，阁下实际工作经验严重不足，是个理想主义者。看到这篇文章，就让我想起政府的某某计划什么乱七八糟的东西，毫无操作性可言，体现在：1. 粗，只有标题，如何执行？如团队组成，配了这些人，请问职责是什么？ 再如覆盖率，请问使条件，还是方法，还是语句，还是综合？ 2.理想化，结对编程，覆盖率90%，你以为就你看过敏捷开发吗？ 3. 教条化，如上。还有，一个迭代2-3周，真不知道2周能做什么？

  回复  引用    
#24楼  2005-08-01 11:23 双鱼座      
我发现大家的评论的确非常精彩!每个人讲得都有一定道理。有些东西的确不能照搬国外的，甚至连国内在java下开发的过程控制都只能借鉴而不能照搬。
希望楼主认真总结改进，然后给大家分享！:)
  回复  引用  查看    
#25楼  2005-08-01 11:47 DotNetFresh      
@ 肯.索夫特
说得很深入,详细..收益不少..在这里,提一些和你不同的观点和疑问.

正所谓理论过多，实际过少，除非你们公司是在印度，否则本计划注定失败。
-----------
不知道这指的什么意思?印度的公司就是理论多,实际少的?:)(题外话,呵)


如果公司的项目多，必然会出现非标准配置的团队。就会首先破坏本规定。导致本规定不严肃。失败。
------------
项目多,出现非标准配置的团对理所当然,不过我觉得这并不和一个规定相悖,正所谓具体情况具体分析,但并不是说存在这样的规定是没有意义的.就象我们国家的"一国两制",难道你能说收回香港,澳门,那我们的社会主义发展纲领就没有意义了?(呵,是不是说大了点...:))


你提出"失败点2"我同意,不过我不知道我们所指的需求分析是不是和linkin指的是同一码事,需求分析也要分阶段,其实我觉得在需求的后期,让开发人员参与进来也是有好处的.


如：单元测试行覆盖率要达到90%以上
但是你有什么措施以保障这些规定可以得以执行，难道你想一个人对所有项目进行检查，那我可以保证你除了上WC的时间，其它的时间都得做这个工作了
-------------
关于这一点,我觉得还能存在实现的可能的,现在覆盖率测试的工具那么多,开源,商业的都有,在daily build里面做起来应该还是没有问题的.特别是如果可以结合着daily build的工具来做,应该不会消耗太多人力成本的.(当然这个地方你应该是拿覆盖率待指开发过程中的种种过程).


要注意的是，你所管理的是人，不是机器，如果有人上班偷偷聊QQ，和看网页的，请检查自己的工作是否做得不够，一个技术总监是有责任保证员工的工作饱满度，不要将什么过错都推给下属
-------------
这一点我想我只能同意你40%.任何规章制度都要靠一些措施来保证,就如同国家的法律法规一样.诚然,员工上班聊QQ,看和工作无关的网页,管理人员肯定存在其责任.但我想,主要问题应该还是应该在员工身上.一个人犯了罪,你能说社会没有给他足够的教育,爱心,关怀,社会应该承担主要责任吗?(呵呵,又是题外话...)那说到我们现实中来...为什么那么多的公司要封外网端口..啥啥啥的.我觉得这只是一种措施而已(尽管,他可能不是很好的方法).
至于结队遍程,一直感觉很好,不知道大家是否有这样的体验,有时候一个问题两个人讨论起来,代码写起来那感觉都不一样,而且写出来的东西也有信心,但是,这东西实践起来倒底怎么样,我也持怀疑态度...不知道有没有兄弟尝试过用这种方法正式开发??

上述观点,如有不妥,还望各位前辈指教!
  回复  引用  查看    
#26楼 [楼主] 2005-08-01 12:03 linkin      
谢谢大家，无论意见如何，我至少听到了来自各个层次的声音。
我承认，以上确实只是我想的一些理想化管理规定，实际上，公司目前正在走一个大家都很常见的流程，但是这个流程虽然说可以操作，但是弊端非常多，因此才有意做一次过程方面的改革，当然做一个改革总要往好的方向去改，即使是有些冒险和试验性质。
其实这个规定中的许多规定我在以前的项目总也个别的试验过，比如结对编程，单元测试，Daily Build等，并不是完全都是凭空想象的（这里我也想请教一下提出这些规定不具备可操作性的同志们，你们是否亲自实施过然后的出的这个结论？还是也只是想当然？）
当然，最后再次谢谢大家提供的宝贵意见，不过我希望谁能拿出一份更加合理和更加具备可操作性的规范出来给大家交流探讨一下。用好的流程来改进大家的开发不是更好？
  回复  引用  查看    
#27楼  2005-08-01 12:31 cmic [未注册用户]
每天下班以前必须签入当天的工作代码，并通过单元测试
--------------------------------------------
我觉得签入的是可运行的代码，而不是所有代码

  回复  引用    
#28楼  2005-08-01 12:33 QuitGame      
你开了这个公司偶绝对不会去。
  回复  引用  查看    
#29楼  2005-08-01 13:14 andyloo      
嘿嘿，首先要员工和你一条心才行，还是多下功夫怎么去调动调动积极性吧。看了你这个东东，我也同意你开了这个公司偶绝对不会去。员工不是机器，没有他们的配合，你啥也搞不起来的。是人就会有人的缺点，就有自己的立场，聊QQ看网页，人之常情。只要不耽误进度，何必呢？大家都是从下面走上来的，要多下面人着想，否则你再搞什么先进的方法也没用。
  回复  引用  查看    
#30楼 [楼主] 2005-08-01 14:13 linkin      
请问不来的原因就是因为公司不许聊QQ和不许看闲杂网页吗？
  回复  引用  查看    
#31楼  2005-08-01 14:28 ttyp      
不去的原因是不够人性化，其实早想说点什么了，不要只想到公司制度，应该先想到员工，大部分公司认为公司发展好了，员工自然有发展。我认为相反，应该是员工发展好了，才能有公司的发展。正如一个国家的富有强大，要看它的人民富有和强大。要执行你这个制度，必然要有相应的关于员工福利制度，工作环境和气氛，还有要有个好领导。
  回复  引用  查看    
#32楼 [楼主] 2005-08-01 14:32 linkin      
这个只是开发制度，不用把员工的福利制度都写进去吧？
而且这个制度如何不够人性化？是不许聊QQ吗？还是不许看闲杂网页？
愿闻其详

  回复  引用  查看    
#33楼  2005-08-01 14:37 yzx110 [未注册用户]
改变方法是好的，但是要注意改变的幅度
你应该一步一步地去改变，
如果你说你们公司现在是按照现在国内大部分软件公司的那套流程走的
那么你一次改变那么大， 我不怎么看好
  回复  引用    
#34楼 [楼主] 2005-08-01 14:41 linkin      
yzx110：
谢谢你的意见，我这个只是理想化方案，具体做法是根据情况尽量实行，在实施过程中应该会有一个折中过渡的过程，但是最终目标就是希望能达到现在描述的这个样子。
  回复  引用  查看    
#35楼  2005-08-01 15:04 idior      
我很期待一两个月你的下一篇关于这个的体会. 可一定要总结出来哦.
  回复  引用  查看    
#36楼  2005-08-01 15:43 肯.索夫特      
我再多说二句吧。之所以说不是印度所以无法成功，原因是指在印度，90%以上的CODER是高中毕业，因此，可以适用于此粗暴的管理方法。
但在中国，正好相反，90%以上的CODER是大学生，做技术的大部份都自视过高，如何粗暴的管理方法，只会造成人才流失，流动的营盘，流动的兵。形成不了一个稳定的团队。
很抱歉我用了粗暴二字来形容你的管理规定。
再一次强调：
公司的现状出发，制定一个适合的工作制度，不但要考虑到BOSS的管理需要也要考虑到员工的接受和认知程度，制度的制定，不是一个人拍一下脑袋就可以做出来的，也不是从网上COPY下来改改就可以的，放弃那些想法，多和下属员工以及上级BOSS进行沟通，以期达成一个大家都信赖的制度


下面说说你这个规定的硬伤：
1、无弹性。
就像我之前所说的，规定必须有弹性。
由于制定规定时，无法预计出所有的情况，所以必须有一定的弹性，以保证不会过于频繁的改动规定，造成规定的不严肃。
在这里我帮你改改第一个规定：
每个团队开发设立以下职位：
项目经理、配置管理员、业务顾问、项目组员。
其中项目经理是必须的，配置管理员和业务顾问可按情况单独配置或与其它项目共用。
2、过细
在这种大杠架纲领性的文件中，不要使用以下语句：
在整个开发流程中采用迭代循环的方式进行渐进式开发，每次迭代周期控制在2-3周左右
改成这样应该会好一些。
在开发流程中采用迭代开发方式，每个项目的迭代周期应由项目经理确认，并将其明文写入开发文档中。
3、无执行性
规定制定出来就是要执行的，我们来看看这几句：
在写功能代码之前必须先写TestCase
这句话，说实话，有经验的人士，绝对不会这么写。因为你没有检查的手段，程序员很聪明的，他大可以先写代码，然后补TESTCASE。
改成这样：
开发时，先编写对应的TESTCASE后经项目经理审核，并编列入开发文档后，方可进行功能代码编写
这样可行性就高得多。

先简单说一下吧，主要是硬伤过多，一个个指出来，我都有点不好意思。


  回复  引用  查看    
#37楼  2005-08-01 16:01 Snox [未注册用户]
知识觉得这样是不是比较的压抑。
  回复  引用    
#38楼 [楼主] 2005-08-01 16:06 linkin      
肯.索夫特:
非常感谢你提出的宝贵修改意见!!!并热切希望能继续指出硬伤,我不怕丢脸,有错就改,所以希望你也不要不好意思,呵呵,再次感谢
  回复  引用  查看    
#39楼  2005-08-01 17:03 Ninputer      
单元测试不等于测试。只有单元测试是不可能发现所有Bug的，或者应该说，大多数Bug都不能发现。但是单元测试有助于减少Bug，不过这是另外一个概念了。
测试代码与编码量相等应该不是指的单元测试的代码，而是测试人员的代码。反复强调，开发人员不应当做自己的测试人员，或者说作不了自己的测试人员。必须要有专门的测试人员。
  回复  引用  查看    
#40楼  2005-08-01 20:37 cure      
现实会让人很痛苦的:)
  回复  引用  查看    
#41楼  2005-08-01 20:53 Oscar.NET      
理想和现实是有差距的，大公司需要这样的理想主义者，来带动一些人的热情，但是如果规模不大，建议你首先不要放弃理想主义，然后仔细考虑肯的话，如果有空，翻翻看《死亡之旅》这本书。
每个公司都有适合自己的开发流程，任何人给你的只是他们的看法，和经验，至于什么样的方法适合你们公司，这需要你们自己不断摸索和思考，才能总结出来，不要照搬别人的方法，包括所谓的国内外牛人告诉你的方法。
  回复  引用  查看    
#42楼  2005-08-01 22:07 Zeus      
”而是采用记录日志和设置断言的方式“
是不是说
而是采用记录日志和设置断点的方式？
  回复  引用  查看    
#43楼  2005-08-02 08:56 双鱼座      
Zeus不知道断言(Assertion)，不过在.net开发者里好象很普遍。
  回复  引用  查看    
#44楼  2005-08-02 15:10 myrat      
肯 兄说得很有道理，一看就是过来人，还希望多指点，我们旁观者也可以多学习。
不管怎么样，理想主义者还是应该有的。
  回复  引用  查看    




标题  
姓名  
主页
Email (博主才能看到) 
验证码 *  看不清,换一张 [登录][注册]
内容(请不要发表任何与政治相关的内容)  
网站首页

新闻频道

社区

小组

博问

网摘

人才

找找看
  登录  使用高级评论  新用户注册  返回页首  恢复上次提交      
该文被作者在 2005-08-01 13:00 编辑过
Google站内搜索

China-pub 计算机图书网上专卖店！6.5万品种 2-8折！
近千种 9-95 新二手计算图书火热销售中！
开发者征途系统新作：《设计模式——基于C#的工程化实现及扩展》

相关文章:

相关链接:

最新IT新闻:
雅虎新任CEO两大人选基本锁定
成龙谈创办汽车网站：不让我的受骗经历重演
微软高管解密Windows7内幕：大量功能中国造
Vista SP2 beta 具体更新的清单
纽约时报：Twitter为何拒绝Facebook收购
 

Copyright ©2008 linkin Powered by: 博客园 模板提供：沪江博客