流程方法

今年春节时，我写了一篇《TDD并不是看上去的那么美》，在这篇文章中我列举了一些关于使用TDD的一些难点和对TDD的质疑，后来出现了一些争论（可参见那篇文章的评论），以及Todd同学的《TDD到底美不美》，还有infoQ中文上的那个几乎没有营养离线讨论。今天，有网友给我推来一个英文版infoQ的视频——“Coplien and Martin Debate TDD, CDD and Professionalism”，这是2008年2月18日的视频，视频的主角两个人争论TDD好还是不好，一个是敏捷社区的教主级的人物——Robert Martin（大家称之为“Bob大叔”），另一个是C++，OO，多范式编程的大师Jim Coplien（大家都叫他Cope）。这两个人对TDD的见解有分歧。Coplien的很多观点和我之前的不谋而合，而他自己称他是坚决强烈地站在TDD的对立面上。下面是Jim的原话： I have adopted a very strong position against what particularly the XP community is calling test ...

下面文章由网友吕毅投递，源文是：http://blog.lvscar.info/?p=427 ————————————————————————————————————————————— 周末聚会，无意间聊起建筑行业。自己是搞软件开发的，我们的行业从建筑设计/施工过程中借鉴了大量的概念，隐喻，名词。可以说软件就是现实中伴随整个人类历史发展的“建筑”在虚拟空间中的投影。有个两年前问过其他朋友的问题，这次友人又再次提起，“为什么建筑设计过程中没有普遍性的采用版本控制呢？” 瞎扯了一干各种原因后，我们几乎同时想到一个名字”Joel”，建筑设计行业或许缺乏像Joel Spolsky一样十数年如一日，把自己丰富的经验和深入的思考转化成一篇篇文章以向新人传授软件开发过程中那些容易被忽略的概念。高傲的黑客们会对CMMI之类的认证抱以鄙夷之情，但对Joel整理出的12条写出更好软件的”最佳实践”，大家甚至把此称为审视其他团队开发过程的“Joel TEST”以推崇 这12条测试如下: 1. 是否启用版本控制？ 2. 是否可以一步构建? 3. 是否进行每日构建？ 4. 是否有bug跟踪列表？ ...

本文译自Dr. Dobb’s Blogger的Walter Bright写的《Overlooked Essentials For Optimizing Code 》 我编写程序至今有35年了，我做了很多关于程序执行速度方面优化的工(一个示例)，我也看过其它人做的优化。我发现有两个最基本的优化技术总是被人所忽略。 注意，这两个技术并不是避免时机不成熟的优化。并不是把冒泡排序变成快速排序（算法优化）。也不是语言或是编译器的优化。也不是把 i*4写成i<<2 的优化。 这两个技术是： 使用 一个profiler。 查看程序执行时的汇编码。 使用这两个技术的人将会成功地写出运行快的代码，不会使用这两个技术的人则不行。下面让我为你细细道来。 使用一个 Profiler 我们知道，程序运行时的90%的时间是用在了10%的代码上。我发现这并不准确。一次又一次地，我发现，几乎所有的程序会在1%的代码上花了99%的运行时间。但是，是哪个1%？一个好的Profiler可以告诉你这个答案。就算我们需要使用100个小时在这1%的代码上进行优化，也比使用100个小时在其它99%的代码上优 ...

在Stack Overflow上有这样的一个贴子《What’s your most controversial programming opinion?》，翻译成中文就是“你认为最有争议的编程观点是什么？”，不过，在400多个主回贴，以及千把个子回贴中，好像并不是很有争议，而是令人相当的茅塞顿开，下面罗列一些，并通过我自己的经历和理解发挥了一些，希望对你有帮助。 1） The only “best practice” you should be using all the time is “Use Your Brain”. 唯一的“Best Practice”并不是使用各种各样被前人总结过的各种设计方法、模式，框架，那些著名的方法、模式、框架只代码赞同他们的人多，并不代表他们适合你，你应该更多的去使用你的大脑，独立地思考那些方法、模式、框架出现的原因和其背后的想法和思想，那才是“best practice”。事实上来说，那些所谓的“Best Practice”只不过是限制那些糟糕的程序员们的破坏力。 2）Programmers who don’t code in their spar ...

Jimmy Bogard 曾经写过一篇文章： 《从单元测试中获益》，这这篇文章中给出了下面三条规则： “测试名应该从用户的角度描述是什么和为什么” – 这样一来，程序员可以从名字就可以知道用户需要什么样的软件行为。 “测试也是代码，同样也需要我们更多的爱” – 真实运行在生产环境下的代码不仅仅只是我们需要去关心和花心思的代码。对于单元测试中的代码同样也需要易读易维护，以及可重用的特性。“我非常痛恨那些又长又复杂的测试代码，如果一个测试需要30行的单元测试代码，请把其放在一个方法中。一个长的测试步骤只会激怒程序员。如果你在正式的代码中都没有这么长的代码，那么为什么我们需要在测试代码中容忍这样的情形呢？” “不要只用一种固定的模式或组织风格” – 有些时候，对于一些特殊的测试案例，标准的类设计模式，或一个固有的测试装置可能并不能有效的工作。 Lior Friedman 加上： “第0条 – 测试应该只测试单元其外部的行为，而不是内部的结构”。或者说，只测试对一个单元的期望，而不是这个单元的构成。 Ravichandran Jv 也加上了他的条例： 一个测试一个断言（如果可 ...

