本书给你描绘了一个务实的程序员应该是什么样的。你只需要按照书中的方式进行修炼即可。很多人觉得这本书难啃，因为里面太多行业术语，但难啃意味着如果啃下来，好处也是巨大的。说说我心目中务实程序员的特征：首先，在面对问题上，务实的程序员会越过问题的表面，基于整体来分析，找到问题背后的原因。如果你不了解需求的目的，你也不会知道为什么当初会这样做。更不知道如何来解决问题。其次，就是对自己做的事情负责，一件事情出问题，可能有多种原因。以我们开发中最常见的上线延期为例，延期了是谁的问题？肯定有多方面问题，需求时间评估不足、需求理解错误、需求有变更、其他人的计划延期以及一些意外情况等等。但细想一下，哪些问题是你能做好却没做好的？我们要直面问题，才能解决问题。最后，就是要多学习，你需要大量的基础知识和经验，才可能实现以上这些。很多程序员是有完美情结的，但记住一句话，完成好过完美。我们只能在有限资源里完成某个任务，永远达不到完美。但我们每一次迭代都是在接近完美。

这本书有可能颠覆你的技术生涯

如果不是程序员这本书不必读，因为编程这一行发展太快，可以说日新月异，我 40 年前开始编程，从打孔机开始应该经历了计算机发展的整个过程。原本翻译的书就很难流畅，再加上夹杂一些代码，找人生哲理也不必在这本书里找，如果是程序员为了怀旧，感慨，教学老师可以当闲书翻翻多些谈资，编程慢慢也如同数学进入通识教育范畴，编程建立在科学基础上的逻辑推导，有编程思维不会相信怪力乱神，相信双盲实验，相信结果和错误都可复现，相信小步迭代，相信大处着眼小处着手，相信人工智能只是个工具。本书没有开创性的思路，程序员还是勤劳的工蜂。

我们这些开发者，拥有令人难以置信的特权 —— 我们真正在建设未来，这是一股巨大的力量。伴随着这种力量而来的，是一种非同寻常的责任。我们隔多久会停下来思考这个问题？对于这一责任究竟意味着什么，我们在自己人之间，以及和更广泛的读者一起，隔多久会讨论一次？比起笔记本电脑、台式机和数据中心，嵌入式设备用到的计算机要多一个数量级。这些嵌入式计算机通常控制着生命攸关的系统，从发电厂到汽车再到医疗设备。即使是简单的中央供暖控制系统或家用电器，如果设计或实施不当，也会致人死亡。当你为这些设备做开发时，所承担的责任是很惊人的。许多非嵌入式系统同时具备好的一面和坏的一面。社交媒体可以促进和平改革，也能煽动丑陋的仇恨。大数据可以让购物变得更容易，也可以摧毁任何你认为该自己保有的隐私。银行系统做出的贷款决策，足以改变人们的生活。几乎任何系统都可以用来窥探用户。我们已经隐约看到乌托邦未来的可能性，也见过不少例子中反乌托邦噩梦般的意外后果。这两种结果之间的差异可能比想象的更微妙。但一切都在你的手中。道德罗盘这种意想不到的力量，并非没有代价，它会让你提心吊胆。我们的行为直接影响着全人类。不再是车库里 8 位 CPU 上的业余程序，也不再是数据中心主机上孤立的批量业务流程，甚至不再只是桌面 PC—— 我们的软件已渗透到当今日常生活的方方面面。对于我们交付的每一段代码，我们有义务问自己两个问题：1. 我已经保护好用户了吗？2. 我自己会用它吗？首先，你应该问的是 “我是否已经尽了最大努力来保护这段代码的用户免受伤害？” 也就是问自己 —— 是否已经做好准备，不断把安全补丁应用到那个简单的婴儿监视器上；是否已经确保，即使中央自动加热恒温器失效，客户仍然可以手动控制；是否只保存了需要的数据，并加密了所有个人信息。人无完人，每个人都会时不时地忘记一些事情。但如果你不能满怀信心地声明自己已尽力列出所有后果，并确信能保护用户不受其影响，那么当事情变糟时，就难辞其咎。

