《梦断代码》的原文摘录
-
如果向程序员报告缺陷，他的第一反应是问你，“重现问题了吗？”——意思就是说，你能确实让问题再现一次吗？如果答案是肯定的，事情就成了一半。如果答案是否定的，程序员就会耸耸肩膀，将责任推给硬件故障或者宇宙射线。 (查看原文) —— 引自第254页 -
软件工程师、硬件工程师和部门经理驾车去瑞士开会。行驶到一处陡峭山路时，刹车突然失灵。汽车不受控制，一路侧滑下去，飞越过紧急缓冲障碍，奇迹般地蹭着山石停了下来。乘客们有惊无险， 不过面临一个问题：他们抛锚在半山上，汽车制动无效。该怎么办呢？ “我知道怎么办，”部门经理说，“先开个会，提出愿景（Vision），形成任务书（Mission Statement），定义一些目标（Goals），持续改进（Continuous Improvement）并找到严重问题（Critical Problems）的解决方案，这样就能上路了。” “不行，不行，”硬件工程师说，“太花时间了，而且，这种方法从来就行不通。我带了把瑞士军刀，转眼间就可以拆下汽车制动系统、分离故障并修好它，这样就能上路了。” “嗯，”软件工程师说，“动手开千之前，我想应该把车推回到山上，看看事故是否会重现。” 如果向程序员报告缺陷，他的第一反应是问你，“重现问题了吗？” 意思是说，你能确实让问题再现一次吗？如果答案是肯定的，事情就成了一半。如果答案是否定的，程序员就会耸耸肩膀，将责任推给硬件故障或者宇宙射线。 (查看原文) -
布鲁克斯法则：往已延误的项目中补充人力，只会使其继续延误 我也曾相信，最重要的软件......需要像建设教堂一般，由独立的巫师或者一队相互独立的魔法师精心打造，在面试之前绝不发布beta版本。李纳斯·托瓦茨的开发风格----早发布、多发布、全委托、尽开放----让我吃惊。这里不存在静穆、虔诚的教堂式开发----相反，Linux社群看似一个乱哄哄的大集市，铺陈了各种日程和手法......要从中得到前后一致和稳定的系统，简直只能指望奇迹再三出现。可事实上这种集市风格看来行之有效，真令人震惊 (查看原文) —— 引自第25页 -
2004年6月，《Linux时报（Linux Times）》发表了一篇对Linux”仁君“李纳斯·托瓦兹的采访。 “你对那些刚开始做大型开源项目的人有何建议？”记者问道。 “别做大项目，”托瓦兹要言作答。 “从小项目开始，而且永远不要期望它变大。 如果这么想，就会做过度设计，把它想象得过于重要。 更坏的情况是，你可能会被自己想象中的艰难工作所吓倒。 所以要从小处起步，着力考虑细节。 别去想大图景和好设计。如果项目没解决某些眼前的需求，多半就是被过度设计了。 “别指望在短时间内达到大成就，”他宣称， “我致力于Linux达13年之久，我想后面还得花上好些时间。如果一早就妄想做个大东西，可能现在还没动手呢。” (查看原文) —— 引自第159页 -
作为人： 我们是具体化的生物；肉体物是我们的基础，肉体性也以无数种不同方式定义了我们的存在。 我们与周围环境紧密相连；在经验形成的过程中，感知环境和与环境互动具有等同的认识的作用。 情感和认知同等基础，或更加基础；强烈和细微的感觉塑造了思维的封套。 我们是有意识的存在，既能外观亦能自省；精神人格和超越自我是我们能预于其中、也是我们所具有的境界。 (查看原文) —— 引自第1页 -
And so he formulated Brook's Law, which is both a principle and a paradox: "Adding manpower to a late software project makes it later." (查看原文) —— 引自第17页 -
如果程序员太过在意过往那些软件灾难留下的教训，就一行代码也写不下去。每次失败都如此类似，简直令人生寒。你唯有交叉十指，祈祷我们的老冰箱不会出毛病。 (查看原文) —— 引自第50页 -
好程序员懂得写什么，而卓越的程序员知道改写并复用什么。 (查看原文) —— 引自第56页 -
在软件项目管理中存在一种充满讽刺意味的天性,尽管程序员工作时使用的计算机和编程语言都要求精确缜密, 但软件编写工作却奇怪地对绩效考量有抵抗力.数十年以来,程序经理们尽力寻找一种准确的方法来测量该领域的生产力. 程序员每天的工作成果是代码, 而软件生产力最明显的量尺也是代码行.然而这量尺却不能让人满意, 有时甚至具有欺骗性. 在代码量和程序完成度, 质量以及对用户的价值之间, 并无可靠的关联关系. (查看原文) —— 引自第117页 -
没人为可怜的用户说话. 在这个问题上大家信守缄默的密约 ... ... 揭开表层掩饰, 你会发现人们羞于承认自己发现哪些设备难以使用. 它们意味错在自己 ...... 我认识的每个人美洲至少有那么一次想把那恼人的机器扔出窗去 ...... 软件缺乏可用性, 拙劣的程序设计, 这些都是计算机工业不足为外人道的耻辱. 应该做点什么呢? 计算机专业人员应该承担起创建良好用户体验的责任. 也许最重要的概念进步就是意识到在计算机产品中设计的紧迫性, 并将它与编程相提并论. 而在计算机业里最重要的社会进步则是为软件设计师留出位置, 鼓励对用户体验的关注. (查看原文) —— 引自第136页 -
有人问三个石匠他们在干什么工作,第一石匠答道 :＂我在谋生." 第二个一边干活一边说: "我在做全国最棒的石匠活." 第三个抬起头来, 眼里充满幻想的光芒, 说: "我在建造一座大教堂." (查看原文) —— 引自第145页 -
规格说明书是程序员的圣经, 而且, 通常程序员也会是忠诚信徒: 规格说明就是法律. 因其天性和职业需求, 程序员也缺乏想象力. 所以编写规格说明书就要十分当心: 像在童话故事里一般, 你要小心阐述自己想要的东西. (查看原文) —— 引自第168页 -
质量不应该是一种后悔药, 应该体现到生产过程的每一阶段. (查看原文) —— 引自第226页 -
没有物理学就很难有真正的工程,而软件中则没有什么物理可言. (查看原文) —— 引自第254页 -
小心上列代码中的缺陷, 我证明了代码的正确性,还没有试运行过呢. (查看原文) —— 引自第279页 -
电梯游说(elevator pitch) ---- 当你有幸在电梯间遇到某位权钱人士时, 能脱口而出, 在短时间内说服他 (查看原文) —— 引自第75页 -
要么和开源一起上天堂，要么和微软一起下地狱。 (查看原文) —— 引自第75页 -
愉悦是金，好的软件开发工作始于打造开发者本人 (查看原文) —— 引自章节：doomed -
文中第一条原则就是：“必须依序执行。决定推迟某些特性，项目才能成为项目。所有事同时开干并非明智之选。” (查看原文) —— 引自第132页 -
在软件项目管理中存在一种充满讽刺意味的天性，尽管程序员工作时所用的计算机和编程语言都要求精确缜密，但软件编写却奇怪地对绩效考量具有抵抗力。数十年以来，程序经理们尽力寻找一种准确的方法来测量该领域的生产力。程序员每天的工作成果时代码，而软件生产力最明显的量尺也是代码行。然而这量尺却不能令人满意，有时甚至具有欺骗性。诺波尔和毕多在研究可复用软件对象时发现，代码行各有不同。在代码量和程序完成度、质量以及对用户的价值之间，并无可靠的关联关系。 (查看原文) —— 引自第132页
作者: 罗森伯格
isbn: 7121135698
页数: 336
定价: 59.00元
出品方: 博文视点
装帧: 平装
出版年: 2011-6
原作名: Dreaming In Code
书名: 梦断代码
译者: 韩磊
出版社: 电子工业出版社