http://www.kuqin.com/software-engineer/ 挖经验 / 软件工程 zh-cn Copyright &copy; 2007-2008 <A href="http://www.kuqin.com">酷勤网</A> All Rights Reserved <A href="http://www.miibeian.gov.cn/" target="_blank">京ICP备07011765号</A> kuqin.com@163.com http://www.kuqin.com/software-engineer/20080904/16501.html Martin Fowler开始简单解释了精益概念的历史，他说，有关精益概念的历史根源可以追溯到20世纪50年代发展起来的精益制造和丰田生产系统。这个系统和它蕴含的思想，为日本制造业，尤其是丰田公司，赢得了广泛的信誉。 2008-09-04 软件工程 Chris Sims译者 李忠利 InfoQ http://www.kuqin.com/software-engineer/20080902/16157.html 一个程序的致命错误要到其发布至少半年后才会被发现；不可检测的错误是无穷无尽的，并以各种形式存在；相反，可检测的错误从理论上讲是有限的；随着时间的推移，修正某个错误所需花费的精力会成指数级增加；你越快开始编写代码，就会需要越长的时间…… 2008-09-02 软件工程 DevTopics 译言 http://www.kuqin.com/software-engineer/20080831/15969.html Johanna Rothman补充说，如果你发现了阻力，你应当想一下这是否也体现出来了你自己身上的阻力。所以，当我们遭遇阻力时，应当把脚步稍稍收回，考虑找人一起玩一下Dale的游戏，这可以帮助我们分析出问题的本质和应对方案，对当前情况作出改善。 2008-08-31 软件工程 Mark Levison译者 秦时月 InfoQ http://www.kuqin.com/software-engineer/20080831/15944.html 把种种需求明列并分级是唯一的办法;自已就按步就班一点点地完成，这是唯一的办法。事实上，对于商业客户这也是适用的，因为收钱的毕竟是公司老板而不是项目组的程序员，公司老板收了钱就不管实际项目成本是多少而让程序员无条件接受客户的需求也是常见的事情。 2008-08-31 软件工程 秩名 天极网 http://www.kuqin.com/software-engineer/20080831/15941.html ISO 9000是一系列关于质量管理的国际标准。该系列可以分为三部分，其中ISO 9001是最大的一块。ISO 9000, 质量管理体系 — 基础和词汇标准；ISO 9001, 质量管理体系 — 要求；ISO 9004, 质量管理体系 — 业绩改进指南. 2008-08-31 软件工程 Alan Zeichick 译言 http://www.kuqin.com/software-engineer/20080831/15921.html 由于CMMI的实施改变了软件企业固有工作流程及习惯，所以推进及推广会产生比较大的阻力，如何更加有效的把软件企业固有和工作与规范化管理有机的结合在一起很重要，尤其，CMMI也需要进行“信息化”，工具的支持很重要。 2008-08-31 软件工程 周玲 天极网 http://www.kuqin.com/software-engineer/20080830/15824.html 大多数的程序代码，基本上都依循一致的命名惯例。不过运气更差的时候，一套系统中可能会充斥着多套命名惯例。这有可能是因为开发团队由多组人马所构成，每组人马都有不同的文化，而在项目开发管理又没有管控得宜所造成。 2008-08-30 软件工程 iThome 王建兴 天极网 http://www.kuqin.com/software-engineer/20080830/15675.html 在设计敏捷过程的时候，一定要明白个体的价值不是通过上级的命令，而是通过主动参与实现的。设计过程的构建方案是一种可以提高效率的做法，而让参与者成为这个设计的一部分则是取得成功的根本。 2008-08-30 软件工程 IT168 袁发明 IT168 http://www.kuqin.com/software-engineer/20080830/15674.html 建立敏捷架构并不只是为了更好地预测结果，许多措施不但可以简化正在进行中的工作，并且同样有长期效益。只有那些完备的代码才有清晰的表达能力；并且只有那些技术负债较少的代码才会使架构成为轻松愉快的工作环境。 2008-08-30 软件工程 IT168 袁发明 IT168 http://www.kuqin.com/software-engineer/20080829/15510.html 从另一个角度思考技术债务：努力“增加资产”。从会计学的“借贷”角度来说：一个人可以将精力集中于减少借款或者增加存款，但最终理想的目标还是增加资产。某些情况下这只是视角的问题。 2008-08-29 软件工程 Mike Bria译者 张龙 InfoQ http://www.kuqin.com/software-engineer/20080826/15148.html “Scrum是其中最简单易懂，并且易于采用的。”IBM敏捷开发实践的负责人Scott Ambler谈到：“Scrum实施的重点是团队领导和需求管理，它既不像XP必须有深入地技术实践，也不像统一过程必须覆盖整个生命周期的每一个细节。” 2008-08-26 软件工程 秩名 天极网 http://www.kuqin.com/software-engineer/20080824/14943.html 敏捷软件开发越来越重视“程序员的职业水准”，这并不是什么全新的观念了。极限编程提出一系列技术实践，就是为了达到这个目的。Scrum强调“技术卓越性”，还有很多其他的例子。问题在于：为什么有那么多团队都做不到这一点？是不是太过隐晦了？ 2008-08-24 软件工程 Mike Bria译者 郑柯 InfoQ http://www.kuqin.com/software-engineer/20080824/14942.html 在敏捷中，可以调整一个sprint接受的故事点数，以使sprint中的所有任务都能在sprint之内抵达“完成”状态。这就是“尾灯效应”。 软件开发之难，很大程度上因为其过程类似于复杂的自适应系统。敏捷，如果可以正确实施，将会提供稳定的反馈。 2008-08-24 软件工程 Amr Elssamadisy译者 郑柯 InfoQ http://www.kuqin.com/software-engineer/20080821/14626.html 大家都已经习惯于事先明确定义最佳流程，要想抛弃这种观念，也许有点让人胆战心惊，可是现实告诉我们：要想为一组特定的人制订软件开发的流程，不去事先得到流程的明确定义，而是将精力放在流程的演进上；这也是与人类大脑和软件本身最一致的方式。 2008-08-21 软件工程 Kurt Christensen译者 郑柯 InfoQ http://www.kuqin.com/software-engineer/20080819/14443.html 通常，在公司中都有编码规范，然而这些编码规范执行的好与坏却很少有人关心，编码规范有两个大的方面作用：一是可以使代码容易理解，当然这也是最主要的作用；另外就是通过有效的编码规范可以提高程序的稳定性。 2008-08-19 软件工程 鹿寒 CSDN博客 http://www.kuqin.com/software-engineer/20080819/14442.html 隐喻（metaphore）是所有XP实践中最难理解的一个。极限编程者在本质上都是务实主义者，隐喻这个缺乏具体定义的概念使我们觉得很不舒服。的确，一些XP的支持者经常讨论把隐喻从XP的实践中去除。然而，在某种意义上，隐喻却是XP所有实践中最重要的实践之一。 2008-08-19 软件工程 鹿寒 CSDN博客 http://www.kuqin.com/software-engineer/20080819/14441.html 现场客户这个原则有两个主要内容：第一，鼓励和客户一起开发，无论是将客户邀请到公司内部还是开发人员到客户现场。第二，就是在和客户沟通需求时采用场景的方式将用户的需求一个个描述出来，而描述的语言是程序员和客户都能理解的 2008-08-19 软件工程 鹿寒 CSDN博客 http://www.kuqin.com/software-engineer/20080819/14440.html 敏捷开发中提出了每周只工作40小时的原则，这一原则的提出自然引起了大家的关注，吸引大家进一步的去了解敏捷开发的理论体系。可以肯定地说，敏捷开发的创始人并不是说每周工作40小时之后就呼呼大睡了，关键的话在这里：“充分利用你的时间”。 2008-08-19 软件工程 鹿寒 CSDN博客 http://www.kuqin.com/software-engineer/20080819/14439.html 在敏捷开发、极限编程的其他几个原则中都已经为实现代码共享作了各种准备工作，例如，简单设计、重构增强了代码的可阅读性，配对编程通过工作方式上的压力实现了深层次的知识共享，编码标准使得代码的编写规范是一致的。 2008-08-19 软件工程 鹿寒 CSDN博客 http://www.kuqin.com/software-engineer/20080819/14438.html Laurie Williams将配对编程描述为“一种编程风格，它由两个程序员并排在一台计算机上工作，连续协作完成同一个设计、算法、代码或者测试”。配对编程的含义不仅仅是编程本身的键入，我个人认为“配对开发”应该是对这种活动的更好描述。 2008-08-19 软件工程 鹿寒 CSDN博客 http://www.kuqin.com/software-engineer/20080819/14437.html 关于重构，是一个相对复杂的话题，通常按照对一个问题的考虑思路是这样这样论述的：重构是什么？为什么要重构？怎么重构？有本书名字叫《重构——改善既有代码的设计》，专门论述重构，推荐大家去看。 2008-08-19 软件工程 鹿寒 CSDN博客 http://www.kuqin.com/software-engineer/20080819/14436.html 当我开始接触到敏捷开发、极限编程理论之后，深深地感觉到这些理论其实并不是什么新奇的东西，只是我们的很多实践没有形成理论和体系。同样，敏捷开发、极限编程也不应该是和传统的软件工程格格不入、相互矛盾的。 2008-08-19 软件工程 鹿寒 CSDN博客 http://www.kuqin.com/software-engineer/20080819/14435.html 测试原则在我理解中应该是敏捷开发中最重要的原则。因为对于敏捷开发，它是欢迎变化的，也就意味着频繁的修改。如果这种频繁的修改没有测试做保证的话，那么最终的结果只能是一堆错误百出、隐患重重的垃圾。 2008-08-19 软件工程 鹿寒 CSDN博客 http://www.kuqin.com/software-engineer/20080819/14434.html 演进的设计更符合极限编程的核心准则。然而简单并非意味着简易，所谓“大道至简”，自简入繁并不难，化繁为简才真正需要大智慧。我们必须理解的一点就是，所谓的“简单系统”同时还应该保证它的有效性。 2008-08-19 软件工程 Kent Beck CSDN博客 http://www.kuqin.com/software-engineer/20080819/14433.html 小版本发布是一个可交流的好办法，客户可以针对性提出反馈。但小版本把模块缩得很小，会影响软件的整体思路连贯，所以小版本也需要总体合理的规划。 2008-08-19 软件工程 鹿寒 CSDN博客 http://www.kuqin.com/software-engineer/20080819/14432.html 目前的项目大多数是“背靠一堵墙”进行时间计划的，这一点在目前竞争激烈，以占领市场为前提，以生存为目标的大环境下是很难改变的。那么我们作为“底层”人员是不是就放弃了呢？其实，我倒是觉得越是在这种情况下，越能体现敏捷开发、极限编程的优势。 2008-08-19 软件工程 鹿寒 CSDN博客 http://www.kuqin.com/software-engineer/20080819/14431.html 解读极限编程的12大原则 1：计划的制定；2：小版本；3：简单设计；4：测试；5：持续整合；6：重构；7：配对编程；8：代码共享；9：每周只工作40小时；10：现场客户；11：隐喻；12：编码标准 2008-08-19 软件工程 鹿寒 CSDN博客 http://www.kuqin.com/software-engineer/20080819/14428.html 无论同意文章的结论与否，它对精益——特别是看板——的描述方式，有助于Scrum团队评估是否可以采用这些实践。文章还描述了一种实践的方式，Scrum团队可以用这种方式来采纳看板实践，以进一步发挥现有流程的作用。 2008-08-19 软件工程 Chris Sims译者 郑柯 InfoQ http://www.kuqin.com/software-engineer/20080818/14344.html “CMMI环境下，该如何实施Agile？”这个问题并没有一个规范的答案。其实可以说：“只要本着‘积极思考，消除浪费’，没有必要把敏捷挂在嘴边，不要对立，而去实践，在实践中不断调整”就是在CMMI环境下实施Agile的要点。 2008-08-18 软件工程 乔梁 InfoQ http://www.kuqin.com/software-engineer/20080818/14311.html 著名的敏捷专家J.B. Rainsberger在Yahoo的XP讨论组中发起了一个有趣的讨论，质疑在敏捷软件项目中做估算的必要性。Industrial Logic的创始人Josh Kerievsky在Agile 2008大会中作了题为“被认为是浪费的估算”的演讲，并涉及很多细节。 2008-08-18 软件工程 Mike Bria译者 郑柯 InfoQ http://www.kuqin.com/software-engineer/20080811/13938.html 比过去交付更多的业务价值，这就是我们定义的成功。有些人认为，这其中暗含着要求，要为大家创建一个愿意工作在其中的环境。也许最重要的，是要在向敏捷转换的过程中，设定业务人员需要的目标。绝大多数人同意敏捷实践仅仅是达到目标的手段。 2008-08-11 软件工程 Mark Levison译者 郑柯 InfoQ http://www.kuqin.com/software-engineer/20080806/13463.html 2.不是调出来的那是怎么出来的呢？ “写出来的。” 呵呵，别扭，但是想想看，是否有点道理？3.从另一个层面，我们需要加强代码的规范的写法，这就好比设计，先尽量将设计做的到位一点…… 2008-08-06 软件工程 Alex BlogJava http://www.kuqin.com/software-engineer/20080804/13304.html 一如很多人所料，这回事不是黑白分明。我们该如何做好？我们现时在做的到底有用么？只有一个正确方法呢，还是有两个不同的 正确方法呢？或者视乎实际情况而定？会不会是有些情况下用用例较好，而有些情况下用用户故事较好呢？还是其实没太大分别呢 2008-08-04 软件工程 Amr Elssamadisy译者 麦天志 InfoQ http://www.kuqin.com/software-engineer/20080803/13163.html 照37 Signals的做法，约束是朋友。“约束是打造伟大产品的关键，”弗瑞德说，“约束产生创意。如果有人说，给你全世界的财富，让你做任何想做的东西，那这东西多半永远发布不了。给我一个月就好！” 2008-08-03 软件工程 Scott Rosenberg，译者：韩磊 InfoQ http://www.kuqin.com/software-engineer/20080802/13111.html 软件其实很简单的，无非是分析好用例，然后让计算机一步步实现而已，用例，是所有软件实现的前提：不然，软件到底要干什么？好的软件项目都有一个共同的特点，就是简单的逻辑，明确用例。 2008-08-02 软件工程 秩名 天极网 http://www.kuqin.com/software-engineer/20080801/13012.html 现在，单元测试却是大家所期望的，有时甚至是必须的。越来越多的人甚至用Michael Feather'的定义来识别“遗留代码”，这个定义就是：没有单元测试的代码。也许，有人会发明一种测试技术，可以防止由于最基本的抽象层面发生问题而导致的无数故障。 2008-08-01 软件工程 Michael Nygard译者 乔梁 InfoQ http://www.kuqin.com/software-engineer/20080728/12583.html A: 是结对编程是 XP 实践中最具争议的一个. 反对它的开发者不在少数, 但更大的阻力来自老板的本能反对。老板们对它的质疑更多的是效率上. 其实就像TDD增加了整体代码量但不是工作量一样, 结对编程并非像直觉的那样降低了效率 2008-07-28 软件工程 切尔斯基 CSDN博客 http://www.kuqin.com/software-engineer/20080727/12538.html 任何集成策略在执行过程中都会遇到困难, 如迟迟得不到能够成功集成的版本. 这时你要找出原因, 并有权力或相应措施要求整个几百人的团队停下来, 做为第一优先级的任务去修复. 并让整个团队清楚进度停滞造成的损失. 这么做的意图是强调集成的重要性 2008-07-27 软件工程 李光磊 CSDN博客 http://www.kuqin.com/software-engineer/20080727/12518.html 什么才是“优秀代码”最重要的特点？显然，就像软件工程里所面临的问题一样，是代码的平衡性。编写代码时，我们总是会努力保证复杂与简练之间的平衡：选择折衷的方式来编写代码，通过不断地测试来达成我们所期望的目标。 2008-07-27 软件工程 Eran Kampf CSDN博客 http://www.kuqin.com/software-engineer/20080726/12395.html 减轻书写模板代码之痛苦的途径之一，是Visual Studio的代码片断功能。它自带了不少VB的片段和少量C#片段。虽然编写代码片段容易了一些，但与团队成员分享代码片断仍然是一件麻烦的事情。 2008-07-26 软件工程 Jonathan Allen译者 郭晓刚 InfoQ http://www.kuqin.com/software-engineer/20080724/12178.html BPDM元模型看似复杂。然而，正是这一复杂性为具体元素提供了精确的定义。这些抽象概念不会表现为附加的BPMN图形，也不会作为附加的XML概念来表达。总的说来，BPDM元模型的复杂性使得这一规范更加精准和健壮，并为未来开发一致的、互补的业务建模功能提供了支持。 2008-07-24 软件工程 Boris Lublinsky译者 黄璜 InfoQ http://www.kuqin.com/software-engineer/20080723/12135.html 13条小贴士可以帮助你写出更规范、更容易维护的代码注释：1、逐层注释；2、使用段落型注释；3、对齐连续的行注释；4、不要侮辱读者的智商；5、注意礼貌；6、讲重点；7、坚持统一风格；8、使用内部统一规定的标签；9、边写代码边注释；10、就当是为自己写注释…… 2008-07-23 软件工程 José M. Aguilar 译言 http://www.kuqin.com/software-engineer/20080722/12051.html 编写可读性强的代码，事实上也不会花费更多的时间，至少在开发的最后阶段是这样的。可读性强的代码能让你更容易看懂自己写了些什么，这也是为什么要如此做的重要原因。而且，我们在查看代码时往往会顺便检查代码，这样也有利于纠正错误。 2008-07-22 软件工程 Eran Kampf 天极网 http://www.kuqin.com/software-engineer/20080721/11893.html Q: 我们也做单元测试, 但是是先写产品代码后写测试的. 难道非得 TDD, 非得测试先行吗?A: 没什么事是非做不可的. 取决于你要什么. TDD 只是以可验证的方式迫使你将质量内建在思维中, 长期的测试先行将历练你思维的质量. 而事后的单元测试只是惶恐的跟随者. 2008-07-21 软件工程 李光磊 CSDN博客 http://www.kuqin.com/software-engineer/20080721/11892.html 怎么样才能保证自己的代码没有 BUG 来？程序员必须克服一些自身的致命缺点才能够从根本上解决这个问题。程序员必须对自己的代码带着挑剔和学习的态度;这个基础是假设自己的代码是错误的，然后需要做的是怎么样证明自己的代码是正确的。 2008-07-21 软件工程 秩名 天极网 http://www.kuqin.com/software-engineer/20080721/11880.html 信息技术市场流行的方法论有RUP(Rational Unified Process), The Zachman Framework, XP(极限编程)等。在这些方法论中，最流行的要数RUP。RUP有三大特点：1)软件开发是一个叠代过程，2)软件开发是由Use Case驱动的，3)软件开发是以构架设计为中心的。 2008-07-21 软件工程 秩名 天极网 http://www.kuqin.com/software-engineer/20080709/10764.html 软件开发组织从一开始就在向制造业借鉴和学习，并形成了各种不同的开发方法。敏捷开发与准时化生产中的很多观点和实践是一致的，精益思想作为精益生产背后的指导思想也正在积极地影响着软件开发领域，向其中不断注入创新与活力。 2008-07-09 软件工程 路宁 InfoQ http://www.kuqin.com/software-engineer/20080709/10762.html 单元测试并不能在“单元”这个层次上通过抓到错误来改进质量。而且，集成测试也不能在“集成”这个层次上通过抓到错误来提高质量。实际上背后的道理难以言说。质量是反复思考的结果——严谨的反复思考。这就是关键。强化纪律的技术一定会提高质量。 2008-07-09 软件工程 Abel Avram译者 乔梁 InfoQ http://www.kuqin.com/software-engineer/20080705/10497.html 女性程序员会用有用的注解和说明点缀代码，解释一行行代码的作用。这些代码就像“路标”，其他人可以方便的修改和增添代码。男人，从另一方面说，可不会这么做，为了展现聪明才华，他们总是写一些模糊的代码，他们把一切都搞得不清不楚，而且不留下说明指示以供后来者参 2008-07-05 软件工程 matrix solidot.org http://www.kuqin.com/software-engineer/20080704/10416.html 如果将主要的精力和时间花在雕琢软件特别是界面上是不可取的，那样做往往是浪费时间，因为在软件的开发中还有更重要的事情等着要做。我并不是说软件界面不重要，相反软件界面是用户体验的重头戏，我说的是没有必要特别的去雕刻软件，要有一种全局观 2008-07-04 软件工程 alisx 博客园