技术改变世界 阅读塑造人生! - shaogx.com

This string was altered by TechBlog\Plugins\Example.; This is an example to show the potential of an offcanvas layout pattern in Bootstrap. Try some responsive-range viewport sizes to see it in action.

怎么样才叫软件团队开发

在我10多年的软件开发中,经历过超过200人的软件开发团队,也有过两三个人开发的小团队,但无论团队的大小,都是采用一个很简单的软件开发方法,就是把项目切分成模块,然后每个人开发一块,最后集合起来,调试完成,再经过测试,交给客户使用,就算项目完成了。在这其间,团队成员之间,没有什么交集,相互的代码也没有查看,或者了解一下。因此,当某一个成员离职或者病休时,就会带来很大的问题,因为其它人员都对他的工作不了解,因而不能接手他的工作,导致再开发下一个项目时,就会带来高涨的成本,项目大大地增加延长开发的时间。另外,由于成员相互之间没有了解代码,每个人的编写代码的风格也差异比较大,导致代码比较难重用。这种团队开发在目前看来,还在很多公司是存在的。那么怎么样才可以改变这种现状?也就是说怎么样才叫真正的软件团队开发呢?由于软件开发从个人开发变成团队开发方式,在中国来说,也近来10多年的事情。在90年代都是个人开发就可以成功了,比如像金山软件的求伯君,就可单兵一个,就可以完成DOS下面的WPS开发。放在今天这样的环境里,软件的规模已经非常大,一个人完成的软件,只有在手机领域还有市场,在其它领域已经不太可能了。因此,必须建立团队开发为目标了。为了建立团队的开发,就需要制定各种标准。比如编码规范,有了这个标准之后,就可以让所有团队成员编写出同一样规范的代码,可以减少相互交流的成本,同时也提高了代码的质量。同时也可以让成员看不出来谁写的代码,减少心理上抗拒。但是,是否制定了标准之后,就可以万事大吉了呢?其实不然,由于每个开发人员都是人,是人就有着出错,有着自己个性表现,以及个人的习惯。因而有了标准之后,就需要想着怎么样实践了,以及让标准成为行为准则。... 全文

团队 开发人员 软件 软件开发 软件质量

让普通业余软件开发兴趣爱好者也快速开发出相对专业的软件产品

一般公司里往往会有这样那样的小需求,例如一个简易的订餐的功能软件,加班申请的功能软件,客户管理的小软件,办公用品领用的小软件,工作日志填报的小软件,项目管理的小软件等等需求,虽然功能简单吧,想做好也需要五脏俱全,而且往往是需要有能实现多用户的使用。    那我们用通用权限管理系统组件模块如何能快速实现类似的功能需求呢? 若我们有兴趣,有精力去编写各种应用小应用程序时,按下面的思路去做,就很省心省事了。可以有计划有目的做出很多有意思的应用程序来了,方便自己办公,也可以分享给同事使用其乐无穷了。    1:要求快速开发,费用预算也少,使用简单便捷。    2:业余兴趣爱好着就可以开发好。    3:将来又有很强的可扩展的余地。 ... 全文

软件开发 管理系统 办公用品 应用程序 兴趣爱好

规范软件开发过程

随着软件系统的规模、复杂度日益上升,软件开发过程管理已经成为保证软件系统开发效率、质量、成本的关键性因素。作为软件开发过程中质量保障的重要组成部分,行之有效的软件配置管理(以下简称SCM,Software Configuration Management)能够显著提高软件开发组织的自身能力、提高软件开发过程的完整性,以及降低软件开发的风险。软件配置管理的概念... 全文

软件开发过程管理 软件配置 CMM 项目管理

软件开发模式对比(瀑布、迭代、螺旋、敏捷)

