Joel on Software

原文摘录   · · · · · ·  ( 全部 )

• 我觉得，人们所犯的一些最大错误（即使再体系结构的最高层）的根源在于，对处于最底层的几个简单事物理解不够或者一知半解。 编译器设计人员都知道的那样，语法分析与解释是在编译处理过程中最慢的部分。只要谈我们在解释、分析与建立抽象的内存语法树时，发现它涉及许多处理起来很慢的字符串素材，以及许多执行起来很慢的内存分配内容就够了。 所有这些事情都要求用户去思考字节，字节影响着用户在各个体系与策略方面做出决定。这就是我为什么坚持一种教学观点——大学一年级学生需要从基础学起，即用C语言以及从CPU开始向上逐步构建自己程序设计技能——的原因。 (查看原文)

  bluetingting 2012-07-06 13:52:53

• Joel测试 1.使用源代码控制机制吗 2.能一步完成连编吗 3.每天都做连编吗 4.有故障信息数据库吗 5.在编写新代码之前修复故障码 6.有最新的进度表吗 7.有规格说明书吗 8.程序员拥有安静的工作环境吗 9.你用到了你资金能力内可买到的最好工具吗 10.你有测试人员吗 11.新聘人员在试用期写代码吗 12.进行走廊可用性测试吗 一个可用的故障信息数据库必须至少为每个故障包含如下数据： 1.重现故障的完整步骤 2.预期功能 3.观察到的故障行为 4.要分配给谁 5.是否已修复 如果故障跟踪软件的复杂性是组织你跟踪故障的唯一因素，那么建立一个包含上述关键信息的五字段关系表，然后开始使用它。 一般来说，在修复故障之前等待的时间越长，付出的代价就越大。 立刻修复故障的理由： 1.花费时间较少。 2.预测要花多长时间去编写新代码要比预测要用多少时间去修复现有故障容易得多。因此修复了故障之后的进度表要比有很多故障的进度表靠谱。 写规格说明书好比是理乱麻：人人都认为是好事情，可就是没人去做。 熟练员工一旦做到“顺手”就工作得最好。这个时候，他们将全部精力集中在自己的工作上而置身于环境之外。他们忘记了时间，因为精力特别集中而焕发出很高的生产率。 问题在于，进入状态并不是件很容易做到的事情。人们平均起来似乎要经过15分钟才开始进入效率最高的状态。有时候，如果你比较劳累或者已经在当天做了很多创造性工作，那么你就不能进入最佳状态。剩下的工作时间里，所要做的事情就是把周围整理一下，上上网或玩玩。另一件麻烦事情是被干扰而退出兴奋点却非常容易。 (查看原文)

  bluetingting 2012-07-06 14:10:24

> 全部原文摘录