重点整理：1. 李小龙：活着不是为了满足你的期望，正如你也不是因为我的期望而活着 2. 给出选择，而不是找借口。不要说搞不定；解释一下要做些什么才能挽回这个局面 3. 一扇破窗：一段设计糟糕的代码，一个让团队在整个项目周期内都必须要遵守的糟糕管理决定，一就是一切衰退的开始 4. 你做的东西，从用户需求角度来说是否足够好？最好还是留给用户一个机会，让他们能亲自参与评判 5. 对知识组合做定期投资：每年学习一门新语言每月读一本技术书读非技术书上课加入本地的用户组和交流群尝试不同的环境 6. 几个值得思考的问题：问 "五个为什么" 谁从中受益有什么背景什么时候在哪里可以工作起来为什么这是个问题 7. 英语就是另一门编程语言 8. 能适应使用者的就是好的设计。对代码而言，就是要顺应变化，信奉 ETC 原则（Easier To Change）9. 在一个系统中，每一处知识都必须单一、明确、权威地表达 10. 可以用一个简单的方法来测试设计的正交性。当你规划好组件后，问问自己：如一个特别功能背后的需求发生显著改变，有多少模块会受影响？对于一个正交系统，答案应该是 "一个"11. 三种技术可以用来保持正交性：保持代码解耦避免全局数据避免相似的函数 12. 埃米尔 - 奥古斯特・沙尔捷：如果某个想法是你唯一的想法，那就没有比它更危险的东西了 13. 路德维希・维特根斯坦：语言之界限，即是一个人世界之界限 14. 通过估算来避免意外：持续时间 1 - 15 天：采用的估算单位 - 天持续时间 3 - 6 周：采用的估算单位 - 周持续时间 8 - 20 周：采用的估算单位 - 月持续时间 20+ 周：说出估算前再仔细想想 15. 工具会放大你的才能。工具越好，同时你越知道怎样用更好，效率就越高 16. 共享目录绝非版本控制 17. 永远使用版本控制：即使你只有一个人且项目一周就会结束，即使它是一个 "用完即弃的" 原型，即使你操作的不是源码，永远都应如此 18. Bug 是你的错还是别人的错并不重要。无论是谁的错，问题仍然要你来面对 19. 爱德华・鲍沃尔 - 利顿：最容易欺骗的人就是自己 20. 不要假设，要证明 21. 你无法写出完美的软件 22. 死掉的程序不会说谎 23. 使用断言去预防不可能的事情 24. 有始有终这条提示告诉我们，理想情况下，分配资源的例程也应该负责释放它 25. 全局变量给代码带来耦合有很多原因。最明显的是，修改全局变量的实现，可能会潜在地影响到系统中的所有代码。当然，在实践中影响相当有限；归根结底，问题在于你必须找到每一处需要修改的地方 26. 如果全局唯一非常重要，那么将它包装到 API 中 27. 编程讲的是代码，而程序谈的是数据 28. 继承很少用到，对传统的类继承的三个替代方案：接口与协议委托 mixin 与特征 29. mixin 时要解决的问题。基本思想很简单：希望能够为类和对象扩展新的功能，但不用继承 30. 随机故障通常是并发问题 31. 用角色实现并发性时不必共享状态 32. 测试的主要收益来自于你思考和编写测试期间，而不是运行测试那一刻 33. 学会在编码时听从直觉是一项需要培养的重要技能 34. 找到恰好能用的答案和找到正确的答案不是一回事 35. 重组现有代码实体、改变其内部结构而不改变其外部行为的规范式技术 36. 进行重构：重复：你发现了一处违背 DRY 原则的地方非正交设计：你发现做一些事情可以让其更为正交过时的知识 37. 尽早重构，经常重构 38. 测试是代码的第一个用户 39. 测试驱动开发（TDD）的基本循环：决定要添加一小部分功能编写一个测试：等相应功能实现后，该测试会通过运行所有测试：验证一下，是否只有刚刚编写的那个测试失败了。尽量少写代码，只需保证测试通过即可：验证一下，测试现在是否可以干净地运行重构代码：看看是否有办法改进刚刚编写的代码（测试或函数）。确保完成时测试仍然通过 40. 既非自上而下，也不自下而上，基于端对端构建 41. 安全性的基本原则：将攻击面的面积最小化最小特权原则安全的默认值敏感数据要加密维护安全更新 42. 输入数据是一种攻击载体 43. 永远不要信任来自外部实体的数据，在将其传递到数据库、呈现视图或其他处理过程之前，一定要对其进行消毒 44. 保持代码简洁，让攻击面最小 45. 在计算机科学中两件难事：缓存失效和命名 46. 好好取名；需要时更名 47. 程序员帮助人们理解他们想要什么，可能是我们最有价值的属性 48. 需求是从反馈循环中学到的 49. 和用户一起工作以便从用户角度思考 50. 许多项目失败，都可以归咎于不断扩大涉及范围，也称为功能膨胀、特性泛滥或需求蠕变 51. 仔细看看你今天卷入的难题。你能解决这个棘手的问题吗？一定要这样做吗？一定要做吗？52. 当你投入到当前的项目时，是否得到了一组约束条件？它们到现在都仍然适用吗？对它们的解释仍然有效吗？53. 敏捷不是一个名词；敏捷有关你如何做事 54. 维持小而稳定的团队 55. 不要一个人埋头钻进代码中 56. 做能起作用的事，别赶时髦 57. 尽早测试，经常测试，自动测试 58. 测试状态覆盖率，而非代码覆盖率 59. 每个 Bug 只找一次 60. 用户真正要的不是代码，他们只是遇到某个业务问题，需要在目标和预算范围内解决。他们的信念是，通过与你的团队合作，能够做到这一点 61. 取悦用户，而不要只是交付代码 62. 在作品上签名