1、瀑布模型是由W.W.Royce在1970年最初提出的软件开发模型, 瀑布式开发是一种老旧的计算机软件开发方法。瀑布模型式是最典型的预见性的方法,严格遵循预先计划的需求分析、设计、编码、集成、测试、维护的步骤顺序进行。步骤成果作为衡量进度的方法,例如需求规格,设计文档,测试计划和代码审阅等等。 瀑布式的主要的问题是它的严格分级导致的自由度降低,项目早期即作出承诺导致对后期需求的变化难以调整,代价高昂。瀑布式方法在需求不明并且在项目进行过程中可能变化的情况下基本是不可行的。 2、迭代式开发也被称作迭代增量式开发或迭代进化式开发,是一种与传统的瀑布式开发相反的软件开发过程,它弥补了传统开发方式中的一些弱点,具有更高的成功率和生产率。什么是迭代式开发?每次只设计和实现这个产品的一部分, 逐步逐步完成的方法叫迭代开发, 每次设计和实现一个阶段叫做一个迭代. 在迭代式开发方法中,整个开发工作被组织为一系列的短小的、固定长度(如3周)的小项目,被称为一系列的迭代。每一次迭代都包括了需求分析、设计、实现与测试。采用这种方法,开发工作可以在需求被完整地确定之前启动,并在一次迭代中完成系统的一部分功能或业务逻辑的开发工作。再通过客户的反馈来细化需求,并开始新一轮的迭代。迭代式开发的优点:  1、降低风险  2、得到早期用户反馈  3、持续的测试和集成  4、使用变更  5、提高复用性螺旋开发,1988年,巴利·玻姆(Barry Boehm)正式发表了软件系统开发的“螺旋模型”,它将瀑布模型和快速原型模型结合起来,强调了其他模型所忽视的风险分析,特别适合于大型复杂的系统。“螺旋模型”刚开始规模很小,当项目被定义得更好、更稳定时,逐渐展开。   “螺旋模型”的核心就在于您不需要在刚开始的时候就把所有事情都定义的清清楚楚。您轻松上阵,定义最重要的功能,实现它,然后听取客户的意见,之后再进入到下一个阶段。如此不断轮回重复,直到得到您满意的最终产品。        (1)制定计划:确定软件目标,选定实施方案,弄清项目开发的限制条件;   (2)风险分析:分析评估所选方案,考虑如何识别和消除风险;   (3)实施工程:实施软件开发和验证;   (4)客户评估:评价开发工作,提出修正建议,制定下一步计划。 螺旋模型很大程度上是一种风险驱动的方法体系,因为在每个阶段之前及经常发生的循环之前,都必须首先进行风险评估。 敏捷软件开发又称敏捷开发,是一种从1990年代开始逐渐引起广泛关注的一些新型软件开发方法,是一种应对快速变化的需求的一种软件开发能力。它们的具体名称、理念、过程、术语都不尽相同,相对于“非敏捷”,更强调程序员团队与业务专家之间的紧密协作、面对面的沟通(认为比书面的文档更有效)、频繁交付新的软件版本、紧凑而自我组织型的团队、能够很好地适应需求变化的代码编写和团队组织方法,也更注重软件开发中人的作用。人和交互 重于过程和工具。可以工作的软件 重于求全而完备的文档。客户协作重于合同谈判。随时应对变化重于循规蹈矩。其中位于右边的内容虽然也有其价值,但是左边的内容最为重要。人员彼此信任 人少但是精干 可以面对面的沟通项目的敏捷开发:敏捷开发小组主要的工作方式可以归纳为:作为一个整体工作; 按短迭代周期工作; 每次迭代交付一些成果; 关注业务优先级; 检查与调整。最重要的因素恐怕是项目的规模。规模增长,面对面的沟通就愈加困难,因此敏捷方法更适用于较小的队伍,40、30、20、10人或者更少。大规模的敏捷软件开发尚处于积极研究的领域。四者对比区别:传统的瀑布式开发,也就是从需求到设计,从设计到编码,从编码到测试,从测试到提交大概这样的流程,要求每一个开发阶段都要做到最好。特别是前期阶段,设计的越完美,提交后的成本损失就越少。迭代式开发,不要求每一个阶段的任务做的都是最完美的,而是明明知道还有很多不足的地方,却偏偏不去完善它,而是把主要功能先搭建起来为目的,以最短的时间,最少的损失先完成一个“不完美的成果物”直至提交。然后再通过客户或用户的反馈信息,在这个“不完美的成果物”上逐步进行完善。螺旋开发,很大程度上是一种风险驱动的方法体系,因为在每个阶段之前及经常发生的循环之前,都必须首先进行风险评估。敏捷开发,相比迭代式开发两者都强调在较短的开发周期提交软件,但是,敏捷开发的周期可能更短,并且更加强调队伍中的高度协作。敏捷方法有时候被误认为是无计划性和纪律性的方法,实际上更确切的说法是敏捷方法强调适应性而非预见性。 适应性的方法集中在快速适应现实的变化。当项目的需求起了变化,团队应该迅速适应。这个团队可能很难确切描述未来将会如何变化.... 全文

