《构建之法》的原文摘录

  • 把所有的错误记在一个“我常犯的错误”表中,作为以后自我复审的第一步。 (查看原文)
    红色有角F叔 5回复 3赞 2014-10-12 20:03:41
    —— 引自章节:在代码复审后要做什么
  • 什么是好的软件?一些同学认为,所谓好软件,就是软件没有缺陷(Bug),所谓软件工程,就是把软件中的Bug都消灭掉的过程。这的确是抓住了软件工程的一个要素。和软件打交道的专业人士都知道软件有“Bug”(缺陷),软件团队的很多人都整天和Bug打交道,Bug的多少可以直接衡量一个软件的开发效率、用户满意度、可靠性和可维护性。 ——P15 很多人认为有Bug就是质量不合格,没有Bug就是质量完美,其实这也未必。我们在大街上看到很多小汽车,这些汽车出厂时都通过了各自的质量检测,符合行业的质量标准。但是你问路人哪些车的“质量好”,很多人会告诉你有些车的质量大大好于另外一些车,那为什么还有人买那些质量“不够好”的汽车呢?对于某些顾客来说,某一类的汽车满足了他们的需求,他们就会买。如果销售人员不经市场调研胡乱推销自己公司的汽车,最后销量未必理想。 市面上有这么多不完美的产品,软件团队为什么还要把这些不完美的软件发布出来呢?为什么不能等到它们完美之后再发布?**软件工程的一个重要任务,就是要决定一个软件在什么时候能“足够好”,可以发布。** ——P16 (查看原文)
    秦君 2回复 3赞 2018-09-09 20:35:23
    —— 引自第1页
  • 既然代码复审能发现这么多问题,有这么好的效果,如果我们每时每刻都在代码复审的状态,那不是很好么?事实上,极限编程(Extreme Programming)正是这一思想的体现——为什么不把一些卓有成效的开发方法用到极致(Extreme),让我们无时无刻地使用它们? ——p84页 极限编程对工程师提出了更高的要求。这种要求不关乎技术水平,也不关乎学历水平或工作经验。这种要求是对一个人的心智、道德修养的更高要求。结队编程中,编码不再是私人的工作,而是一种公开的“表演”。程序员的代码、工作方式、技术水平都变得公开和透明,这也许是一些人不喜欢这一方式的原因。 ——P87 (查看原文)
    秦君 2回复 3赞 2018-09-09 20:35:23
    —— 引自第1页
  • 计算机人工智能研究的一个重大挑战,就是计算机程序是否在国际象棋这个游戏中打败人类。从20世纪60年代开始,就有很多研究人员从理论和“智能”的角度去着手,取得了一定进栈,但是里最终胜利还是遥遥无期。1985年,还是一个研究生的徐峰雄这样想: “我们从一个不同的方向去逼近这个问题。我们,至少是我自己,把这个问题看成是一个纯粹的工程问题。” 历史证明,这个从工程的角度出发,用“蛮力”提高计算机速度的工程方法远远甩开了同时代的各种“智能”方案。1997年,徐峰雄带队设计的“深蓝”战胜了国际象棋大师加里·卡斯帕洛夫。 ——P13 (查看原文)
    秦君 2回复 3赞 2018-09-09 20:35:23
    —— 引自第1页
  • 用户体验设计的一个重要目的就是要降低用户的认知阻力(Cog-nitive Friction),即用户对于软件界面的认知(想象某事应该怎么做,想象某操作应该产生什么结果)和实际结果的差异。我们来看一个具体的例子,如果用户(一个生活在中国二线城市,有高中文化水平,有基本计算机基础的成年人)要在一个文稿中写居中的一句话,在下表所列的各种工具中,用户是怎么才能做到的。 倘若认知阻力大,学习曲线就会比较陡;但是经过学习和练习,如果用户适应了新的认知模式,工作效率便会有较大的提高。 ——P271 (查看原文)
    秦君 2回复 3赞 2018-09-09 20:35:23
    —— 引自第1页
  • 很多心理学家通过各种试验和分析告诉我们,纯粹强调外界的驱动因素(金钱的报酬或惩罚)仅仅对体力劳动或有明确规则的活动有效(奖金越多,结果越好),但对于需要创造性思维的活动,即使是简单的认知能力的活动,更多奖金反而起到相反的效果。 ——P409 (查看原文)
    秦君 2回复 3赞 2018-09-09 20:35:23
    —— 引自第1页
  • 一个成熟的软件工程师应该能够降低任务交付时间的标准方差。 软件领域可以分为两个方面:一方面是技艺创新的大爆发;而另一方面是坚持不懈的工程工作,包括软件的改善、维护和测试等,这一方面占了 90%~95% 的比例。 (查看原文)
    红色有角F叔 2014-10-12 18:01:16
    —— 引自章节:软件工程师的成长
  • "Natural critical learning environment." In that environment, people learn by confronting intriguing, beautiful, or important problems, authentic tasks that will challenge them to grapple with ideas, rethink their assumptions, and examine their mental models of reality. (查看原文)
    岁月如歌 1回复 1赞 2014-11-11 10:24:04
    —— 引自章节:构造怎样的学习环境
  • 1)软件构建:除了代码和静态数据,还有各种文件和数据来描述各个程序文件之间的依赖关系等; 2)源代码管理/配置管理:保证代码的平台兼容性、配置兼容性等; 3)质量保障(软件测试):保证软件的质量在修改过程中可以不断提高,或者至少可以保持; 4)项目管理:软件维护和服务运营 5)生命周期:以上称为软件的生命周期SLC (查看原文)
    司马欧阳 3回复 2017-05-03 15:14:44
    —— 引自章节:全书
  • public Class User() { public User(string userEmail) { memail = userEmail; } private string memail;//private变量拒绝外部类访问(除非用get/set方法) } (查看原文)
    司马欧阳 3回复 2017-05-03 15:14:44
    —— 引自章节:全书
  • 代码复审的目的在于找出代码的错误。因为越是项目后期发现的错误,修复的代价就越大——这也是learning by doing思想的体现。 (查看原文)
    司马欧阳 3回复 2017-05-03 15:14:44
    —— 引自章节:全书
  • 1.团队模式【我比较认可的】 主治医师模式 (查看原文)
    司马欧阳 3回复 2017-05-03 15:14:44
    —— 引自章节:全书
  • 社区模式 (查看原文)
    司马欧阳 3回复 2017-05-03 15:14:44
    —— 引自章节:全书
  • 响乐团模式交 (查看原文)
    司马欧阳 3回复 2017-05-03 15:14:44
    —— 引自章节:全书
  • 功能团队模式 (查看原文)
    司马欧阳 3回复 2017-05-03 15:14:44
    —— 引自章节:全书
  • 对于后来者,一个赶上的办法就是把别人的优势变成大路货(Commodity)。 (查看原文)
    红色有角F叔 2014-10-18 10:21:31
    —— 引自章节:IT 行业的创新
  • 牛人主导的项目,往往会大起大落。PM 主导的产品中,“不犯大错”成了一个特点,微软的很多产品在长期竞争中,靠“不犯大错”,从第三版开始,赶上并超越竞争对手。这也是了不起的能力。 (查看原文)
    红色有角F叔 2015-04-24 20:17:45
    —— 引自章节:项目经理
  • 解决道德冲突最好的方法是对基本原则进行全面的思考,而不是盲从某些具体的条目。 确保雇主和客户了解并同意你做的重要折衷,并让用户和公众能了解这些折衷。 对于任何形式的软件维护工作,要具备同开发新软件时一样的专业精神。 (查看原文)
    红色有角F叔 2015-08-15 13:58:47
    —— 引自章节:软件工程师的职业道德
  • 压力测试严格地说不属于效能测试,压力测试要验证的问题是: 软件在超过设计负载的情况下能否仍能返回正常结果,没有产生严重的副作用或崩溃。 (查看原文)
    红色有角F叔 2016-07-03 23:22:25
    —— 引自章节:压力测试
  • 我成为了一名职业程序员,但是我发现所有的算法别人都已经实现了,我只要调用就可以。似乎我们公司的软件与数据结构、算法的关系都不大。那我当初辛辛苦苦学习的数据结构和算法有用么?如何区分一个好的程序员和不好的程序员呢? (查看原文)
    GreyZeng 1回复 2017-07-11 20:25:26
    —— 引自第1页
<前页 1 2 3 后页>