👉理性，真是个好东西👍编码，也是一门手艺活儿书中有大量提示的门道经验紥紮实实貌似都点在要紧处了操作到位靠谱至上外行人看热闹赞叹之余有感：👉理性，真是个好东西👍

不需要懂 c++ 精灵语言和各种程序细节，只要能看懂结果背后的逻辑就够用了。最小成事闭环，反馈，调节，增强，以用户为中心的随时调整数据的状态。成事是有章法的，精彩且枯燥，枯燥的是数据和代码着实不懂，背后的东西太精彩了。

《程序员修炼之道》之所以在全球范围内广泛传播，被一代代开发者奉为圭臬，盖因它可以创造出真正的价值：或编写出更好的软件，或探究出编程的本质，而所有收获均不依赖于特定语言、框架和方法。时隔 20 年的新版，经过全面的重新选材、组织和编写，覆盖哲学、方法、工具、设计、解耦、并发、重构、需求、团队等务实话题的最佳实践及重大陷阱，以及易于改造、复用的架构技术。本书极具洞察力与趣味性，适合从初学者到架构师的各阶层读者潜心研读或增广见闻。

虽然全篇大部分的都看不懂，因为涉及到代码以及程序的专业用语，但是有一点启发：中间讲到了给客服交付的是服务而不是程序，让我想到了朋友找你聊事情的时候真的是要一个解决方案吗？不一定，他其实想要的是有人理解他，并且安慰他心情的朋友，而不是一个给他讲是非对错单纯给解决方案的人。

针对技巧，设立清单和导图，写思考，反复链接，整理实践，并且计划学习和修正。从一个中间角度去思考。

一个为程序员写出好代码而出的书，非常受用，不过自己太菜，有些看不懂要怎么做