软件开发 软件设计

开发软件非常需要有规划定位

折腾了好几年的程序给客户讲解大多听众都晕倒了,其实这几年一直埋头实现梦想中的完美软件架构,大多时候跟软件开发人员交流频繁,跟最终的用户或非IT客户交流得还是相对少些。最近碰到一位编程爱好者,他对软件开发特别是C#.NET开发很有兴趣,平时还看看视频教程,也看看技术方面的书籍,同时他也有比较丰富的软件实际使用经验并有多年的工作经验。   我是不管走到哪里都推广一下自己精心维护的软件组件,希望能把劳动成果分享给更多地人,结果试着给他讲解了10来分钟,他就一头雾水了,本来很耐心的讲解了软件的功能,同时也展示了软件的强大功能,结果这位朋友怎么还是会一头雾水了?甚至是听得云里雾里? ... 全文

软件开发 辅助 通用软件 闭门造车 工作经验

SaaS开发入门 阿里软件平台HelloWorld开发实例(1)

【51CTO独家特稿】51CTO推出的"SaaS时代的软件开发"系列专题受到了广大开发人员的关注。在了解了SaaS的基本概念、商业模式和开发方式等知识后,你也许想亲自动手开发一个SaaS应用,却又不知该如何开始。51CTO开发频道特别邀请了阿里软件的工程师李战老师撰写此文,从阿里软件的商业模式开始,逐步深入,手把手教您开发一个基于阿里SaaS平台的Hello World程序。阿里软件的商业模式... 全文

阿里软件 旺旺软件平台 SaaS HelloWorld ISV

远见卓识,像CEO一样编写代码!

发表于2013-10-22 17:00| 4580次阅读| 来源DZone| 12 条评论| 作者Zac GeryCEO软件开发程序员编程经验分享摘要:CEO和程序员这两个本来没有多少交集的职位,在现在看来这两者之间已经没有什么不可逾越的鸿沟了。最典型的例子就是Facebook创始人MarkZuckerberg从一个优秀的程序员变身为CEO,对于广大的程序员来说是有激励效应的。 本文作者Zac Gery是一名软件开发者、架构师。在本文,他认为一个优秀的程序员应该像CEO那样去思考,并不是说去做CEO做的事情,只是要在态度、热情、责任等方面像CEO一样,为项目开发着想,为公司利益考虑。(以下是编译内容) 基本上每一个开发者每天都要做出很多决定,不管你是新手、高手、领导还是架构师。对于所有需要完成的,都按优先顺序排好,逐一解决:先调查哪一个bug?怎样修复议题?如何采用合理的规划路径来处理棘手问题等等。尽管某些需要作出决定的事情看上去微不足道,但它们仍然具有不同程度的影响力。当有太多的竞争性需求要得到解决的时候,首要任务是做出一个相对简单、但聪明的决定。... 全文

ceo 软件开发 编程 程序员 开发者 CEO 软件开发 程序员 编程 经验分享

