“软件工程”是个老话题了，我以前写过一篇文章《名不副实的“软件工程”》，当时还引起了不小的争议。回头看，当时更多的思考还是在“软件工程”本身。我们完全可以把讨论的范围扩得更大一些：“软件工程”和“工程”有关吗？如果有，到底有多大的关系？（这里的“软件”泛指IT的各种开发，不存在“软件”和“互联网”的分别。）
不要以为这些问题很好回答。在大学里，“计算机/软件开发”专业到底属于理科还是工科？似乎一直没有明确答案。到了社会上，一说起“计算机/软件”，很多人都觉得它既不同于文科，也不同于传统的“工程”（硬件）。
那么，“软件工程师”和“程序员”究竟有什么区别？似乎一直也没有人说清楚，只是名称不一样。就我所知，不少搞软件开发的人认为，软件是全新的领域，应当有全新的知识体系和工作范式，所以学校教育根本没啥用。甚至，有些人在内心看不上传统的工程人员，认为那都是“夕阳行业”的过时经验。
“软件工程”真的有这么特殊，可以大喊“我们不一样”吗？中国历史上有过“白马非马”的辩论，“软件工程”和“工程”之间也是这种关系吗？
下面结合软件工程，讲几个“传统”工程的故事。如果你也好奇“软件工程”和“工程”的关系，相信可以得到启发。
工程与理论
在软件开发的行业，大家争论不休的问题之一是：数学对于软件工程师到底重要还是不重要。或者更泛化一点：数学、算法、计算机体系结构等理论知识，对于软件工程师到底重要还是不重要。
许多人的答案是“不重要”，并且有现身说法：你看我，工作这么多年，学校学的东西早都忘记了，我不是一样在写代码，交付各种业务功能吗？没有理论，并不影响我工作。
说“重要”的也有许多人（我也在内）。理由是：软件虽“软”，背后却是有严密的逻辑体系做支撑的。如果凡事都要靠经验、靠试验去得到结论，那么成本未免也太高了。
这里不争论这个问题，我们看看土木工程的故事。
1742年，教皇本尼迪克特十四世（Benedict XIV）需要派人诊断罗马圣彼得大教堂拱顶出现的裂纹。传统上，这种事情总是要找建造经验最丰富的工匠。但是这次不一样，教皇把任务指派给了三位数学家，其中一位还曾编辑和注释过伊萨克·牛顿的《自然哲学的数学原理》。
在那个年代，三位数学家的诊断方法和结论都引发了巨大的争议，因为这违背了无数工匠的经验和直觉，他们都积累了丰富的建筑经验。按照三位数学家的结论，拱顶的箍环承受不了水平的推力，必须新增三个带链条和铁钉的铁环，才能确保建筑的完整。
最终，三位数学家的建议被采纳了。今天如果你去罗马，仍然可以看到完整的圣彼得大教堂。
土木工程师兼历史学家斯特劳布评论说：这份报告在土木工程史上有划时代的意义……重要性在于，与所有的传统和常规相反。从此，所有人都明白了，对建筑结构的稳定性的勘测，不应该建立在经验规则和静态感觉的基础之上，而是应当基于科学的分析和研究。
从此大家也相信，建筑不再是一门“手艺”，要想建造更复杂、更伟大的建筑，谁也离不开科学和研究。今天，如果土木工程师开展工作不依照模型、理论、计算，而是完全按照经验和直觉，哪怕他的经验再丰富，也不能称为“工程师”。
工程与规模
在软件开发行业，“规模”其实是绕不过去的话题。
今天仍然有许多工程师，对“工业开发”的理解就是“改改网络上现成的示例代码”，以及“写一段在本地运行没有问题”的代码。软件开发人员跟人吵架时有句著名的托词：“你看，在我这是好的”，这可以算是背后的心理根源。
实际上，“在本地运行，实现指定功能，得到正确结果”的代码很容易。同样的功能，要在成千上万台服务器上运行，每天运行成千上万遍，挑战就截然不同。这种挑战极富技术含量，值得特别重视。
不信的话，让我们换个角度，看看化学工程的故事。
19世纪直到20世纪早期，德国的化学工业都是相当发达的，远远领先世界各国。这是化学工业的早期，在这个阶段，把化学反应从实验室按比例扩大到工业生产的工作，是由与机械工程师合作的化学家完成的。对德国人来说，这种合作方式相当满意，部分原因在于，他们精通复杂产品。这些复杂、专业、高价值的产品，需要复杂的化学知识，而不是科学技术。用途也限于高价值领域，所以规模并不是问题。
据统计，德国1913年一共生产了13.7万吨染料，涵盖上千个品种，其相对高昂的价格能够带来足够的收益，足够让德国的化工企业维持运转。
作为对比，在同一年，美国仅硫酸就生产了225万吨。美国的化学工业，考虑更多的不是如何精工细作，而是如何利用已有的化学知识，借助更多的工程技术，按比例扩大到巨大的生产规模。
于是，工业化学家诞生了。他们不是把每种生产看成一套单元，而是将其解析为多个构成部分，并根据其效用概括出一般结论。许多具体的操作，例如增压和蒸馏，并不属于严格意义上的化学领域，也受到了当时一些“化学家”的鄙视。但是，化学工程师对此毫不在乎，坚持认为这些问题值得科学家关注，因为这些单元操作是化学反应从实验室规模跃升到工业水平的主要难关。从中暴露出来的各种问题，恰恰是化学工业需要面对和重视的。
1923年，沃克、刘易斯、麦克亚当斯在《化学工程学原理》中写道：所有重要的单元操作都有许多共通之处，如果领会了理性设计和操作基本类型的工程设备所取决的内在原理，那么它们能成功应用于制造工业流程，就不再是碰运气的事情了。
培养工业化学家、发展化学工程学、追求规模的结果是，美国的化学工业迎头赶上，甚至超过了德国。今天，众多国际知名的化工和制药企业都位于美国。
工程与用户
软件工程师和用户之间的矛盾，能引发经久不息的讨论。
矛盾的场景往往大同小异：软件工程师抱怨用户智商太低、知识太少、脑子转得慢、看不懂说明书，所以玩不转高科技的系统；用户抱怨软件工程师不说人话，做出来的系统不人性化，不符合直觉。
其它行业的工程师也会遇到这样的问题吗？他们是如何解决的？我们看看船舶工程的故事。
人类很早就发明了用来掌控船舶前进方向的船舵。哪怕是没有操船经验的人，也很容易感觉到船舵的操作和船舶前进方向之间的关系。稍微加以训练，就可以基本掌握船舵的操作，保持船舶前进的稳定性。
但是在蒸汽船兴起之后，麻烦出现了。对于排水量达到几千吨的船只，靠手工转动船舵已经难以为继，当时的军舰在全速行驶时，仅仅转动扳动船舵就需要上百人。借助蒸汽的力量转动船舵当然是很容易的事情，但仅仅机械地“转动船舵”是不够的，因为蒸汽不懂得舵手的意志，舵手也没法获得直观的反馈，精确船舶前进方向就成为空谈。
船舶工程师们不能抱怨舵手“不懂技术、跟不上时代”，强迫他们“必须学习”，而是必须想出办法，让船舵能够聪明、灵敏地响应舵手的操作，不能机械死板地摆动。
1866年，苏格兰工程师麦克法兰·格雷（J. Macfarlane Gray）发明了具有反馈控制功能的操舵引擎（Steering Engine，今天叫“舵机”）并获得了专利。这种发动机率先安装在排水量18915吨的Great Eastern号上，其控制机械能精确跟踪、匹配舵轮的变化，根据船舵的反馈持续修正。有了舵机，舵手才能真正操控船舵，准确把握船只的前进方向。
这种大获成功的自动控制器被称做“伺服机构”（servo mechanism），其名称源自拉丁文servo，意思是“奴隶”或者“仆人”，它不只是机械执行操作者的意志，而是可以形成闭环，根据实际情况不断反馈修正，确保实现使用者设定的目标。今天，伺服机构已经被广泛应用于各种设备。今天的每一台数码相机上，你都可以找到“伺服”对焦模式。
工程与生产
我不知道有多少软件工程师真正去过生产线，但我记得我第一次去到生产车间的感受。
面对着生产线、工位、SOP、物料管理……，我感到震撼。以前我总觉得软件开发复杂，但现实的生产一点也不比软件开发简单。尤其是看到自己开发的软件被一线用户真正实用的时候，之前的各种不理解、委屈、抱怨，似乎全都泄了气。从此我深刻理解了，“深入生产一线”到底是什么，它有什么用。
其实不只对软件工程，对任何高科技工程来说，“深入生产一线”的重要性，怎么强调都不为过。作为例子，我们可以看看航空工程中的故事。
在航空业大名鼎鼎的“臭鼬工厂”（Skunkworks）是洛克希德公司高级开发项目的官方绰号，由著名飞机设计师克里·约翰逊（Kelly Johnson）创立于1943年。臭鼬工厂以担任秘密研制任务著称，先后研制了升限2.4万米的U-2高空侦察机、空速3马赫的SR-71侦察机、史上第一架隐身轰炸机F-117等著名飞机。
臭鼬工厂研制出这么多了不起的飞机，当然聚集了一批了不起的工程师。这些工程师是不是”关起门来攻关“呢？不是。按照约翰逊的规定，工程师在设计过程中，每一个步骤都必须经过反复的商讨和推敲。一旦工作中遇到问题，他们需要与试飞员、机械车间工人、管理人员紧密合作，共通面对。
约翰逊还为臭鼬工厂设定了若干基本规则，其中有两条是：第一，工程师应当守候与机械车间不应当超过“扔石头能打到的距离”；第二，“坏消息传到高层的速度必须和好消息一样快”。在实际工作中，这两条规则执行得相当好，设计工程师每天上班至少要花1/3的时间在生产车间待命。
不同职能、不同团队的紧密协作，呈现出强有力的团队面貌和高度激励精神，也形成了多学科、系统化的工作方法，将行政管理上的官僚作风减少到最低限度。员工不会在移交工作之后推卸责任，而是在移交之前拼尽全力。
这样工作的结果不难想见，突出的例子是F-117。“臭鼬工厂”的F-117隐身轰炸机因为造型太过怪异，一度被行业人士判断”飞不起来“，事实证明，F-117的性能完全满足设计需求。
工程与成本
有多少软件工程师会考虑成本问题？似乎相当部分的软件工程师没什么成本意识。
相当多的软件工程师在乎的是，写下代码，用代码去实现功能。如果说成本，可能最先想到的是人工成本，也就是写代码的时间。至于其它方面的成本，比如运行的资源消耗、维护的难易程度，愿意考虑的人并不多。
作为对比，在传统工程领域，合格的”工程师“大都明白，工程和科学之间的差别。科学问的是”是什么“和”为什么“，工程问的是”为了什么“、”怎样实现“、”评价好坏的标准是什么“。正因为这三个问题对工程相当重要，合格的工程师一定清楚意识到，在实现目标价值的情况下，成本越低越好。航天工程的例子，正可以作为注解。
20世纪60年代，美国政府在航天领域持续投入巨资，先后进行了”水星“、”双子星“、”阿波罗“计划，将人类送上月球。然而，即便是有天量投入为支撑，航天工程中仍然要时时秉承”节约“的原则。
在阿波罗登月计划中，指令舱隔热罩的材料遇到了巨大挑战。在太空中，它朝向太阳的一面炽热，背向太阳的一面极冷，重返大气层时还需要经受极高温的考验。如何设计才能解决这个问题，工程师陷入了深深的思索。
最终，工程师们没有发明某种特异的复杂材料，而是让指令舱每小时绕自转轴旋转一周。在登月往返中，指令舱始终保持这种”翻转烤肉“的模式，利用太阳的热量有规律地烘烤，所以再不用考虑低温的考验。
尽管航天工程花费巨大，这种”节约成本“的例子却比比皆是。2003年”哥伦比亚“号航天飞机在返航中失事，事后确认原因是：发射升空过程中，脱落的隔热瓦撞破了飞机机翼，在重返大气层过程中，炽热的气体灌入飞机内部，最终导致解体。
怎样发现机身的破损？工程师的办法并不是给航天飞机全身装上破损检测传感器，而是在返航之前新增一项检查：航天飞机在返航之前，必须在太空做360度转体，由太空望远镜或空间站观测，确认机身没有破损。
工程与人
“软件工程师”对普通人来说，是怎样的形象？
看看周围的媒体就知道，“软件工程师”（或者叫“程序员”）已经形成了相对固定的刻板印象：木讷、无趣、不善交际、缺乏趣味。软件工程师似乎默认了这种印象，在自己的亚文化圈子中寻找共鸣。
这种现象，是软件工程师独有的吗？看看工程学的发展就会清楚，“吾道不孤”。
今天的许多人，无论怎么看工程师，至少都会归类到“有知识的人”里。但是在历史上，“知识”很长时间里等同于文学、历史、艺术，与今天大家所说的“知识”有很大不同。
所以，工程师的先驱者们大多都是自学成才的。他们大多来自社会底层，出身学徒，凭借好奇心和兴趣，孜孜不倦地学习，从“工匠”升华为“工程师”。制造了蒸汽机车的斯蒂芬森是这样，建造了埃迪斯通灯塔的斯米顿是这样，爱迪生也是这样。
因为出身底层，难入上层阶级法眼，又清楚学习交流对于促进理解、启发灵感的作用，工程师们只能自己创建职业协会。英国土木工程师协会成立于1771年，机械工程师协会成立于1846年，德国也在1856年成立了自己的工程师协会，带动德国综合技术学校率先上升到大学地位。
行业协会的兴起，逐步产生了“工程”专门教育的需求。于是，理工科大学也诞生了。突出的例子就是1794年成立的巴黎综合工科学校，不仅在工程技术上，而且在一般科学上都是教育突破。在这里，最优秀的科学家、工程师教授聪明的年轻人各种工程知识。拿破仑甚至希望，在遇到重大危机的紧要关头，也不要让学生卷入战斗，因为这是“下金蛋的鹅”。
工程技术的飞速发展，重要性不断提升，改变了普通人的生活，也打破了社会原有的格局。作为回应，原有的“轻视”变成了敌视。工程师们，大概只有两种形象：一种是科学怪人弗兰肯斯坦，一种是书呆子、极客。他们不懂高雅艺术、不懂审美、没有情趣、缺乏交流……
这种印象能站得住脚吗？起码工程师们是不赞成的。麻省理工学院工学院创始人威廉·罗杰斯（James Henry Williams, Jr.）在创建新学院的建议中说：
我们提供的教育，虽然就其目的而言价值非凡，但与那种只按经验惯例进行的教育没什么关系；而经验惯例式的教育，有时被吹嘘为对要从事实业来说最合适的教育。相反，我们认为，大多数真正实用的教育，即便按照实业的观点，也是一种建立在透彻的科学定律与原理的知识基础上的，而且是一种将缜密观察、精确推理结合起来的教育，是一种全面的综合素养。
不只麻省理工学院，已经有越来越多的工程师意识到，工程绝不是冷冰冰的、机械的产物，它一脚踩在科学领地，一脚踏进社会万象。过分强调一条腿，忽略另一条腿，都是非常危险的。
其实，古代的工匠就已经懂得这个道理，充分懂得并重视人的因素。
古希腊建筑大师卡里克拉特要小心翼翼地挑选雅典城墙的承建者，因为他知道城墙的建筑并不是简单机械的劳动。这个故事给普鲁塔克留下了深刻的印象，在《希腊罗马名人传》里专门记载。写下不朽的《建筑十书》的古罗马建筑大师维特鲁威更是明确说，建筑师如果要正确设计建造屋檐和下水道，就必须熟悉城市制定的各种法律法规，懂得并且重视和商界、政界打交道。
现代的优秀工程师也不会忘记这点。普林斯顿大学航天工程毕业，先后在道格拉斯飞机公司担任研究工程师、总工程师，之后任洛克希德·马丁公司CEO的诺曼·奥古斯汀（Norman R. Augustine）曾经说过一句话，得到了众多工程师的认同：合格的工程师，必须能像处理重力和磁力那样熟练处理社会的和政治的力量。
我知道不少软件工程师都喜欢称自己为“手艺人”，都喜欢讲“三个石匠“的故事——同样在干活，“混饭吃”的石匠一生都在混饭吃，“想做最好石匠”的石匠大概获得了点名声，“造大教堂“的石匠最终功成名就。
我以前也喜欢讲这个故事，很动听，但也很给人安慰。后来我终于发现，这个故事的问题就在于，它太简单了：从来没有人告诉过第三个石匠，要想造大教堂，可不能专心当石匠，你还得学习很多其它的技能，比如画图、计算、选材、算账、砍价、了解天气和气候、排生产计划、检查质量、化解冲突……
From Life Sailor, post 软件工程，“我们不一样”？
注：原文发布于2023年1月16日 到1月份为止，我已经体验了几个月的全远程+共享空间办公了。有不少朋友听说之后很有兴趣，问我到底是什么感觉，所以我简单介绍下个人的体验。 背景 2019年末、2020年初开始在全球流行的Covid-19对远程办公来说，绝对是黑天鹅一般的存在。因为疫情导致的社交隔离措施，极大影响了各大公司的正常运转。 所幸，IT类公司受到的影响比较小，只要求员工“面对屏幕编程”，不必亲临现场。所以，许多IT公司也谨小慎微地开展了远程办公的试验。 从我所知道的结果来看，不少美国公司并不特别喜欢远程办公，比如Google，一旦社交隔离措施有所放松，就忙不迭要求员工回到办公室，盖因为公司认为远程办公严重影响合作效率。 与此相反，不少德国公司反倒是逐渐适应了远程办公的节奏，纷纷降低对员工“到办公室上班”的要求，许多公司甚至可以支持百分百的远程办公。 这里要提到的是，德国公司说的“远程办公”往往是货真价实的“远程”，而不是一些人理解的“家和办公室在同一个城市，只是不用去办公室”而已。 因为德国IT行业缺人严重，而且许多德国公司并没有那么“互联网”，而是依托实业开展业务，所以据我所知，目前不少公司非但没有裁员，反而都在大力招人。 (more…)
注：本文发布于2023年2月6日 最近硅谷几大公司都在裁员，看了些报道，被裁的员工真是不好过。损失经济来源不说，有些人还面临身份问题，这可真是屋漏偏逢连夜雨。 我也留意到，不少被裁的人会不停追问自己：为什么我会遇到这样的事情？为什么这样的不幸会降临到我头上？…… 实话说，我挺能理解这种态度。这挫折如此巨大，似乎又来得全无预兆，不由得让人对命运、对人生、对世界产生深重的怀疑。尤其是对已经走入社会，取得一定成就（如果非要抠字眼，那就用“进展”吧）的人来说，更是如此。 但是我更想说，如果被裁员了，当务之急是赶紧找到下一份工作，哪怕只是机械地行动。要知道，成年人找工作，容不下那么多愁善感。 我之所以这么说，是有切身经历为基础的。之前我讲过找德国工作的经历。最开始是信心十足的，因为虽然毕业多年，手艺没丢，基础还在，随时打开leetcode，中等难度题目基本都不在话下，不但能解对，解法也基本接近最优。既然网上都说“刷题就能找到工作”，估计自己应该没大问题。 没想到真的找起工作来，仍然充满了意想不到的挫折。如果不相信，我且举几个例子吧。 (more…)
虽然早就听说《园丁与木匠》是关于育儿的好书，但一直没开始读。最近终于翻开这本书，才发现属于“拿起就很难放下”的类型，加班加点读完，收获不少。 关于这本书的价值，已经有许多书评讨论过了，所以我想略过微言大义、长篇大论的叙述，谈谈我印象最深，也是最打动我的三点细节。 第一，儿童的学习方式 小孩子觉得拧螺丝很好玩，想自己动手拧一颗螺丝。于是，他打开了工具箱，对着琳琅满目的工具，他不知所措。一会儿摸摸钳子，一会儿试试扳手……这时候，旁边的父母应当怎么办？ 在大多数情况下，父母大概会直接告诉孩子，“亲爱的，你应该用螺丝刀，来，我告诉你”。耐心一点的父母，大概会潜心观察一段孩子的举动，再设法“引导”他到正确的工具上来。在父母眼里，孩子当然不可能一开始就找对正确答案，所以做各种尝试也是情有可原。但是另一方面，也不应该“在错误的路径上摸索太久，浪费时间”，应当“迅速识别出正确的答案”。 无论父母有多少耐心，在他们眼里，孩子找到拧螺丝的工具的过程，都是个“不断接近正确答案”的过程。这个过程越短，孩子就越“聪明”，或者说“学习效率”就越高。 (more…)
陈皓（Haoel，网名“左耳朵耗子”）上周六因为突发心梗去世了，享年47岁。 我跟他虽然聊过好些次，但只是微信好友，从未见过面。回看微信记录，当年稀松平常的一声“再见”，已经成了“再也不见”。 许多人在缅怀他，许多文章提到他的时候，会用到“骨灰级程序员”、“技术大牛”这样的称呼。但如果仅仅用这两个词描述他，断然难以解释，为什么他的突然去世，会引发互联网上怀念的狂潮。 所以，我更愿意按照自己的经验，把他描绘为“有坦诚追求，兼具趣味、操守、胸怀的技术人”。恰恰是因为这样的人在这个年代太稀少，而这些品质又让众多人赏识和受益，大家才会如此地怀念他。 这个年代，做技术（仅指狭义的IT）的人很多，愿意分享的人也不在少数，其中不少还可以算世俗意义上的“成功者”。 但是，若仔细去看他们分享的内容，总感觉不够真诚。总感觉作者希望往高深了靠，目的也没有那么纯粹。你若提一些小白问题，迎来的往往是“你怎么连这都不知道？”的反问，或者“要谈这个问题，你先去看几本书再说吧”。话是这么说没错，但无数的初学者也往往因此打了退堂鼓。 但是陈皓的分享不同。我已经不止一次地看到有人提起，他分享——更准确说，是“创作”——的内容质量很高，而且总能做到“深入浅出”。哪怕是小白读者，看完也确实能有收获，如果还有兴趣，更可以跟着文末的链接，顺藤摸瓜探究更广阔的世界。 这让我想起我佩服的一位记者说的：记者写文章的最高境界，就是不表达自己的观点，因为记者的观点应当来自于他的素材。只要把这些素材摆出来，读者读完报道，观点就自然形成了。要做到这一点，需要对素材有足够的信心和把握，外加真诚和坦荡。 能做到这一点的记者，着实不多。陈皓虽然不是记者，他写的技术文章却能让读者得到类似的结论——要知道，技术讨论往往是非常容易擦枪走火的——可见他运用素材和逻辑的功力，以及更重要的，他的真诚和坦荡。 (more…)
2022年我接手了一本技术图书的翻译，拖拖拉拉到现在，也快截稿了，现在能做的，就是反复审阅，查漏补缺。 但是，有个问题一直困扰着我，始终得不到解决，那就是“姑妈-姨妈”问题。 书的最前面有某业界大牛写的“丛书编辑前言”，里面提到my grandson is learning from his aunt, my youngest daughter。众所周知，英文里亲戚的称呼远比中文简单，grandson既可以指孙子，又可以指外孙，aunt既可以指姑妈，也可以指姨妈。 所以从逻辑分析，grandson可能是“孙子”也可能是“外孙”，那么my daughter对他来说既可能是“姨妈”也可能是“姑妈”，因为文中再没有相关的信息，任凭你分析，也不知道哪种组合才是对的。 因为之前一直忙着处理正文，这个问题一拖再拖。眼看要交稿了，没办法，我才给作者发电子邮件。对方是业界大牛，这个问题又如此的“细枝末节”，那么他会不会回复，有没有耐心回复，我完全不知道。…
注：原文发布于2023年12月22日。 上一篇文章（坚持了两年之后，小朋友突然不想去打冰球了…）发出来之后，出乎意料阅读量竟然创了近期新高，也收到了不少反馈，看来育儿确实是如今许多人关心的话题。 在我收到的留言中，有好几条都提到，小朋友“选择要学的东西之前应当谨慎认真，一旦自己做了决定，那么再苦再累也要坚持”，万万不能“半途而废”。这个说法我非常熟悉，“半途而废”这四个字更是深深触动了我。确实，我反复想过，也和家里领导讨论过这个问题：身为家长，你能接受孩子“半途而废”吗？ 答案当然是“不能”。 我写过自己小时候学手风琴的故事。那时候也有很多泪水、挣扎、反抗，每次闹到不可开交，我父亲就一本正经地说：“这是你自己选的，当时问你要不要学，你说要学，既然说了就必须做到……” 然而我还是没有能坚持下来，学了十年之后终于以“学习更重要”为理由自我解脱了。 等到再捡起来，已经是自己成为父亲之后。有更多时间练琴，更是到了欧洲之后的奢侈享受。虽然现在周围人都反馈我弹得还可以，也因此交到了不少朋友，但内心仍然有遗憾，一些很想弹的曲子，因为对我来说太难，实在是举步维艰。 如果当时没有半途而废，该是多好的一回事啊。 (more…)