这本书在程序员圈非常出名，加入书架很长时间，今天早晨把它读完了。它不是一本只有技术细节的书，书中还有接近一半的篇幅，在讲述工作和思考的方法论。从每一章节的导言的一句话，就可以看出，作者将编程看作是一项哲学工作。跟大家分享一下我自己的收获：1. 要主动掌控自己的人生。给自己定一个计划，比如每年学一门新的编程语言，每个月看一本技术类书籍，经常看技术前沿的讲解视频，等等。如果你的技术过时了，花一些时间，去给自己充电，学习新的技术。这是一种自我投资，只有这种类型的加班才是有价值的。2. 不要花精力去解释，还是要花精力去寻找解决方案。当我们把事情搞砸以后，不需要花过多的时间去思考如何向别人解释，二是应该思考下一步做什么才能弥补当前的情况。每个人都有自己的技术盲区，遇到困难，当前不知道如何下手很正常，去找专业的书籍，专业的课程，跟周围的同事讨论，找到适合的解决方案。3. 石头做的汤，和温水煮青蛙。写软件的过程，是增加熵的过程。遇到任何软件中可能有隐患的部分，马上修复它，或者添加注释，提醒人们今后修复它，而不要想成这件事与我无关。人们无法战胜熵的原因在于，以为别人对这件事情也漠不关心。4. 追求好用即可的软件。尽早的把软件交付给客户，他们会给你提出好的建议，帮你做出更加优秀的软件。5. 发邮件的原则。（1）在发送之前，完整的检查一遍，是否有语法错误和错字。（2）检查收件人。仅仅这两个动作，就可以让我们避免绝大部分的混乱的邮件发送。6. DRY - Don't repeat yourself 模块化原则，凡是一样的代码，不要写到多处，而要进行复用。变量和对象也一样，要尽量使用单例模式。7. 要充分利用各种新的工具。配置好用的终端工具，编辑工具等。练习写脚本的能力，你会发现事情变得简单很多。8. 优化和重构。优化和重构不要过早进行，但是也不要累积到最后才去做。要进行小步迭代，敏捷开发。9. 敏捷的本质。敏捷的本质，指的是对变化的响应。10. 自动化。文明的进步是以增加那些不需要思考就可以完成的重要操作来实现的。我们要让软件尽可能的自动化和傻瓜化。以上就是我读这本书的收获，强烈推荐大家阅读一下。

把所有实物还原为它本来的样子！

程序员必读。