软件开发项目管理

 与一般的研发项目不同,软件开发常常被认为是由少数人的灵感或勤奋程度决定的,是不可控的。一般的研发项目,如果遇到超预算、项目延期等,项目经理一定会非常紧张,想尽一切办法来挽救,如果不是的话,可能就会做好卷铺盖走人的准备了。但是软件项目不同,由于大家都认为其不可控,所以如果项目落后的时间只有20%左右的话,项目组很可能就会开庆功宴,而项目经理可能就会获得升职、加薪了。 软件开发的确是与其它产品的开发不同,如汽车的开发,可以很明确地分成几个系统,如底盘、车身、发动机等,每个系统又可分为总成,如底盘可分为悬架、制动、变速器、转向等,如此这般,对整车的要求就由具体的、看得见的不同部分满足了,也就比较好跟踪其进度及质量,总而言之,产品是看得见的。而软件产品则不同,具体表现在: 一、 项目需求变化难于把握:客户的要求也即项目的需求往往是不明确的,也很难用统一的标准来衡量。二、 过程难于控制:常常是直到项目快结束时才知道可否按时完成。三、 任务难于量化、计划可行性差:软件产品较难衡量,常常是靠感觉进行。项目经理对风险缺乏充分的考虑,造成计划可行性差。四、 版本管理混乱、项目间可继承性差:各个项目组间彼此独立,重复开发多。五、 缺乏可共同执行的标准:公司没有统一的标准,各项目组各自为政,成员在不同项目时遵守不同的标准,导致无所适从。综上所述,软件开发过程常常处于无序状态,较难监控。但是,是否软件开发只能是这样状态呢?也不尽然,众所周知,印度就有不少软件企业的开发是规范的,可以管理的。也正因为此,印度成为世界上最大的软件输出国。其在软件开发上的经验是一个主要原因,CMM在印度的流行也功不可没。一般说来,印度的软件公司从几个方面来对开发项目进行管理:一、 项目生命周期;二、 项目进度管理;三、 项目规模的估计;四、 软件质量控制;五、 软件配置管理;六、 风险管理;七、 项目计划、监督及控制。接下来将就上述七个问题分别阐述,如何进行软件开发的项目管理,提高软件开发的管理水平,保质、保量地完成开发任务。软件开发的生命周期包括两方面的内容, 首先是项目应包括哪些阶段,其次是这些阶段的顺序如何。 软件行业的人都知道,一般的软件开发过程包括:需求分析(RA)、软件设计(SD)、编码(Coding)及单元测试(Unit Test)、集成及系统测试(Integration and System Test)、安装(Install)、实施(Implementation)等阶段。值得一提的是,项目开始之前应经过合同评审,这是非常重要的过程,在ISO质量体系及CMM中都对合同评审有明确的规定。这不仅仅是财务及市场部门的事,作为实际的执行者,项目经理还应从技术的角度提出意见,如公司有无相应的技术、设备、人员等来完成这个项目,也即资源是否足够?能否按时完成?验收的标准是否明确?项目的风险如何?工时(成本)是否合理?等等。因此,在正式进行项目,即需求分析之前,还应有一个项目初始化的阶段(Project Initiation),也可称为计划阶段,来确认上述情况,并制定项目计划、质量计划、配置计划等,并组织资源,确认内、外部的交流的渠道,安排必要的培训等。 另外,项目并不是将软件交给客户就结束了,应该与客户确认移交,并对项目进行分析,总结项目的经验和教训,提高以后项目管理水平,同时,还应将项目的文件归档。这可称之为项目结束阶段(Project Closure)。根据项目性质的不同,阶段的选取是不同的。比如, 有公司将编码的工作外包, 则其软件开发项目的生命周期中就不包括编码阶段。但是,不论项目的生命同期如何,项目一定应包括初始化、需求分析及结束阶段。 还有一种生命周期为维护生命周期,指在项目完成之后,运行中的维护工作。除了与一般项目一样也有初始化与结束阶段外,还包括系统学习及维护阶段。要注意的是,即使是维护项目,也应制定相应的维护计划、质量计划、配置计划,以及其它相应的准备工作,如资源调配、明确沟通渠道等。系统学习阶段也即需求分析阶段,在这个阶段了解系统。而维护阶段实际上是一个微型的软件开发生命周期,包括:对缺隙或更改申请进行分析即需求分析(RA),分析影响即软件设计(SD),实施变更即进行编程(Coding), 然后进行测试(Test)。在维护生命周期中,最重要的就是对变更的管理。本文出自 “变革管理 应对挑战” 博客,转载请与作者联系!... 全文

软件开发 休闲 职场

2013年全球最佳工作 软件开发荣登榜首

【51CTO精选译文】2013年即将到来,在新的一年中软件开发人士将继续保持良好的发展态势,通过信息技术及分析业务为企业带来竞争优势。系统分析师、网络/系统管理员、网络架构师以及数据库管理员也纷纷名列榜单前十五位。硅谷与华盛顿特区地铁体系则成为消化此类人才的最大市场。... 全文

软件开发

用UML建模开发嵌入式软件

