提高软件质量实践――Google篇
很多人应该都看过James whittaker的博客或新书 《How Google test software》，在这里我不想重复他的内容，而是从另外一个角度来分析对比Google是如何保障它的产品质量的。 首先申明的是本人并没有在Google工作过，所以没有第一手的经验，仅以一个旁观者的身份来分析Google的质量控制实践。主要信息来源于google测试博客，在西雅图Google工作的朋友聊天和... [阅读全文]
程序员开发大型应用程序的技巧
英文原文：Tips to Developers Starting _disibledevent=MaintainJ Inc.创始人。该公司提供的工具用于在维护大型Java项目时节省开支。作者在开发和维护企业级Java应用方面已经有15年的经验，并且具有Sun认证的企业架构师与Java开发者资格。他目前和妻子以及2个儿子居住在加拿大多伦多。 关于译者 陈晨， 长期从事互联网信息收集分析领域架构研究。... [阅读全文]
开发人员与测试人员的划分
英文原文：The Developer-Tester Divide 作者：Gil Zilberfeld 译者：蔡坚安 从此以后他们幸福地生活在一起 关于开发人员和测试人员的关系，人们阐述了很多，讨论了很多，争论了很多。而貌似一旦这两者坐在一起，对峙便开始了，两者间的争论多于相互认同。显然，这不利于实现两者合作的目标——向用户提供价值。 让我们来分析事情的来龙去脉和现状，思考... [阅读全文]
从经理的角度看技术债务
英文原文：Technical Debt a Perspective for Managers 作者：Mark Levison 译者：赖勤毅 发布于 2010年11月5日 现在已经到第十次迭代开发周期了，你的项目开发速度开始变慢。在之前的几个迭代周期中，团队没有像以前那样完成很多的“故事场景”（stories）。此外，最近在新的故事场景和回溯中却发现更多缺陷(bug)。项目... [阅读全文]
敏捷开发：如何通过回顾保持学习状态
英文原文： How To: Live and Learn with Retrospectives 软件开发不是孤独的追击，它需要同其他开发者和其他部门协作。大多数组织建立的软件生命周期没有涉及到如何进行这些交互。现实是许多团队的过程并不符合他们的要求或没有得到一贯地遵循。当发生这种情况时，很容易让人产生抱怨情绪，如果你已经有了改进的想法却又无从下手，也会让人感到沮丧。本文提供了一个工具，可以帮助... [阅读全文]
苦并快乐着,重构,让人快乐让人苦
重构，是编写代码必须要面对的一项操作，同时也应该是程序员乐于实践的一项内容。不论是逻辑实现还是设计过程，乃至整个分层结构，我们都可能面临并且实施重构。这篇文章不会告诉您什么是重构，如何去优美的重构等等的理论，只想和大家分享一些感受，并且探讨一些问题。最近的两周，我一直对我们团队的一个子业务框架做重构的工作，很多地方让我感到很痛苦，于是便有了这篇文章。 牵一发而动全身的根源在哪里 当我打开解决方案... [阅读全文]
自动化专业代码,代码规范的自动化监管
英文原文：Implementing Automated Governance for Coding Standards 作者：Mark Figley 译者：罗小平 多数大型开发组织都有一套自己的编码和实践规范。但是对这些团队而言，光是将这些规范文档化，并保证实时更新，就是一个巨大的挑战。此外，在工作中长期、忠实地执行这些规范和标准，难度就更大。我们团队在这些方面做了积极探索，在整个构建过程（bu... [阅读全文]
如何编写技术文档,如何编写优质的需求文档
英文原文：How to write good requirements 编写需求文档，在嵌入式开发领域是非常普遍的。需求文档被用来定义开发任务，协调大规模的研发计划。对于最终的产品，需求文档扮演着开发者行为和消费者行为之间沟通纽带的角色。当需求文档书写正确的时候，便可以发挥巨大的作用。然而，如果你在嵌入式开发领域工作的时间足够长，你就会很快发现，这个领域里不合格的需求文档实在是太多了。当你尝试对这... [阅读全文]
持续集成,持续集成之戏说Check-in Dance
尽管Thoughtworks的首席科学家Martion folwer 为“持续集成 ”下了定义，但由于自身背景与经历的不同，每个人对其都有不同的理解。从狭义上讲，持续集成可以认为是一种基于某种或者某些变化对软件系统进行的经常性的构建活动（注：这里的构建活动不仅指编译打包工作，还包含各类自动化测试、部署及发布活动）。然而，它忽视了一点，即：任何实践中都应该包含“与... [阅读全文]
持续集成,持续集成之"软件自我识别
在前文《自动化部署》中，我们讨论了自动化部署。通过对部署操作脚本化、部署验证自动化、部署环境版本控制、生产部署全自动化等诸多实践，可以让部署完全处于受控状态。然而，作为运维人员，是否曾经有人走过来问你这样的问题：“当前生产环境上部署的是哪个软件版本？”你是否遇到过这样的情形，即使手里拿着一个jar文件或dll文件，也无法知道它到底是哪个版本。也许你可能认为，这算不了什么，到... [阅读全文]
持续集成之"Everything is code
在前文《软件自我识别》中，我们讨论了如果使软件做到自我识别，以促进自动化部署和版本检测等工作。 随着互联网的飞速发展，以及基础设施的改进，越来越多的业务被放在了“云”端。管理数千台服务器和各种应用程序的不同版本已经是一种常规事务了。那么如果管理好这些机器和代码吗？本文将介绍一些最佳实践，来帮助大家更好的完成相关的事务。 一、测试代码不是二等公民 业务压力让团队人力显得有点儿... [阅读全文]
恰如其分,设计恰如其分的架构
Thoughtworks 的 Sam Newman 在 Mythoughtworks 的 Software Development 小组中给出了 Evolutionary Architecture 的一些资源。其中一个是 Martin Fowler 与 Rebecca Parsons 在 QCon SF 2009 的一次演讲，题目为 Agilists and Architects: Allies... [阅读全文]
成功在于过程,"品质在于构建过程 吗?
今天在微博上看到几位敏捷爱好者（本着讨论问题的态度故隐其名）探讨敏捷测试和质量保证问题，我忍不住也加入了讨论： Z先生原帖：我刚才看到一个大会演讲稿，谈到敏捷测试六大指导原则：1. 仅靠测试人员不可能获得高质量的软件，质量是整个研发团队的责任；2. 场景是不可穷举的，测试活动必须是风险驱动的，关注于高风险的场景；3.分层自动化测试是唯一出路；4. 在正确的位置进行恰当的测试是自动化的关键；【待续... [阅读全文]
git分支管理,GIT分支管理是一门艺术
英文原文：http://www.nvie.com/posts/a-successful-git-branching-model/ 原文作者：Vincent Driessen 本文经Linux大棚博主总结精简而成。 1 GIT，在技术层面上，绝对是一个无中心的分布式版本控制系统，但在管理层面上，我建议你保持一个中心版本库。 2 我建议，一个中心版本库(我们叫它origin)至少包括两个分支，即... [阅读全文]
持续集成,重温大师经典：Martin Fowler 的持续集成
英文原文：Continuous Integration （作者：Martin Fowler，译者：滕云） 原文发布时间：2006年5月1日 翻译时间：2012年2月25日 持续集成是一种软件开发实践，在实践中项目成员频繁地进行集成，通常每个成员每天都会做集成工作，如此，每天整个项目将会有多次集成。每次集成后都会通过自动化构建（包括测试）来尽快发现其中的错误。许多团队都发现这种方法大大地减少了集... [阅读全文]
版本控制工具,版本控制工具历史的10个里程碑
英文原文：Astonishments, ten, in the history of version control 引言： “如果你想要了解真正的历史，你需要回到在打孔卡上进行人工比对的年代。” —— Jim Rootham 在这个为鳕鱼编写传记都能够流行的年代，写一本记录程序员如何存储代码——他们最重要的劳动成果的书一... [阅读全文]
持续交付,持续交付的八条原则,你能做到几条?
英文原文：8 Principles of Continuous Delivery The process for releasing/deploying software MUST be repeatable and reliable.软件的发布或部署过程必须是可重复且可靠的。这就引出了下一条… Automate everything! 所有操作的自动化！我很难相信“... [阅读全文]
敏捷开发,敏捷开发"松结对编程 实践
传说中的结对编程，大致结构是两个人共用一台电脑，一个开发，一个测试，以随时评审来抵消返工时间损失。 传说归传说，谁也没有见过。问题出在哪里？有两种主要原因。 一是来自高层的，高层感觉两个人只有一个人干活，实在是有点浪费。“评审抵消返工时间”虚无缥缈，但每天只有一个人干活却是现实情况。 二是来自基层的，两人若有高低，高手肯定觉得还不如我一个人干的快；两人若旗鼓相当，难免产生争... [阅读全文]
平衡敏捷与规范,敏捷发布与轻应用
对于流行的“敏捷发布”概念，我的感情很复杂。一方面我自己就是敏捷发布的忠实支持者，但又看到了对它大量的滥用，甚至我自己也有可能滥用。 前些日子看见一个典型案例，一同行说，自己的新浪微博应用，从提出创意到发布只用了6天，6天！这款应用叫“APP汇”，思路上挺带感的APP社交推荐服务。从正面的意义讲，尽早拿出一个可用原型来接受市场检验，再根据真实数据与反... [阅读全文]
devops,建设DevOps能力,实现业务敏捷
当软件行业进入互联网时代，市场对软件产品和服务的交付提出了更高的要求：不仅要快速实现需求，而且要快速发布上线，并且必须保证业务可靠、高效运行。为了满足这些要求，IT组织需要强有力的流程、技术和人员作为保障。 ThoughtWorks很早就认识到发布与运营对于成功交付的重要性。我们的创始人Roy Singham在《走完业务软件的“最后一公里”》[1]一文中指出： 所谓[软件开... [阅读全文]
tfs2010,在 TFS 2010 中运用 Agile
在“Agile 宣言”中，有几个强调 Agile 团队该如何协同工作的关键词。 其中包括相对于流程和工具而言更重视个体（及其交互）的价值。 各团队将这些价值作为转向 Agile 开发的原因之一。 在过去 10 年左右的时间内，自宣言发布以来，开发了各种版本的 Agile。 我将进一步介绍 TFS 2010 中的一些选项，通过这些选项可以采用两种 Agile 流程模板之一，此... [阅读全文]
软件工程流程图,软件工程中的图情结
我们通常都是对图形化的东西情有独钟，我们小时候的启蒙教育基本上也都是从图形化开始的，我们曾经看过的连环画、漫画、看图识字等等。因为图形能将一个抽象的东西具体化、形象化，图形化的表述能将一个用文字语言无法表达清楚或很难表达的观点、事物、科学概念等清晰的呈现出来。这就是为什么我们相比晦涩难懂文字更喜欢形象生动的图形的原因。 软件工程导论作为软件工程中非常重要的一门课程，通常因为其偏文科性、理论性、概... [阅读全文]
agile开发,敏捷软件开发 Agile Software Development
敏捷软件开发 Agile software Development 敏捷开发是一种软件开发方法，基于迭代和增量开发，通过自组织,跨团队，沟通协作完成开发工作。 敏捷宣言的诞生： 2001年2月11日到13日，17位软件开发领域的领军人物聚集在美国犹他州的滑雪胜地雪鸟（Snowbird）雪场。经过两天的讨论，“敏捷”（Agile）这个词为全体聚会者所接受，用以概括一套全新... [阅读全文]
敏捷测试,敏捷软件测试的七个关键成功要素
资深敏捷专家Lisa Crispin在最近的讲座和参与合著的《Agile Testing – A Practical Guide for Testers and Agile Teams》中分享了敏捷软件测试的七个关键成功要素，包括使用团队整体参与的方法、采用敏捷测试思维、自动化回归测试、提供并获取反馈、构建核心实践的基础、与客户合作、保持大局观等。 使用团队整体参与的方法 当整个... [阅读全文]
自动化部署,持续集成之"自动化部署
在前文《依赖管理》中，我们讨论了如何在代码变得庞大，组件增多的情况下，做好外部库和内部组件依赖管理，从而提高构建效率。可以应用的实践包括：一次生成，多次复用；建立统一制品库，外部依赖库可以使用像Maven或Ivy这样的工具进行统一管理；对架构进行调整，使一个大的代码库分成多个组件；每个组件有自己的持续集成体系；对多个组件做持续集成。然而，解决一个问题后，总会有另一个问题等在那里，需要你来解决。这次... [阅读全文]
测试驱动开发,你这不是测试驱动开发
英文原文：“That’s Not TDD” 几个月前，我去一个客户那里，他们在使用测试驱动开发上遇到了很多问题。 “我们的单元测试用例要半个小时才能跑完，”他说。 “你们这不是在做驱动测试开发，”我说。“为了让测试发挥效能，所有的测试必须在几秒钟内能跑完，否则的话，程序员不得不频繁的停下来等待测试。&... [阅读全文]
scrum,Scrum 实施经验
什么是 Scrum ? Scrum是一种迭代式增量软件开发过程，通常用于敏捷软件开发。Scrum在英语的意思是橄榄球里的争球。 虽然Scrum是为管理软件开发项目而开发的，它同样可以用于运行软件维护团队，或者作为计划管理方法：Scrum of Scrums 。 相关线上资料：http://zh.wikipedia.org/wiki/Scrum 角色 Scrum定义了许多角色，根据猪和鸡的笑话分... [阅读全文]
测试网速没问题,"测试是浪费时间,我的程序肯定没问题
英文原文：Testing is waste of time, I know that my code works 尽管关于测试驱动开发(TDD)的书和文章有成百上千之多，仍然有很多人从未感受过测试的强大力量。 之所以不愿意去写测试程序不外乎有以下几个理由： 太费时间。 不值得。 我很懒。 我不知道如何做。 我知道我的程序好用，我运行过一次，没出问题。 我是超人，我从来不犯错误。 除非你的答案是... [阅读全文]
你到底爱不爱我,TDD到底美不美?
最近CoolShell上的一篇《TDD并不是看上去的那么美》引起了敏捷社区的高度关注和激励辩论。今天，InfoQ甚至专门举行了一个虚拟座谈会《TDD有多美？》，几位国内敏捷社区的名人专门就此问题展开了深入地讨论。不论结果如何，这种探讨和反思的精神还是非常值得赞赏的。事件实际上可以简单地归纳为一个有一定影响力的开发人员质疑TDD，一群敏捷社区名人对TDD进行解释和辩护。现在，就让我坚定地站在Cool... [阅读全文]
