软件工程
itsoft2006
技术80,性格80,运气80
展开
-
程序开发团队---组建团队篇
我近期的文章都是一些读后感,主要观点来自于温伯格大师,我只是用自己的语言来重新唠叨一下,争取做到短小精悍,争取能让同行们用最短的时间获得最佳的学习效果。我念大学的那几年,IT行业涌现出求伯君、梁肇新、王江民、王志东等等一些非常NB的Programmers,那个年代似乎崇尚个人英雄主义,但随着时间的飞逝,软件系统的规模日益增大,再NB的程序员也不可能单独完成,程序英雄基本上不再出现,即使有转载 2006-05-01 16:16:00 · 747 阅读 · 0 评论 -
项目管理: 我来谈谈项目的收尾
2006年年初,公司面临解散,但是还有部分项目没有验收完毕,公司高层决定采取内部员工承包的方式来解决这个问题,当时,我在公司负责物流项目,刚好有两个项目没有最后终验,这两个项目本来就是我一直负责做下来的,已经完成了初验,所以我承包的时候是非常有信心完成最后的验收的,我也跟公司签定了合同,合同比较苛刻,两个项目最后的终验款合起来是7万元,如果两个项目我在规定时间内全部验收,则公司就把这两个项转载 2007-01-15 10:17:00 · 1686 阅读 · 1 评论 -
程序员的话
我在程序员的时候,我一开始追逐这个API怎么用,数据库SQL怎么写更优化,Dcom技术的细节 然后我发现我写出来的产品为了符合客户需求必须要大量修改,但是我的代码却粘在了一起 第一个感觉就是一个函数太长,一看就头痛,而且一个函数干了好多事。这些事本来可以一段一段的,每段写上注释,然后有意义命名,自己管理错误和内存,然后把这些函数连在一起 然后我作了这些: 1小函数 2写上注释 3有意义命名 4自己原创 2007-03-08 15:25:00 · 576 阅读 · 1 评论 -
从一个笑话看软件开发管理
1. 程序员写出自认为没有Bug的代码。2. 软件测试,发现了20个Bug。3. 程序员修改了10个Bug,并告诉测试组另外10个不是Bug。4. 测试组发现其中5个改动根本无法工作,同时又发现了15个新Bug。5. 重复3次步骤3和步骤4。6. 鉴于市场方面的压力,为了配合当初制定的过分乐观的发布时间表,产品终于上市了。7. 用户发现了137个新Bug。8. 已经领了项目奖金的程序员不知跑到哪里转载 2007-01-23 10:39:00 · 672 阅读 · 0 评论 -
什么是分布式? 什么是集中式? 各有哪些优缺点?
按数据的分布方式,中介软件有“分布式”和“集中式”之分的说法。简单地说,“分布式”就是每一个客户端都有数据的副本,查询等的数据操作都使用副本进行;并定期或不定期的与数据交换中心进行交换,以获得最新的数据;“集中式”是指整个整个系统中只使用一份数据(只在服务器上),所有客户端(分公司)必须联接上服务器才能进行数据查询等操作。以下是网上比较流行的说法。我在最后加上了一栏:网络先生意见转载 2007-05-31 14:26:00 · 18105 阅读 · 0 评论 -
项目开发经验谈
我就大致描述一下我的项目团队(算上美工5人)在这方面的情况:首先,介绍角色: 1.项目组长:相当于项目经理吧,主要职责我就不多说了。 2.界面工程师:是用户界面交互方面的专家,决定与用户交互的方式,当然很大程度也影响着界面 3.美工:设计和美化界面 4.高级程序员:设计总体程序结构,制定技术上的规范,并为小组解决各种难题,帮助项目组长分解每日程序员任务 5.程序员:编写代码,实现功能 6.需求转载 2007-05-31 14:32:00 · 2183 阅读 · 0 评论 -
软件与商业
软件的销售关键不是技术,而是打通掌握了决定权的领导。技术都是扯淡,权力才是最重要的。在中国卖软件,搞不懂这点,只有喝西北风。 我来公司学到的第一件事就是技术不值一文,有权才能决定投标的结果。我们公司上的一个项目完全就是权力的结果,虽然我们的技术人员都极度讨厌这个破软件、BUG很多的软件,但是还是被那个软件公司拿走了几千几百万,现在我们自己做的软件问题也没他们的多 所以,决原创 2008-05-14 09:24:00 · 1705 阅读 · 0 评论 -
常用版本控制软件简介
<br />根据查看网络上的资料,看到一般的公司使用的版本控制软件大致如下:<br />1.Clear case --------〉中坚级<br />2.CVS --------〉开源奇葩<br />3.Visual SourceSafe --------〉入门级 vss<br />4.PVCS --------〉小工作组级<br />5 Perforce --------〉<br />6.CCC --------〉元老级<br />7.StarTeam --------〉<br />8.RCS -----转载 2010-12-02 15:09:00 · 3515 阅读 · 1 评论 -
分布式的版本控制工具
<br />我最早接触的 SCM 工具是 vss ,但是没用几天(换工作到网易后)就迁移到了 cvs 。我自己大约用了一年后,公司集体从 cvs 迁移到了 svn 。领导这次大迁徙的大大说, svn 是一个更好的 cvs (确实是这样吗?据说有争议,但至少我感觉在多文件版本控制上 svn 比 cvs 方便,因为 cvs 无法保证多个文件同时提交的原子性)。<br />前几年,有人跟我争论过到底 vss 的加锁模式好,还是 cvs 的合并模式好。我觉得答案是不言而喻的,懒得争论。虽然在某些特殊环境上,我们偶尔转载 2010-12-02 15:06:00 · 2142 阅读 · 1 评论 -
软件项目管理:质量先行
软件开发为何不能像硬件开发那样可控?软件质量之旅将带给我们一些启示。 提到软件产品开发,我们的脑海里总是浮现出这样的情景:开发组的每一位成员都在辛苦地工作,加班加点,甚至通宵达旦。虽然项目经理一次又一次地修改了进度计划,而实际的开发情况却总是令人担忧,以至于每次向领导汇报工作的时候,总是觉得以前制定的计划没有很好完成,总是觉得人力资源不够,总是觉得没有太多的时间。等到代码终于开发完成了,测试进转载 2007-01-15 10:13:00 · 674 阅读 · 0 评论 -
敏捷式开发与传统软件过程
在六十年代末期提出了软件危机的概念,因此提出了非常有纪律性的方法即软件工程学,试图从电子工程学、技术工程学提炼出一些东西来用于软件工程学,他们想从中提炼出一种方法,使得软件开发的流程更有预测性。但软件业的人在做软件的过程中发现这些方法并没有减少软件开发过程中遇到的问题。近年来有人发现软件工程学里一些基本的假设是不正确的,并使用了一些新的开发方法,称为敏捷式开发。敏捷式开发采用适应性方法,而传统的软转载 2007-02-13 14:18:00 · 994 阅读 · 0 评论 -
如何写出优秀的程序?
阅读程序并不分好坏,好的源码确实让人易读易懂,甚至心旷神怡,而不好的源码让人百思不得其解,甚至心烦意乱,但作为学习者,应保持冷静的头脑,善于从别人的错误或混乱之中得到乐趣,毕竟能看得出别人的错误也可以证明自已的水平要高,阅读程序与发现错误本身也是一个学习的过程。 程序员是一个需要不断学习不断创新的职业,局外人看出来这是一个苦差事,经常思考,经常OT(加班),有人曾这样描述:如原创 2006-05-01 16:33:00 · 813 阅读 · 0 评论 -
从一段项目管理者的论断想到的敏捷开发方法
“他们的需求总是变,一天一个样,这叫我们怎么做啊。所以,你们在设计模块的时候,要尽量多考虑一些,比如,开始做的时候就应该考虑支持多个服务器,支持分布式,而不要等他们提再做,这样多耽误时间啊!他们这种做法是不合理的,我们不能这样不断的改。”这是我们一个项目负责人说的话,听到这些话,真的很悲哀,也许我懂得太多,以至于对他这些话有非常多的想法,如果不是学习了敏捷的软件开发方法,我想我就不会有原创 2007-02-13 14:13:00 · 425 阅读 · 0 评论 -
敏捷软件开发(原则,模式与实践)笔记1
教堂尖顶上的风标,即使由钢铁制成,如果不懂得顺应风势的艺术,一样会被风暴立即摧毁。——海因里希.海涅一、敏捷软件开发宣言1、个体和交互胜过过程和工具人是获得成功的最为重要的因素。合作、沟通以及交互能力要比单纯的编程能力更为重要。一个由平均水平程序员组成的团队,如果具有良好的沟通能力,将比那些虽然拥有一批高水平程序员,但是成员却不能进行交流的团队更有可能获得成功。选择合适的工具而转载 2007-02-13 14:17:00 · 561 阅读 · 0 评论 -
新方法学-敏捷开发
胡健(转载自敏捷中国) 2003年09月15日 过去几年中兴起的敏捷型(agile〕(也被称之为“轻量型”,lightweight) 的软件开发方法,以矫正官僚繁琐过程、许可对过程进行自主调整为特征, 在软件业引起了极大的兴趣。在这篇文章里,我将探索敏捷型方法的合理性, 着重点并不是放在其“轻重”上,而是于它们的适应性(adaptive〕性质 和以人优先的理念。我在本文也简要介绍了转载 2007-02-13 14:19:00 · 1045 阅读 · 0 评论 -
我需要敏捷吗:不必关心敏捷的六大理由
当“敏捷”日益成为整个软件业的热门词汇,作为优秀的开发者、成功的项目经理,我们是否有足够的理由不去关心敏捷?我们帮你列出了6个“不必关心敏捷”的理由,以及对这些理由的深入解释。如果这些理由仍然不能打消你对敏捷的兴趣,首届“敏捷中国”开发者大会即将来到你的身边。你现在就可以报名参加本次大会,与Martin Fowler和众多敏捷专家面对面交流。 理由1:项目需求? 客户即上帝!转载 2007-02-13 14:32:00 · 588 阅读 · 0 评论 -
小软件项目开发的管理
小软件项目开发的管理 选自:松耦合空间制作组 一个企业的管理,大公司有大公司的方式,小公司也有小公司的方式,如果把别人的经验生搬硬套到自己身上,可能会适得其反。同样,管理一个软件项目也一样,大项目和小项目的方式不完全一样。但从另一个角度来看,项目的大与小并没有本质的区别,很多方法是共通的。本文的目的是从作者的经验来谈谈小项目开发的管理。 一、小项目的特点 大家知道,“软件危机”的出现起源于转载 2007-02-13 14:42:00 · 497 阅读 · 0 评论 -
软件工程的七条基本原理
软件工程的七条基本原理 选自:松耦合空间制作组 1、用分阶段的生命周期计划严格管理有人经统计发现,在不成功的软件项目中有一半左右是由于计划不周造成的,可见把建立完善的计划作为第一条基本原理是吸取了前人的教训而提出来的。在软件开发与维护的漫长的生命周期中,需要完成许多性质各异的工作。这条基本原理意味着,应该把软件生命周期划分成若干个阶段,并相应地制定出切实可行的计划,然后严格按照计划对软件的转载 2007-02-13 14:41:00 · 655 阅读 · 0 评论 -
敏捷和CMM
关于敏捷和CMM,以及怎样在CMMI的框架下有效的引入敏捷的开发,是我所一直关注的话题,最近在网上闲逛,看到ThoughtWorks总经理郭晓在软博会上的演讲,觉得讲得不错,现转载如下(转载于网易科技):实际上我们软件产业要发展就要创新,在当前这种形势下,具体讲我们怎么样创新和融合,我觉得胡主任的报告做了一个非常好的报告和研究。我觉得是值得大家借鉴的。下面大家都知道,我们对于软件产业的发展转载 2007-02-13 14:14:00 · 1161 阅读 · 0 评论 -
做软件项目
有时候我也会想,为什么我们做不好软件项目?其实,我们真的要是用心在做软件项目,应该是能做得好的,但是强制要求人人都用心去做项目,比较难,很难。1. 我们做事往往喜欢稀里糊涂,不管是沟通、设计、测试、上线各个环节上都喜欢稀里糊涂差不多就可以的做法,但是这些不严谨的做法,遇到真正需要客户用的时候就出了大问题了,客户需要每个功能都是准确无误的否则无法达到他的实际工作流程了,这就会导致客户无法用,无法验收付款,软件无法满足客户的实际要求,其实这一切都从源头就开始了,例如签订合同时就开始了。转载 2010-12-27 15:03:00 · 1570 阅读 · 0 评论