面向对象开发方法无疑是当前最流行的软件开发方法。这归功于面向对象开发的众多优点:可靠性高,所开发的程序更健壮;由于面向对象编程的可重用性,可以在应用程序中大量采用成熟的类库,从而缩短了开发时间;继承和封装使得应用程序的修改带来的影响更加局部化,应用程序更易于维护、更新和升级。另外,UML建模语言和Rosc等CASE工具为面向对象的流行也起了很太作用,这些工具允许应用规范的面向对象分析和设计的方法与理论,远离纠缠不清的源代码,使得构建和设计变得更直观、更容易理解与修改,从而大大提高开发效率。... 全文

UML 开发 软件

软件开发自动化ANT

当一个代码项目大了以后,每次重新编译,打包,测试等都会变得非常复杂而且重复,因此c语言中有make脚本来帮助这些工作的批量完成。由于Java是平台无关的,不会采用平台相关的make脚本来完成这些批处理任务。ANT本身就是这样一个流程脚本引擎,用于自动化调用程序完成项目的编译、打包、测试等。除了基于JAVA是平台无关的外,脚本的格式是基于XML的,比make脚本来说还要好维护一些。每个ant脚本(缺省叫build.xml)中设置了一系列任务(target),而多个任务之间往往又包含了一定了依赖关系:比如把整个应用打包任务(jar)的这个依赖于编译任务(build),而编译任务又依赖于整个环境初始化任务(init)等。ANT具有以下的优点: ... 全文

ANT 软件 开发 休闲 自动化

对话微软MVP:走进嵌入式软件开发

每年的TechED不但能带给我们众多精品技术课程和与专家、MVP面对面交流的机会,同时还向我们展示未来一年的行业热点和技术发展方向。今年的TechED 2009带给我们怎样的技术指引?嵌入式开发前景看好... 全文

嵌入式软件开发

软件后期开发中的版本控制总结

 软件后期开发中的版本控制总结主题1.      在研发和测试过程中如何做好版本的衔接2.      在程序部署到现场以后,如何做好版本控制3.      版本和问题、缺陷之间的关系如何维护4.      在项目实施过程中,实施人员对版本的关注点是什么?项目经理对版本的关注点是什么?需要考虑的... 全文

软件 开发 项目管理

用户转换漏斗模型对软件开发的挑战

什么是用户转换漏斗模型一个普通的用户从软件公司的市场营销活动中得知一个软件到成为该软件的付费用户,中间有漫长的过程。在这过程中,有很多环节可能让用户失去兴趣或者失去耐性从而放弃进一步尝试,最终失去这个用户。我们可以用下图描述从得知软件的用户到软件的付费用户的过程:... 全文

软件开发 用户体验

云环境下的软件开发需进行重新思考

 编者注:此文是 Eucalyptus Systems CEO Marten Mickos 的文章。软件自出现以来模式就未曾改变:运行应用,然后应用则是在平台上面跑的。但是由于基础设施的飞跃发展,应用设计和部署的基础原则的确会不时改变—有时候这种变化还很激烈。... 全文

云环境 软件开发

送给当代软件开发者的咒语:"Write Less Code"

在2012年的时候,笔者写过这样一篇文章:Write Less Code,在当时还不错,但是在那之后,我在PageCloud工作,两年之后,再回过头来看这篇文章,现在,带着两年的思考和经验(希望如此),对这篇文章重新修改。... 全文

软件开发

