Nov 28
Posted by eDWARD at 14:28
- 对于聪明的人，只要一个字；对于快马，只要轻轻一鞭；对于写得好的程序，只要单独的一个命令。
- 设计一个千百万程序的操作系统很容易，要改变一个人的本性却困难得多。
- 开发前面的百分之九十需要一半时间，而另一半时间则用来完成最后的百分之十。
- 项目计划和公布的时间表，本身毫无意义。那些日期和项目进展的里程碑本质上不意味着什么。然而有一个秘密的时间表，它被所有工作于一个项目的人所理解。这个秘密的时间表从未被外界的关注所愚弄，也从未被操纵以迎合市场的方案。这个秘密的时间表总是被遵守，因为它反映了所有开发部成员之间的相互理解。当项目反映了这个现实时，程序会如期完成；当项目计划与此现实相矛盾时，程序会被延误。
- 有三种情况肯定会导致程序设计项目的失败。第一种情况是，主管此项目的经理对软件一无所知；第二种情况是，对程序代码负责的项目带头人对编写代码毫无兴趣；第三种情况是，编写代码的程序员是临时雇佣的，对项目缺乏忠诚。这三种情况中的任何一种都会导致项目的失败；三种情况同时出现，就必死无疑了。
- 一个程序的价值不能由它的宣传册的大小，或出现在大众计算机杂志上的整页广告的数量来判断。这些噪音越响，程序越不可能有用；真正优秀的程序不需要广告，用户会口口相伟。
- 一位初学者问大师：“程序设计的真正含义是什么？”
大师回答说：“饿的时侯就吃；困的时侯就睡；当时机恰当时，就进行程序设计。”
- 一位初学者问大师，“每当我在一套新的系统上编程时，必须学会一种新的语言。为什么没有一套标准呢？”大师转身而去。“唯一真正的标准是死亡。”他说“上个星期我准备劈些木柴烧火，但我的斧子又旧又钝。于是，我去五金店买了把新的。”“这挺有趣儿，”第一位程序员说，“但这和用户界面有什么关系呢？”“这把新斧子附带有一本长达八页的使用说明书。”他回答说。
- 不懂编程之道的程序员常常把空间和时间消耗殆尽，得道的程序员则总是有足够的空间和时间去完成编程任务。
- 上士闻道，从而行之。中士闻道，谨而寻之。下士闻道，大笑之。
- 有一位编程大师，他写非结构化的程序，一位初学者刻意模仿他，也写非结构化的程序。当他让大师看他的进步时，大师批评了他的非结构化程序：“ 对一位编程大师合适的东西未必对一个初学者同样合适，在超越结构化之前，你必须理解编程之道。”
- 一个项目经理带给编程大师一个项目的需求，然后问大师：“如果我给你5个程序员，要多少时间设计这个项目？”“一年”，大师说。“但是我们等不了那么长时间，越快越好，如果10程序员呢？”大师皱了一下眉头说：“那就要花2年”。“那，100年程序员呢？”大师耸了耸肩说：“那这个项目就永远完不成了。”
- 有人问一位程序员，“一个财务软件和一个操作系统哪个更容易设计？”“是操作系统”，这位程序员回答说。此人大惑不解。他说：“显然一个财务软件比起操作系统来说其复杂性是微不足道的”。程序员说：“不，设计财务软件时，一个程序员必须成为持不同意见的用户与计算机的一个中介，他必须了解用户的操作习惯，报表要是什么形式，如何遵循税法。相反，一个操作系统完全与这些外部的东西无关。设计操作系统，程序员只需要达到自己的设想与机器之间的简单的和谐。这就是为什么操作系统反而比财务软件更容易设计。”这些人笑着说。“不错，但是哪一个更容易调试呢？”程序员没有回答。写的好的程序是它自己的天堂，写的不好的程序是它自己的地狱。
- “技巧？”，大师转过身说，“我所遵循的是道–它超乎所有的技巧。当我开始编程时我看到的是整个一大块的程序，三年后我看到的是子过程。现在我什么也看不到了。我的整个存在是没有任何形式的虚无。我感觉很悠闲，总之，事实上是我的程序自己在写，有时我看到一些问题，我看到它们，就停下来静静地观察它们，然后我改变了一行代码，难题就象一阵轻烟一样化为乌有。然后我编译程序。坐在那里享受工作的喜悦。闭了一会眼睛然后退出系统。
-
一个好的农民不会不管他的庄稼。
一个好的老师不会不管哪怕是最差的学生。
一个好的父亲不会让他的任何一个孩子挨饿。
一个好的程序员不应拒绝维护他的程序。
-
为什么程序员没有效率，因为他们把时间都浪费在开会上了。
为什么程序员难于管理？因为管理者的干预太多了。
为什么程序员一个接一个地辞职，因为他们累坏了。
在糟糕的管理下工作，他们享受不到工作的乐趣。
-
经理对程序员说，“你们的工作时间是早上9点到正午点。”，所有的程序员都很不满。经理又说：“好吧，那随你们的便，只要能按时完成任务。”，程序员们这下满意了，他们中午上班，一直工作到凌晨。
Sphere: Related Content Filed In 学习路上 | Study | Tags: 软件工程 | Add a Comment »
Oct 29
Posted by eDWARD at 17:20
一个好的办法是每日构建（daily builds）。 每日构建意味着自动地，每天，完整地构建整个代码树、（译者按：“代码树”，原文为source tree，意思是将整个项目源代码的目录，子目录，文件的位置尽可能事先固定下来，这样在开发过程中各个模块间，各个文件间的相对位置都不会混乱。源代码树指的就是一个项目所有的已经组织好的代码文件。通常代码树应该用版本控制软件管理起来。虽然这个概念很基本，但是据我的观察，国内还是有软件公司在这方面做的不够好的，所以有必要解释一下。）
自动地 － 因为你设定代码每天在固定的时间构建。在Unix环境下使用cron，在windows下使用“任务计划”。
每天 － 或者更频繁. 当然每天构建的次数越多越好啦。但是有时候构建次数还是有上限的，原因和版本控制有关系，等会儿我会谈到的。
完整地 －很可能你的代码有多个版本。多语言版本，多操作系统版本，或者高端低端版本。每日构建（daily build）需要构建所有这些版本。并且每个文件都需要从头编译，而不是使用编译器的不完美的增量编译功能。
以下是每日构建（daily build）能带来的好处：
- 当一个bug被修正了，测试者可以很快得到最新的修正后的版本开始重新测试，以验证bug是否真正地被修复了。
- 开发人员可以更加确定他们对代码做的修改不会破坏1024个操作系统上的任何一个版本。验证这一点不需要在他们的机器上安装OS/2（IBM公司生产的PC机操作系统）。
- 那些每天将修改过的代码导入（check in）版本控制服务器的开发人员知道，他们对一个模块导入的修改不会拖别的开发人员的后腿。拖后腿的意思是，那些开发别的模块的程序员使用这个修改过的模块，出了问题，于是他们自己的模块也没有办法开发下去了。每日构建则不会有人拖后腿。如果把一个开发团队比作一台PC机，那么团队中的一个程序员对某个模块的修改导致其他人无法开发别的模块，相当于PC机发生了蓝屏。当一个程序员忘记把他（她）新建立的文件导入到repository（指版本控制服务器上的代码树）时，这种开发过程中的“蓝屏”会经常发生。因为在这个程序员自己的计算机上有这个文件，所以他（她）构建 这个程序没有问题。但是其他程序员是从版本控制服务器上导出（check out）代码的，由于服务器上没有这个文件，他们遇到了链接错误（link error），无法继续工作了。
- 外部团队（例如市场销售部门，进行beta测试的一些客户）可以获得一个比较稳定的版本，这样对他们开展自己的工作比较有利。
- 假如你将每日构建出的二进制文件（例如一个可执行程序，一个dll等等）存档管理，那么当你发现一个非常奇怪的，无法解决的bug时，你可以通过对这些文件进行二进制搜索（binary search）来确定什么时候这个bug第一次出现。如果有对代码进行了完善的版本控制，你也可以找出是谁在何时对代码进行的导入（check in）导致了这个bug。
- 当开发者修正了测试者报告的一个错误时，如果测试者同时报告了发现错误时的构建的版本，开发人员可以直接在那个版本中测试是否bug真正被修复了。（译者按：测试者报告出现了一个bug，只是报告了一个错误症状，而错误的原因可能有多个，每个原因可能在不同的模块中。前文中的方法是为了避免只修正了一个模块中一个原因，别的模块由于在变动，于是掩盖了而不是修复了bug）
以下是如何进行每日构建（daily build）的具体步骤。你需要用最快的电脑建立一个每日构建服务器。写一个脚本，可以自动从版本控制服务器中导出（check out）完整的代码，（你当然使用版本控制，不是吗？），然后对代码从头开始进行构建（build），要构建所有的版本。如果你有一个安装打包程序，也要在脚本中自动运行。所有会卖给最终用户的东西都要包括在构建过程中。把构建出来的版本放在各自的的目录里，不同时间构建的相同版本也应该按日期整理好，不要相互覆盖。每天固定的时间运行这样的脚本。
- 最关键的是所有这些步骤都应该由脚本自动化完成，从导出（check out）代码到将最终产品放在网上供用户下载（当然在开发阶段，产品是放在一台测试服务器上的）。要保证开发过程中的任何东西的任何记录是由文档记录的而不是由某个人的脑子来记录的，这是唯一的办法。否则你会碰到这样的情况，产品需要发布了，可是只有Shaniqua知道如何将产品打包的，可是他刚刚被巴士撞了。在Juno公司（本文作者工作过的公司之一），要进行每日构建，你唯一需要学会的东西就是双击每日构建服务器桌面上的一个快捷方式。
- 如果你在发行程序的当天发现了一个小bug，没有问题。修正它，然后重新运行每日构建脚本，现在你可以安安心心的发行程序了。当然，黄金定律是每日构建脚本应该是把所有的事情从头做一遍，遵循这个定律就不会有什么问题。
- 将你的编译器的警告参数设到最大（在微软的VC中是-W4 ; 在GCC中是-Wall），当遇到任何一个最微小的警告时就应该停下来。
- 如果每日构建失败了，可能整个开发团队的工作会因此进行不下去。当务之急是立刻找出原因，使得每日构建能成功进行下去。某天也许你会一天运行好几次每日构建脚本的。
- 每日构建一旦失败，应该自动地将失败用email通知整个团队。提取错误日志中的恰当部分并包括在email正文中也不是很难。每日构建脚本也可以将当前的状态报告整理成一个html文件，自动发布到一个所有人都可以访问的web服务器上，这样测试者可以很快知道那个版本的构建是成功的。
- 当我在微软的excel团队中工作时，我们的一个有效办法是，谁导致每日构建（daily build）失败，他（她）就得负责照看当日的每日构建（译者按：微软通常每日构建都在半夜），直到有另一个人导致构建失败而接替他（她）。这样做当然可以使每个开发者都小心不要因为自己代码的错误破坏了构建，更重要的是团队中的每个人都可以学会每日构建（daily build）的原理。
- 如果你的团队在同一个时区工作，在午饭时间进行每日构建（daily build）是个不错的主意。午饭前每个程序员导入（check in）代码，这样当程序员在吃饭时，构建系统在工作。当程序员吃完饭回来时，如果每日构建失败了，所有的人也都在，可以尽快找出失败的原因。当构建系统运作起来时，没有人再会担心别人导入（check in）代码会妨碍自己的工作了。.
- 如果你的团队同时在两个时区工作，计划好每日构建（daily build）的时间使得一个时区的工作不会影响另一个时区的工作。在Juno公司，纽约程序员在晚上7：00导入（check in）到版本控制服务器。如果他们的导入导致构建失败，印度Hyderabad市（译者按：印度科技重镇）的程序员在纽约时间晚上8：00以后的工作几乎无法进行下去。我们每天进行两次每日构建（daily build），每次构建的时间都在两地的程序员回家之前，这下就没有问题了。
Sphere: Related Content Filed In 学习路上 | Study | Tags: 软件工程 | Add a Comment »