虽然这样的文章非常的多，并且，就算是对于编程新手来说，也是非常的简单和显而见，但是，在我们进行Code Review过程中，我们还是能够看到那些非常混乱的代码，所以，有些时候，你会在想，是不是这样的规则太多了，导致我们的程序员记不住。虽然我们在以前的文章中一遍又一遍的说过（比如：《优质代码的十诫》），千言万语总结一下，无论你用什么样的语言，最最基本的编程原则就是下面这四条。 1 – 简短的方法 简单才会易读，简单才会容易，简单才能重用，简单才能保证质量。把一件事搞复杂，是一件简单的事；而把一件事变简单，这则是一件复杂的事。KISS-Keep it Simple Stupid是一种哲学，Do one thing, Do it best也是一种哲学。这些都是在告诉我们，做设计，做产品，不要把所有的东西一下子都考虑进来，否则将会让你的事情变成一团糟，剪不断理还乱，就是这样道理。把复杂的事情，困难的事情，逐步细化，分解成一个一个简单而单一的事情，然后再把他们拼装起来完成一个复杂的事情，是我们如何完成一个巨大并复杂的项目的通用方法。 编程也是这个道理，维护代码的成本会比你创造代码的成本要大得 ...

质量管理在软件工程中是非常非常重要的一个环节，无论你有多么精妙的算法，或是使用了多么先进的技术，还是拥有了多少强的设计，在质量控制或质量管理面前，这些都可能什么都不是。这里，有一些质量管理的法则，可以让软件的用户从中受益。如果对质量管理一言以蔽之：面对一个长期不断需要改善的软件，当其用户或是管理者们来说，他们对某个组织所提供的标准有一种完全和最基本的信任。 下面，我们给出8个质量管理的法则： 1. 始终从用户角度出发: “无论何时何地，我们都需要明白用户当前的或未来的需求，并能够达到用户的需求，甚至超出用户的期望。” 这是整个软件工程的重中之重。质量管理从某种意义上来说，就是实现用户需求的质量的管理。这需要我们的质量管理管理和用户的关系，以及把用户的需求和整个团队（开发组，测试组，产品组，项目组等等）进行有些的沟通管理。 2. 领导能力: “领导者需要建立一个团结统一的有明确方向的团队。这个团队可以创造并维护一种良好的内部气氛，这种氛围可以使得所有的人都能参与进来，从而达到整个团队的目标。” 对此，我们需要有一个有前瞻性的领导能为整个团队创建一种相互信任的环境。提倡诚实，并积极引导 ...

下面是14件如何有效编程的方法： 目录 计划(Plan) 使用伪代码 书写清楚的注释 使用自动的编辑工具 减少代码 代码重用 代码重构 使用设计模式 使用程序框架Framework 泛型编程 使用开源的代码 完善开发环境 使用调试器 使用版本管理工具 计划(Plan) 所谓Plan，其实就是对应于编程中的“设计”阶段，当然，这里的Plan并不像设计那样重量级。它要求我们程序员在正式编程前至少要考虑一下下面的问题： 你这个程序，工具或是项目的目的，究竟是用来干什么的。你只有知道做什么，要达到什么样的目的，你才能做得对，做得好。 需要有什么样的功能。需要你给出来个功能列表。这样可以保证我们不会遗露了什么。 准备好一些技术难题的前期调查和解决方案。不要等到开始编程的时候才去想。 下面这你因为有“Plan”而得到的好处： 你 ...

软件开发是一个跨度很大的技术工作，在语言方面，有C，C++，Java，Ruby等等等等，在环境方面，又分嵌入式，桌面系统，企业级，WEB，基础系统，或是科学研究。但是，不管是什么的情况，总是有一些通用的基本职业技能。 这些最基本的职业技能通常决定了一个程序员的级别，能否用好这些技能，直接关系到了程序员的职业生涯。很多程序新手也是因为缺少、达不到或是不熟悉在这些基本技能，所以，他们需要有老手带，需要努力补齐这些技能。而高级程序员应该非常熟悉这些基本技能，而且有能力胜任并带领其他经验不足的程序员。 下面这些基本职业技术可以用来做为对一个程序员的评估，很明显，下面的这些技能都可以用来做面试。虽然，还有很多非技术的因素，但对于评估一个程序员的技术能力来说，其应该是足够的了。 下面是程序员所应该具备的基本职业技能： 基本技能 技能描述 阅读代码 这个技能需要程序员能够具备读懂已经存在的代码的能力，这样的能力可以让程序员分析程序的行为，了解程序，这样才能和开发团队一起工作，继承维护或是改进现有的程序。 编写程序 编写程序并 ...