理解软件开发的特点

     与软件开发过程中产品从无到有的创造所带来的兴奋与有趣相比,软件质量保证更多地让人觉得沉闷和枯燥。相比之下,软件开发过程中的需求分析、设计和编码是一个相对容易做的事,因为在这些过程中如果出现差错,工程师都觉得有劲可使以进行弥补,这些过程中的错误更多地表现为“明枪”。软件质量保证则不然,往往很容易出现有劲使不出,乃至怎么也做不好,其更多地表现为“暗箭”。之所以会出现这种状况,是因为开发团队没有深刻地理解到软件质量保证是一个系统工程,高质量软件的获得并不是意味着只要做好软件开发过程中的某一个或几个关键环节就行了,而是需要关注软件生命周期内的所有环节,且很容易出现因为一个小小的细节没有做好却造成最终的软件质量大打折扣。正是因为对于质量保证的系统性认识不够,从而造成“暗箭难防”的局面。     《软件质量是什么》探讨了软件质量的第一层含义,即用户层面来看高质量的软件具有更少的缺陷,也指出从技术层面保证软件质量的关键是提高软件设计质量。除此之外,软件质量还有其第二层含义,即尽可能在第一时间将事情做对,也就是减少返工,其表现是软件在被开发的过程中(并不是在用户手中)所出现的缺陷更少。需求捕获如果没有在需求分析阶段做好,那将造成很大的浪费,这一点众所周知,而这正是因为没有在第一时间将事情做对。另外,软件质量还应当涵盖高效地从事开发工作。同样是做对一件事,花一天与花半天时间将其做对,或许对于软件项目有着天壤之别。最后,软件质量还包含它的第四层含义,这在《软件质量是什么》也有所提及,那就是相关软件工程师的生活质量。高质量的软件应当包含软件工程师的生活质量并没有为之而“打折”,反之应当有助于提高软件工程师的生活质量。缺陷是软件用户可以看到的,而开发过程中的低返工率、开发效率和工程师的生活质量却是用户所看不到的,但对于开发团队来讲却及其重要和真切。不论是低返工率或是开发效率,其最终都反映在项目开发的经济性上。     软件质量保证是一个比较沉重的话题,因为在其后更关系到软件工程师的生活质量,而不只是表面上的产品质量那么简单。对于质量保证这一系统工程,它不能被简单地理解为“就是测试”。在进一步探讨这一话题之前,需要先了解软件开发的特点。软件开发具有以下几个特点,有些特点之间也表现为相互影响,且这些特点最终导致软件质量控制并不是那么的直观和容易。脑力密集型     软件开发是脑力密集型工作,其中的不少活动因为只存在于软件工程师的大脑中,因而具有不可见性,自然也就无法指出工程师在做开发时哪一步思考将有可能造成质量问题,进而无法通过运用流程的方法将这些潜在的质量问题完全消除,这与流水线生产下的质量保证方法完全不同。     另外,善变很可能是人的天性,由于大脑在处理事务时并不能完全保证其一致性。很有可能股票涨了的话一高兴就采用了这种处理方法,而心情不好时则采用了另一种处理方式。善变有它的好处,比如让我们更具创造性,也为我们的生活带来了更多的乐趣,使我们从无聊的事情中通过变通找到乐趣,但这对于软件质量的保证却未必是一件好事。减小善变所带来的负面影响,或许通过培养良好的工作习惯是一条不错的途径。实现不具唯一性     一个软件功能,尽管从使用者的角度来看都一样,但却可以有多种不同的实现方法,且不同的开发团队或者不同能力的人所做出来的设计很有可能完全不同。如果软件实现具有唯一性,那其质量就更好被评估,也更容易找到改善点,但软件开发不属于这一列。     正因为软件的实现不具唯一性,这使得很难从林林总总的实现中找到哪一种更好,或者要找到这个“更好”所需要的成本(包括时间、金钱和能力)却更高。隐性成本高     只要是产品开发则总是存在开发成本的概念,也需要对项目进行预算,这一点软件产品的开发也不例外。与其它产品开发不同的是,软件开发的隐性成本很高。所谓的隐性成本,是指在项目预算时并没有将其考虑在内,但它确实在将来的开发活动中会导致额外的成本开销。     一个软件项目的阶段性完成并不意味着它不会带来后续的成本,因为不同的实现(实现不具唯一性)所带来的软件稳定性和可维护性都将不同,而不良实现所带来的隐性成本往往在预算时无法合理地被考虑,这进一步又意味着什么呢?第一,它将导致对项目进行计划更困难。这是显然的,因为看不到隐性成本的存在,自然在计划时不会将其列入其中。第二则更为严重,由于隐性成本的不可见性,往往很容易造成被忽视,进而不能掌握软件开发的特点,对软件开发中的困难也表现得不理解。甚至一味地认为只要投入时间和人力就一定能开发出高质量的软件产品,孰不知很有可能因为更多的投入而造就更大的隐性成本。     隐性成本的存在往往很容易导致工程师因为工作而影响生活,而进一步带来更大的隐性成本。试想想,有没有某个项目在预算时将工程师的生活质量真正地考虑在内呢?如果有,这种考虑是考虑到了点子上吗?还是只是表面?细节很容易被放大     软件开发过程中的一个很小的细节很容易被放大。对于一个模块在设计时所留下来的小窟窿,哪怕认为微不足道,但是这个“微不足道”最后很有可能演变成项目组的沉重负担。对于大型项目,如果大家随意地包含头文件,最后很有可能造成每一次项目编译都浪费不少时间去等待;修补一个缺陷时,由于觉得没有必要去除其中的一处冗余设计却有可能最后落得难以维护;因为不小心将“==”错写成了“=”而造成一个严重的软件缺陷,等等。     在软件行业,似乎存在这种必然,只要某种事情有可能变坏那就一定会变坏(莫非定律),用“如履薄冰”来形容软件开发一点都不夸张。软件行业能很好地体现“蝴蝶效应”,也就是说一个细节最终对项目所造成的负面影响并非是按它应有的比例,而是远远大于这一比例。     可以说软件开发无小事,可能一开始认为很小的事,到最后明白其重要性时却已让团队背上了沉重的负担,进而可能压跨团队。对于“小事”的把握,需要对软件行业有较为全面和深刻的认识,以及丰富的经验和良好的洞察力。质量评估很需专业的高水平     一个表面上好的软件其设计未必就好,而设计不好则早晚会出问题,从而带来隐性成本。要真正地评估软件的质量需要通过评估其设计质量着手,而这很需专业的高水平。这里所说的专业水平不能简单地理解为评估人具有什么样的学历,或通过了什么样的认证,而是需要他对软件行业有深刻的理解和丰富的经验,以及拥有自己的软件设计思想。通常这类评估人也应当对于软件设计有着精神上的追求(否则他的水平也不会高到哪),很显然这种人是一种稀缺资源!    设计质量评估所需的专业性也正是因为实现不具唯一性这一特点所造成的,合格质量评估者的缺乏使得质量评估变得更加困难。一个开发团队,如果不具备胜任的质量评估者,则很有可能整个团队在开发过程中不知道软件质量的真实状况,而只是停留在关注被发现的缺陷之上,进而无法涉及质量问题的核心 —— 不良设计。    真正高水平软件工程师的缺乏也加剧了软件行业的困难,由于缺乏这些“领头羊”,项目组在开发过程中无法有目的地朝着高质量设计的方向前进,而只能是以完成工作为目标。结果很有可能是项目组多走弯路,以及项目面临更高的隐性成本。本文出自 “至简李云” 博客,请务必保留此出处http://yunli.blog.51cto.com/831344/321951... 全文