📖书名：程序员修炼之道：通向务实的最高境界（第 2 版）✍️作者：【美】David Thomas；Andrew Hunt❓为什么推荐这本书？如果想让自己的软件既领先于时代又易于维护，就在手边摆放一本《程序员修炼之道：通向务实的最高境界（第 2 版）》。本书充满实用建议，有技术方面的，也有专业方面的，无不能让你和你的项目受益多年。🌟 正是这本书，开阔了我的视野，让我意识到自己不仅仅是庞大机器上的一枚齿轮，有朝一日也能藉由修炼成为匠师。它是我生命中最重要的一本书。🌟 Dave 和 Andy 的作品，却能透出那种只有刚刚学到这些课程的人才会有的兴奋感，尽管他们已有几十年的编程经验，却战胜了写出这种感觉的挑战。他们不会居高临下地指指点点，不会假定你是个专家，甚至不认为你已读过本书第一版，仅仅把你当成想要变得更好的程序员而已。他们不惜用整本书的篇幅来帮助你达到目标，一步一个脚印。🌟 在写完本书第一版后，他们有机会思考自己想要说什么，想让读者获得什么，以及读者是如何接受这些信息的。他们得到了这些课程的反馈，也看到了读者在哪里被卡住、有什么需要改进，以及哪些内容被误解。在这本书通过全世界程序员的双手和心灵传播的二十年间，Dave 和 Andy 研究了这些回应，并且形成了新的想法和理念。🌟 他们以简单而深刻的启示开始这本书：“人生是你的。” 这唤起了我们自己的力量，它就蕴含在我们的代码库、工作和职业生涯中。这也为本书的其他内容定下了基调 —— 它不仅仅是又一本充满代码示例的技术图书。🌟 这本书不会告诉你编程应该是怎样的，它并没有使用那种哲学或审判的方式，它只是简单、明了地告诉你，什么是务实的程序员 —— 他们如何操作、如何处理代码。作者让你自己决定是否想成为其中的一员。如果你觉得不适合，也没有人会怪罪你。但如果你决定成为其中的一员，作者就是你的友好邻居，会陪伴左右、为你指路。🌟 这本书是许多短小主题的合集。每一个主题都针对特定的话题而独立成章。你会发现大量的交叉引用，这有助于把各个主题连贯起来。你可以以任意次序随意阅读这些主题 —— 这不是一本需要从头到尾阅读的书。🌟 名字有什么含义。“我用一个词，” 矮胖子相当傲慢地说，“总是同我想要说的恰如其分的，既不重，也不轻。”（路易斯・卡罗《爱丽丝镜中奇遇》）🌟 本书旨在告诉你，作为个体如何更好地完成工作。这本书不是理论书 —— 我们专注于实践的话题，利用经验来做出更明智的决定。🌟 这是一本关于实干的书。编程是一门技艺。简单地说，就是让计算机做你想让它做的事情（或是你的用户想让它做的事情）。作为一名程序员，你既在倾听，又在献策；既是传译，又行独裁；你试图捕获难以捉摸的需求，并找到一种表达它们的方式，以便仅靠一台机器就可以从容应付。你试着把工作记录成文档，以便他人理解；你试着将工作工程化，这样别人就能在其上有所建树；更重要的是，你试图在项目时钟的滴答声中完成所有这些工作。你每天都在创造小小的奇迹。🌟 编程是一项艰难的工作。调整方法去适应当前的情况和环境。对所有影响项目因素的相对重要性做出判断，并通过经验找到适当的解决方案。随着工作的进展，你要不断地这样做。务实的程序员不仅把工作做完，并且做得很好。🌟 谁应该读这本书。本书的目标读者是那些希望成为更高效、多产的程序员的人。也许你现在感到沮丧，因为似乎没能发挥自己的潜力；也许你已经注意到，有些同事似乎正在利用工具让自己的效率比你更高；也许你在现在的工作中使用的是较老的技术，你想知道如何为工作引入新的想法。🌟 思考！思考你的工作！为了成为一名务实的程序员，我们要求你在做事的时候，思考一下自己正在做什么。这不是对当前实践做的一次性审计 —— 而是对每天里每一个项目所做的每一个决定进行的批判性评估。⚠️程序员的底层逻辑。- 早期的采纳者 / 快速的适配者。- 好奇。- 批判性的思考者。- 现实主义。- 多面手。

为了成为一名务实的程序员，我们要求你在做事的时候，思考一下自己正在做什么。这不是对当前实践做的一次性审计 —— 而是对每天里每一个项目所做的每一个决定进行的批判性评估。不要用自动辅助驾驶系统偷懒，而是要不断地思考，即时地批判自己的工作。IBM 公司的座右铭 “思考！”，实属每个务实程序员的真言。

这本真的是常看常新的书，几年前看过第一版的，当再次翻阅时发现好多内容依然击中了我。我把这本书安利给了团队中的所有人，尤其推荐刚入行一两年的同事，希望他们能够在这本书中学会科学的开发思维和解决问题的方式。很多规范性、理论化的东西，可以口口相传加以纠正，但是效率太低。看这本书吧，一次性收获最佳实践，达成团队共识，减少沟通成本、提升开发效率。强烈推荐。

验作为一个 20 多年经的程序猿，现在读到这本书是对多年的总结，也是对自己工作的反思。愿新加入此行业的人们都读读

这本书讲的范围比较广，涉及了编程开发做项目的许多方面，好处是什么都有，坏处是饼太大了，没有深度了，反而很适合不会编程的人来了解程序员，所以标题里面的修炼并不合适，修炼是由浅入深的意思。书里面的例程用了我不会的语言，所以只能大概看一下，也许这是我没有领会妙处的原因吧

程序员的宝典。