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/20090705/60837.html Jaibeer Malik最近发布了一个关于如何在团队中评估和引入代码质量的系列文章。如果你现在需要学习关于代码质量的知识，或者要给其他人介绍相关想法的话，这些文章你可能会很感兴趣。文中提供了关于这个主题的简要介绍，并为进一步研究代码质量给出了指南。 Jaibeer提到 2009-07-05 软件工程 Niclas Nilsson 译者 霍泰稳 InfoQ http://www.kuqin.com/software-engineer/20090702/60075.html 　　迭代在于我们明确的承认信息和知识的不完备性， 不可完备性。 而项目的成功， 需要某种程度的完备性。 　　这种认知的局限与成功的条件之间的矛盾， 促成了人们解决这类问题的通用方法： 渐进的试错法 　　试错法参考一： http://en.wikipedia.org/wiki/Trial_and 2009-07-02 软件工程 切尔斯基 CSDN博客 http://www.kuqin.com/software-engineer/20090626/59050.html &ldquo;究竟为什么我们要使用两个人来同时做同一件事情呢？&rdquo;这往往是初次听说结对编程的人的第一反应。实际上，他们觉得结对编程使写代码的成本翻了一倍。Dave Nicollete用数字说话，告诉大家结对编程是如何省钱，而不是浪费钱的。 由于错误地认为编程主要就是 2009-06-26 软件工程 Mike Bria 译者 金毅 InfoQ http://www.kuqin.com/software-engineer/20090625/58802.html BOSCO系统是一个在线品牌管理系统，项目客户是一家跨国酒店集团，旗下拥有多个世界著名的酒店品牌。BOSCO系统将服务标准化、标准符合度审查、改进流程管理等酒店品牌管理的工作内容整合到一个信息系统中，来提高相关人员的工作效率。目前BOSCO系统已经被全球十个酒店品 2009-06-25 软件工程 胡振波 《程序员》官方BLOG http://www.kuqin.com/software-engineer/20090615/56722.html 老婆经常夸我有想法，得益于老婆大人的鼓励，我才打算将自己平时所想，所总结的东西写下来。人是需要不断总结的，有总结才会有进步。所谓总结，并不一定是多么高深的道理，多么复杂的推论，也并不一定要长篇大论。有时，一句话，或是一个瞬间，会让你明白很多。 首先 2009-06-15 软件工程 CoderZh 博客园 http://www.kuqin.com/software-engineer/20090615/56713.html 编程之广，包罗万象，从用uml工具进行总体框架设计来体现各种设计模式，到高内聚，低耦合，面向接口编程，依赖倒置，再到参数类型的抽象（泛型）,函数的封装，每个私有字段的通过属性进行控制访问，以及软件工程等诸多奇妙的开发模型，归根结底，不过只为两个字：效率！ 2009-06-15 软件工程 李璞 博客园 http://www.kuqin.com/software-engineer/20090609/55697.html 概要 Pollyanna Pixton 告诉我们，在一个互相信任的文化氛围中，领导者必须退到后面，否则他们会阻碍和限制团队的生产力、创造力和革新力。她论述了领导者怎么营造一个互相信任的文化氛围，以及为了将敏捷开发团队的能力发挥到极至，领导者必须要做的事情。 个人简 2009-06-09 软件工程 Pollyanna Pixton 采访人 Debora InfoQ http://www.kuqin.com/software-engineer/20090609/55696.html 由颇受业界尊敬的敏捷思想倡导者Jim Shore和Diana Larsen于下周举办的公开课的报名已经接近爆满。在Jim准备此次课程期间，InfoQ有机会采访到了他。在这次非正式的访谈中，InfoQ跟Jim聊了一些最近跟他密切相关的话题，包括他的《敏捷开发艺术》一书，还有他的一些观点， 2009-06-09 软件工程 Mike Bria 译者 金毅 InfoQ http://www.kuqin.com/software-engineer/20090608/55560.html 原文链接：http://makinggoodsoftware.com/2009/06/04/10-commandments-for-creating-good-code/ 本文出自：http://cocre.com/?p=1007 1.- DRY: Don&rsquo;t repeat yourself. DRY&nbsp;是一个最简单的法则，也是最容易被理解的。但它也可能是最难被应用的（因为要做 2009-06-08 软件工程 秩名 酷壳 http://www.kuqin.com/software-engineer/20090607/55358.html 《人件》中总结了软件管理中七个不真实期望，请不要相信这些期望，它们被比喻为七个女妖： （1）有使你的生产力剧增的新诀窍，你已经错过了； （2）其他经理的成效是正100%、200%或者更多； （3）技术正飞快发展，而你正在被淘汰； （4）改变语言将使你收获巨大； （5 2009-06-07 软件工程 柔晶 Taobao QA Team http://www.kuqin.com/software-engineer/20090607/55357.html 原文链接：http://choosyinfo.com/technology/quality-management-principles 译文出自：http://cocre.com/?p=971 质量管理在软件工程中是非常非常重要的一个环节，无论你有多么精妙的算法，或是使用了多么先进的技术，还是拥有了多少强的设计，在质量控制或质量管理面 2009-06-07 软件工程 Ruchi 酷壳 http://www.kuqin.com/software-engineer/20090604/54975.html 最近一个项目发布了，可是这个群的消息还每天不断的弹出来。项目组的人还每天不断的优化功能，提出日常需求。似乎项目虽然发布了，但是远远没有达到完美，项目还没有结束。有些可惜的是，如果不是定死发布日期，我们完全可以把项目做的更好。 《人件》中通过跟踪大量项 2009-06-04 软件工程 柔晶 Taobao QA Team http://www.kuqin.com/software-engineer/20090604/54974.html 在一个关于超高生产力与电击疗法的演讲中，Jeff Sutherland提到：超高生产力（Hyper-Productivity）至少应该达到丰田的绩效水准，也就是四倍于行业平均水平。他认为：正确进行敏捷开发的团队，应该可以在3个为期两周的迭代中体现出300%的进步。最近在Scrum Development 2009-06-04 软件工程 Vikas Hazrati 译者 郑柯 InfoQ http://www.kuqin.com/software-engineer/20090529/53818.html 写代码，其实也是用一种特殊的语言——程序语言，而不是文字来表达一段意思。我们平时写文章需要注意分段，分层，分条理，写程序也是一样。可能由于水平有限，你一时还无法写出华丽俊秀的文字，但是写文章的首要目标还是“清晰”，要让别人明白你的意思。 2009-05-29 软件工程 老赵 博客园 http://www.kuqin.com/software-engineer/20090529/53817.html 如果你想提高团队的生产效率，就照这3条做：修改任何代码前先编写一个会失败的简短测试；遵循“不结对，不干活”的原则；所有人要认识到内部质量的重要性。 2009-05-29 软件工程 Mike Bria 译者 张晓庆 InfoQ http://www.kuqin.com/software-engineer/20090528/53600.html 在回顾了敏捷宣言的4项核心原则（作者这里所指的4项原则，实际是指敏捷宣言中的4项价值观）之后，作者Jason Bloomberg认为，部分原则是适合EA/SOA层面的，但并非全部，而且必须进行新的解释。 2009-05-28 软件工程 胡键 InfoQ http://www.kuqin.com/software-engineer/20090523/52901.html 为修改代码更容易，应该注意某些小细节。特别是工程比较大的时候。有些习惯要一开始就养成，不要想着只是做些小玩意玩玩，没有关系啦。一开始就应向着这行业最top的那批人看齐，这样才有可能做到专业。 2009-05-23 软件工程 秩名 博客园 http://www.kuqin.com/software-engineer/20090523/52899.html 本文源自devtopics.com的一篇文章，收集了101条各行各业的名人对计算机行业的评语，尤其集中在软件开发这个领域。 2009-05-23 软件工程 秩名 酷勤网 http://www.kuqin.com/software-engineer/20090523/52898.html 提升软件团队的交付能力，其实最好的办法就是释放团队的软件生产力，而不是试图去规范它、约束它。这里，我们用“软件生产力”来定义软件团队开发软件的能力，包括软件团队在软件开发过程中为了解决各种各样的问题而使用的开发语言、开发工具以及开发实践。 2009-05-23 软件工程 mingj BlogJava http://www.kuqin.com/software-engineer/20090522/52700.html Smart原先是由RAD和DSDM实践开始，及后并亦加入一些Scrum及XP的实践。如果跟Mike Cohn在该演讲内容提到的其他方法比较，Smart相对上是不太敏捷的。 2009-05-22 软件工程 麦天志 InfoQ http://www.kuqin.com/software-engineer/20090520/52281.html 需求是不是总做不完？产品质量是不是没办法保证？一个月以前做的功能，是不是到现在包括开发者，都不能说出功能详细情况，还得去看看代码？虽然你不断加班，老板是不是还觉得产品进度太慢？那就对了，你应该！ 2009-05-20 软件工程 屈伟 TechWeb http://www.kuqin.com/software-engineer/20090519/52068.html Henrik Kniberg最新发表 比较看板开发方式和Scrum的"实务指引" ，Kniberg在这精要的文章中指出看板开发和Scrum如何类似以及如何不同。 2009-05-19 软件工程 Mike Bria 译者 麦天志 InfoQ http://www.kuqin.com/software-engineer/20090516/51569.html 调试程序的难度是写代码的两倍。因此，只要你的代码写的尽可能的清楚，那么你在调试代码时就不需要那么地有技巧；用代码行来衡量开发进度，无异于用重量来衡量制造飞机的进度；我才不关于我的代码是否能在你的机器上工作！我们不会给你提供机器…… 2009-05-16 软件工程 秩名 酷壳 http://www.kuqin.com/software-engineer/20090515/51394.html Keith Braitwaite有以下见解：我认为如看板开发过程般以线性、关卡、"手递手"方式过程、没打算重做工作的诠释让很多人抗拒。 2009-05-15 软件工程 Chris Sims 译者 麦天志 InfoQ http://www.kuqin.com/software-engineer/20090429/48864.html 对于质量是什么，大家并没有清晰的共识。但是，大家都赞同质量不是对缺陷数目的衡量。作者们也都认为我们需要实事求是，必须承认一旦有了缺陷就不能再奢论质量。 2009-04-29 软件工程 Mark Levison译者 金明 InfoQ http://www.kuqin.com/software-engineer/20090428/48756.html 如今的实践是指那些标准的、团队开展工作的最佳方式。随着标准的建立，团队会被鼓励去做新的尝试，找到改进的方式，从而带来新的标准。使用标准的目的不是去限制团队。相反地，标准是持续改进的基线。 2009-04-28 软件工程 Chris Sims译者 金毅 InfoQ http://www.kuqin.com/software-engineer/20090426/48244.html 从目前来看，CTO要立足IT，但远不仅限于IT，未来欲屹于不败的CTO应是复合型高级人才，他不仅是一个顶尖的技术专家，还应是一个卓越的经营大师，更是一个优异的会计师和教育家，只有朝此向发展，才能实现职业生涯成功的“大满贯”。 2009-04-26 软件工程 刘亮 IT168 http://www.kuqin.com/software-engineer/20090426/48225.html 凡在一个总体设计或初步设计范围内经济上统一核算的主体工程、配套工程及附属设施，应编制统一的项目建议书；在一个总体设计范围内，经济上独立核算的各工程项目，应分别编制项目建议书;在一个总体设计范围内的分期建设工程项目，也应分别编制项目建议书。 2009-04-26 软件工程 秩名 希赛论坛 http://www.kuqin.com/software-engineer/20090426/48219.html 我想我每年都应该反思一下这种问题，以便成为一个更好的软件开发人员。尽管如此，我还是觉得我的信念已经固定下来了：越是成长，就越希望能够在一个足够自由的环境里面创造美妙的东西。 2009-04-26 软件工程 violasong 译言 http://www.kuqin.com/software-engineer/20090426/48178.html TDD是一项实践性很强的事，就像OO一样需要大量的实践来获得经验，因此如果能在平时养成写测试的习惯，从简单到复杂一点一点进行练习，就能慢慢的掌握TDD了。这里建议初学的人可以考虑先写代码后写测试，等到测试写的很熟练了再转到先写测试后写代码的阶段。 2009-04-26 软件工程 Nick Wang 博客园 http://www.kuqin.com/software-engineer/20090426/48160.html 专业型开发模式，通过对人员进行专业化分工，从而在软件开发过程中最大的利用了人力资源，提升软件的生产效率，并降低了软件的从业门槛。此方式在新形式下的项目开发和产品研发中都具有相当的竞争力，也易有利于保证公司的核心竞争力。 2009-04-26 软件工程 lbom BlogJava http://www.kuqin.com/software-engineer/20090425/48032.html 在这篇文章中，我们将会介绍我们如何成功地完成了一个大型的（20人年，超过十万行代码）、分布式（开发人员位于印度和荷兰）Scrum项目，而这个项目曾经在传统开发方式下被废弃过 。 2009-04-25 软件工程 Marco Mulder and Martin van Vl InfoQ http://www.kuqin.com/software-engineer/20090421/47178.html 作者认为，写代码与环境关系不大，而是与心境有关。情绪，态度和内在能帮助你寻找到写代码的缪斯。也许这需要你有充足的睡眠，家庭、家人或者你内在的信念都有助于你写出最好的代码，而不管周围的物理环境如何。 2009-04-21 软件工程 秩名 Solidot http://www.kuqin.com/software-engineer/20090419/46718.html 说起来，我的感触就是：“除非确无它法，不要编写庞大的程序” 。简洁小巧的程序总是好维护的。尤其是容易进入状态的。我说的进入状态即：在出现 bug 的 30 分钟内可以弄明白那些不是自己写的、陌生的没有读过的代码的脉络。并且开始着手解决问题。 2009-04-19 软件工程 云风 云风的 BLOG http://www.kuqin.com/software-engineer/20090419/46678.html 过早优化对大的问题在于：过早关注不重要的部分，而忽略行动和目标本身。以静态的思维来优化，殊不知，事务发展总是动态的，“优化”是需要长期的实践积累才可以获得。出发点是好的，但往往好心办坏事，折腾大量的时间，做了很多不该做的，而该做的、重要的反而没做。 2009-04-19 软件工程 xjb 守望轩 http://www.kuqin.com/software-engineer/20090401/43345.html 在敏捷团队中，我们所要做的只不过是：不断的回顾、找出问题与瓶颈、不断地重构。通过不断重构持续集成基础结构以及自动化构建脚本，使其达到我们对“反馈时间”和“判断质量准确性”的要求。 2009-04-01 软件工程 乔梁 InfoQ http://www.kuqin.com/software-engineer/20090327/42822.html 如果换一句和 KISS 原则相当分量的话，我会说：不要用愚蠢的方法做事。很矛盾？Repeat Yourself 往往代表了一些愚蠢的方案，且并不 simple ，至少会付出更多的体力。我想，KISS 的最后一个 S 指的是大智若愚的愚，而自做聪明则是另一种愚蠢。 2009-03-27 软件工程 云风 云风的 BLOG http://www.kuqin.com/software-engineer/20090321/41733.html 圈复杂度，它可以精确地测量路径复杂度。通过利用某一方法路由不同的路径，这一基于整数的度量可适当地描述方法复杂度。实际上，过去几年的各种研究已经确定：圈复杂度大于 10 的方法存在很大的出错风险。 2009-03-21 软件工程 xiaodan 阿里巴巴（软件）开发者博客 http://www.kuqin.com/software-engineer/20090320/41479.html 大家有没有这样的经历：当自己拿过来一个新项目的时候，看完之后发现跟自己之前写过的一个项目很相似，可能改改之前的项目，新项目就出来了，所以自己很兴奋的去找以前的项目，可是遗憾的是，您怎么也找不到了！ 2009-03-20 软件工程 一线工作者 博客园 http://www.kuqin.com/software-engineer/20090318/40907.html 我们可以把每一个的User Story的各个功能点想的更加完善，这个是很好的，剩下的只是如何取舍的了，所谓取舍，只是阶段性的舍弃和选择罢了。所以在讨论过程中，不要因为功能的增强，范围的扩大而让我们感到害怕和困惑，把他们记录下来，就是很好的逐步改进系统的武器。 2009-03-18 软件工程 秩名 IT168 http://www.kuqin.com/software-engineer/20090309/38822.html 你们认为编程的首要原则是什么？ 作为我的学习原则的一个实践：学习一项知识，必须问自己三个重要问题：1. 它的本质是什么。2. 它的第一原则是什么。3. 它的知识结构是怎样的。 2009-03-09 软件工程 刘未鹏 刘未鹏 | Mind Hacks http://www.kuqin.com/software-engineer/20090302/37418.html 需求变更有3种情况，一种是客户提出来要进行修改，增加需求等，一种是公司内部人员提交的建议，还有就是开发人员自己修改流程（修改后的效果比前面的更加好），另外需求变更可能是比较小的改动，另外一种就是可能涉及到整个产品流程，这就是比较大的需求改动。 2009-03-02 软件工程 hlearning 博客园 http://www.kuqin.com/software-engineer/20090301/37209.html 男人写的代码也同样的，虽然是你写出来的，但是可能需要别人来维护，需要别人来阅读理解，别人会欣赏学习你的做法，这跟女人比，就好比她们的脸，门面啊。所以大家别变量名不乱来、大小写不乱来、排版不乱来、要整整齐齐、经常维护且反复维护优化。 2009-03-01 软件工程 吉日嘎拉 博客园 http://www.kuqin.com/software-engineer/20090225/36570.html 开发效率常常和优秀结构冲突。一般慢功才出细活，而赶时间做出来的东西总会有结构上的不足。这些不足只会在以后软件功能发生变化，需要扩展的时候才会显示出来。时间紧的时候，开发效率常是优秀结构的克星。 2009-02-25 软件工程 苏林 csdn博客 http://www.kuqin.com/software-engineer/20090203/33937.html 正如J.B.所指出的，优秀设计的清晰定义也许只是一个愿望，不论我们走了多远，它总是我们面前的一步。但是正如J.B.和 Bellware强调的，我们有工具指导我们做出好的设计，保持我们的生产力，让我们做个幸福快乐的程序员。 2009-02-03 软件工程 Mike Bria译者 崔康 InfoQ http://www.kuqin.com/software-engineer/20090201/33573.html Israel认为，采用敏捷方法，内部发布更多更快，使得软件更流畅、更有活力。这让传统的发布流程过时了。把发布区分开可以帮助工程和商业按照自己的发布模式工作，而不会互相打乱发布频率。 2009-02-01 软件工程 Vikas Hazrati译者 张晓庆 InfoQ http://www.kuqin.com/software-engineer/20090201/33572.html 按照Martin Fowler的观点，要想为软件带来更好的质量并向客户交付价值，团队成员应该拥有丰富的技能，这是最基本的保证。尽管在最初会缺少特定领域和特定技术和经验也没有关系。 2009-02-01 软件工程 Sadek Drobi译者 韩锴 InfoQ http://www.kuqin.com/software-engineer/20090126/33312.html Borland从06年2月开始项目试点，想看看敏捷方法能不能帮助他们达成三个核心目标：缩短交付时间、增强整体生产力、鼓励客户参与开发过程，从而确保产品可以满足市场需要。这个项目非常成功，团队提前十天交付了项目，而且比一开始计划的时候增加了很多新特性。 2009-01-26 软件工程 李剑 InfoQ http://www.kuqin.com/software-engineer/20090125/33297.html 在敏捷论文中常常会提到小鸡和猪的故事。在用熏肉和鸡蛋做的早餐中，鸡只是参与，而猪则是付出。所以，“猪”这个词用来形容对某件事情付出全部精力的人，而“鸡”虽然参与了，但是投入的程度比“猪”小。 2009-01-25 软件工程 Chris Sims译者 李剑 InfoQ http://www.kuqin.com/software-engineer/20090105/32571.html 局部优化是让程序变得糟糕的最主要的一个原因. 用高爷爷的话说, 提前优化是万恶之源 (Premature optimization is the root of all evil). 这些技巧, 就是带你去万恶之源的捷径. 2009-01-05 软件工程 徐宥 4G spaces