6月14日（本周日）晚19:30，人民邮电出版社异步社区诚邀业内人士，共享直播盛宴：**软件界传奇“Bob大叔”的回归本源之道：解码“整洁之道三部曲”的核心理念与价值，**届时进行3大主题分享+圆桌讨论。
“整洁之道”一直是值得程序员琢磨的技艺， 而Bob大叔用自己40多年的编程经历，在三部曲中总结出了对“整洁”的体会和建议。小编特意整理并分享出来，希望能对大家有所启发。
01
代码质量与其整洁度成正比
Bob在《代码整洁之道》提出一个观点——代码质量与其整洁度成正比。他认为在软件开发行业保持高效的秘诀，就是始终尽可能保持代码整洁。
在他的职业生涯中，曾被某人的糟糕的代码绊倒过，本来只需做一行修改，结果却涉及上百个模块，导致项目进度延缓严重。那时Bob开始思考一个问题——为什么会产生糟糕的代码呢？
是想快点儿完成吗？是要赶时间吗？有可能。或许你觉得自己要干好而所需的时间不够；假使花时间清理代码，老板就会大发雷霆。或许你只是不耐烦再搞这套程序，期望早点儿结束。或许你看了看自己承诺要做的其他事，意识到得赶紧弄完手上的东西，好接着做下一件工作。这种事程序员都干过。
我们都曾经瞟一眼自己亲手造成的混乱，决定弃之而不顾，走向新一天。我们都曾经看到自己的烂程序居然能运行，然后断言能运行的烂程序总比什么都没有强。我们都曾经说过有朝一日再回头清理。当然，在那些日子里，我们都没听过勒布朗（LeBlanc）法则：稍后等于永不（Later equals never.）。
Bob见过不少因为糟糕代码而关门大吉的公司，**混乱的代码会使生产力下降，**并最终让公司不堪重负。有些团队在项目初期进展迅速，但一两年后效率就变得慢如蜗行。当生产力下降时，管理层就只有一件事可做了：增加更多人手到项目中，期望提升生产力。可是新人并不熟悉系统的设计。他们搞不清楚什么样的修改符合设计意图，什么样的修改违背设计意图。而且，他们以及团队中的其他人都背负着提升生产力的可怕压力。于是，他们只会制造更多的混乱，驱动生产力向零那端不断下降。如图所示。
▲生产力vs时间
有时软件开发者会把问题归咎于那些愚蠢的经理、苛求的用户、没用的营销手段。我们抱怨需求变化背离了初期设计；哀叹进度太紧张，没法干好活。不过，这不能怪别人——是我们太不专业了。
假使你是位医生，病人请求你在给他做手术前别洗手，因为那会花太多时间，你会照办吗？本该是病人说了算；但医生却绝对应该拒绝遵从。为什么？因为医生比病人更了解疾病和感染的风险。医生如果按病人说的办，就是一种不专业的态度。
同理，程序员遵从不了解混乱风险的经理的意愿，是不专业的做法。经理和营销人员指望从我们这里得到必需的信息，然后才能做出承诺和保证；多数经理想要好代码，即便他们总是痴缠于进度；多数经理想要知道实情，即便他们看起来不喜欢实情。经理们奋力卫护进度和需求——那是他们该干的。你需要做的，是以同等的热情卫护代码。
所以，无论你是背负着期限的压力，还是你写的程序被上司的一个突发奇想而打回去修改。对你来说，赶上期限的唯一方法，也是做得快的唯一方法 ——就是始终尽可能保持代码整洁。这也是Bob大叔推崇整洁代码的初衷。
2009年，Bob大叔的《代码整洁之道》一经面世，就在软件开发行业引起了巨大的反响，整洁这一理念得到了数百万程序员的追捧。
02
程序员的两大核心职业素养
Bob把自己职业生涯里犯过的错都记录在《代码整洁之道：程序员的职业素养》里，他希望大家把这本书当成一份指引，绕开他曾经走过的弯路。
作为一个专业的程序员，除了要有担当责任的勇气，还要懂得何时说“不”。
Bob曾犯过这样一个错误——他把没有经过“夜间例行程序”测试的软件推出给了几十个客户，导致了客户数据丢失，公司的客户经理被电话轰炸。为了如期交付产品，他忽略了测试环节，整个过程中只考虑要如何保全自己的颜面，没顾及客户和雇主的声誉。
这件事让Bob明白了两个道理：一是专业的程序员要为自己的失误负责——如果你不小心放过了某个模块里的一个bug，以致公司损失了1万美元，那你将为那1万美元买单；二就是专业人士应该懂得说“不”，要敢于说明真相而不屈从于权势。
如果你的上司告诉你，“你在明天之前要完成那个登录页面”，你多半会这样回答，“噢，喔！要那么快啊？那好吧，我会尽量试试”。多么愉快而轻松的对话啊，而实际情况是，完成“登录页面”所需时间绝不止一天，你对此心知肚明。为了避免冲突，你撒了谎，或许你不觉得这是什么谎言，或许你觉得自己真的会去努力尝试，而且或许你真对按时完成抱着些微薄的希望。但到最后，这仍只会是个谎言。
而你的上司却不会这么理解，他会把“我会尽量试试”当作“好的，没问题”。然后在Deadline来临的时候，看着你做的失败的登录页面大发雷霆，而且他会承受比你更大的压力。
在Bob看来，程序员和雇主双方都应该具有专业性。你的上司要求你在明天之前完成登录页面，这就是他在追求和捍卫的一个目标，那是尽他的工作职责。如果你明知第二天之前不可能完成登录页面，嘴上却说“好的，我会试试的”，那么便是你失职了。这时候，尽职的唯一选择是说“不，这不可能”。
可是难道你不该照上司说的话去做吗？当然不该，你的上司指望的是，你能像他那样竭尽所能地捍卫自己的目标。可能的最好结果，是你和你的上司共同追求的目标。最关键的是要找到那个共同目标，而这往往有赖于协商。你们之间各表异议相互说“不”，然后找到了双方都能接受的解决方案。对话中必然会稍有冲突，也有片刻不愉快发生，但如果双方坚持追求的目标不能完美切合时，找到一个能应急的方案是比较理想的情况。
或许你觉得应该解释下为什么“登录页面”还要花那么长时间才能完成。Bob的经验是，“为什么”远不如“事实”重要。如果你的上司恰好有技术背景和好脾气去倾听理解，这些解释也许会有用。大多数情况则是，他可能会不认同你的结论。有时候，提供太多细节，只会招致更多的微观管理。
当我们承诺某事时，必须认真对待承诺。同样，当我们意识到某事不可能达到预期，也应当及时说“不行”。因为你的英雄主义，或者害怕“对抗”上司，导致的损失需要你有勇气承担。这是Bob大叔想告诉我们的——作为一个程序员该有的基本素养。
03
敏捷归来，正本清源
在距离敏捷宣言发布20个年头后，大家似乎遗忘了软件产品开发管理者应有的状态。而今，Bob大叔在《敏捷整洁之道：回归本源》中提出了“软件匠艺宣言”，给敏捷宣言加上了第五句——“匠心高于瞎写垃圾”( Craftsmanship over Crap)，而他的目的正是要为敏捷正本清源、清理门户。
自2001 年 2 月《敏捷宣言》诞生以来，Bob看到敏捷迅速席卷了整个软件行业，这是令他意想不到的事情。他低估了长久以来人们被“分析-设计-编程”这种瀑布式项目模式束缚已久的爆发力。以前，我们首先分析问题，然后设计解决方案，接着按照设计实现。简单、直接、明显，但却是错的。
《敏捷宣言》的中心思想：
个体和互动高于流程和工具；
可工作的软件高于详尽的文档；
客户合作高于合同谈判；
响应变化高于遵循计划。
敏捷改变了软件行业的思维模式，但是就如耳旁传话游戏那样，最初的敏捷思想被扭曲和简化，最终到公司里变成了承诺可以更快交付软件的一个流程。一些公司在敏捷转型上投入了几年时间与资源之后，才意识到：他们以前存在的问题如今仍然存在。当然，他们把责任全都推到敏捷头上。
大多数管理人员不理解软件项目的基本原理，质量、速度、成本、完成，这4个“铁十字”，你只能任选 3 个，没法 4 个全要，不是要求每一个属性都做到是 100%。
**敏捷只是一个框架，**它可以帮助开发人员和管理人员进行务实的项目管理。但是，这种管理不是自动的，并不能保证经理会做出恰当的决定。
随着对技术能力逐渐失去关注，敏捷是否还能给软件项目带来显著的改善？敏捷是否还像当初《敏捷宣言》中所言，聚焦于身体力行同时帮助他人探寻更好的软件开发方法？Bob大叔说，“我不是很确定。”
请不要把这本书当视为学术著作，最好将它视作一本回忆录——就像脾气暴躁的老年人满腹牢骚，让时尚新潮的敏捷小年轻们从他家的草坪上滚开。
——Bob大叔
有人认为，编程行业的新老更替开启了某种程度的黑暗时代。Bob却深明其中的原因——整整30年，大家一直受困于“用大团队干大事”的观念，根本不知道成功的秘诀其实在于用很多小团队解决很多小问题。而用小团队解决小问题，就需要每个程序员具备**“匠艺精神”**。
许多开发人员觉得匠艺和敏捷相互排斥，但本质上，两者都希望客户满意，都渴望紧密合作，并且都重视短的反馈循环。两者都希望交付高质量、有价值的工作，并且都要求专业性。为了获得业务敏捷性，公司不仅需要协作和迭代的流程，还需要良好的工程技能。敏捷与匠艺的结合是实现这一目标的完美方法。
匠艺提倡将软件开发作为一种职业。职业不同于工作。工作是我们要做的事情，但并不是我们自己的一部分。而职业则是我们的一部分，我们会对职业进行投资。我们希望在职业上不断精进。我们希望获得更多技能，并且拥有长久而充实的职业生涯。
敏捷要修复开发与业务之间的鸿沟。不幸的是，当项目经理涌入敏捷社区时，最初创建敏捷社区的开发人员感觉被剥夺了价值。
当越来越多的年轻程序员进入行业，大家对敏捷开发的理解可能与Bob当初的意图相去基远。现在，Bob大叔用《敏捷整洁之道：回归本源》给读者提供了一个历史的视角，使读者更完整、更准确地看清敏捷开发。就仿佛在对每一个年轻的程序员耳提面命——看看敏捷开发最初的样子吧！
▼▼▼
直播预告
6月14日（本周日）晚19:30，异步社区诚邀三位嘉宾共享直播盛宴：**软件界传奇“Bob大叔”的回归本源之道：解码“整洁之道三部曲”的核心理念与价值，**届时进行3大主题分享+圆桌讨论。
可以扫码下方二维码，提前获取直播信息！
▲长按图片识别二维码 了解详情