软件开发 质量 休闲 特点 职场

软件开发方法和Visual Studio Team System

window.location.href='http://www.microsoft.com/china/msdn/library/langtool/vsts/SDMthVSTS.mspx?mfr=true';给力(0票)动心(0票)废话(0票)专业(0票)标题党(0票)路过(0票) getcountscom(46889,11); getcountscom(46889,12); getcountscom(46889,13); getcountscom(46889,14); getcountscom(46889,15); getcountscom(46889,16); ... 全文

VSTS 软件 开发 方法

SSD软件技术开发组寻找合作伙伴

SSD软件技术开发组是由一群长年从事开源ERP、OA、CRM等系统研究的程序爱好者组成。我们致力于结合中小企业用户的实际特点,积极研究与设计开发一整套企业信息化解决方案。我们技术组现在已经推出了实用型的OA、CRM应用平台,ERP平台框架还在积极酝酿开发过程中。相信不久的将来会推出一款实用的ERP系统平台。现在真诚希望可以寻找到有实力有诚意的合作伙伴一起做相关成果的推广。如有意向的朋友可以直接通过我们的指定Email(ssdcrm@163.com)取得联系。期待我们的合作共筑辉煌!联系QQ:2263375116  ... 全文

SSD软件技术开发组 寻找合作伙伴

软件开发中的两种态度:约束和信赖

Martin Fowler

一种态度认为,应该对程序员在软件开发中的行为进行约束(DirectingAttitude)。持这种态度的人认为大部分的程序员水平都不高(谣传说... 全文

软件开发 码农

2 3 4 5 6 7 8 9 10 11