敏捷软件开发（珍藏版）

我经历过跨地域协作的研发，也见证过团队在“形似敏捷”的挣扎。重读罗伯特·马丁的《敏捷软件开发（珍藏版）》，最深刻的感受是：它不仅是给开发者的技术指南，更是为研发管理者提供了一套“敏捷落地的工程化标尺”。 很多团队把敏捷等同于“快速交付”，却忽略了“工程实践是基石”——没有测试驱动开发（TDD）保障的迭代，是“带病奔跑”；缺乏重构意识的快速迭代，最终会让代码变成无法维护的“技术债务泥潭”。这一点对管理跨文化团队尤其关键：当不同国家的开发者对“敏捷”有不同理解时，书中的SOLID原则、重构方法论能成为统一的技术语言，避免协作中“各说各话”。 此外，书中的薪资管理系统案例，对管理者的项目规划极具参考价值。我们常遇到“需求频繁变更”的困境，而书中强调的“通过高质量代码提升系统适应性”，其实是在提醒管理者：与其在需求变更时焦虑，不如提前在团队中推行TDD、结对编程等实践，从技术层面降低变更成本。这种“从技术根源解决管理问题”的思路，“似乎”比单纯制定流程更有效。 对研发管理而言，这本书的价值还在于它的“前瞻性”。即便出版多年，书中对“代码质量与交付效率平衡”“团队技术能力建设”的论述，依然精准命中当前研发管理的核心痛点。如果你的团队正陷入“敏捷流程走得顺，但代码质量掉得快”的困境，这本书或许能帮你找到破局的关键——毕竟，真正的敏捷，从来不是流程的堆砌，而是工程实践与管理智慧的结合。

敏捷不了，或者我们一直都在敏捷中。当前的业界早就是这样单功能全功能的测试，而TDD也完全靠人来推动而不是开发的流程。

曾经年少轻狂都追过敏捷，被毒打、撞南墙后，所谓敏捷开发可能更适用于小作坊！ 大公司：流程合规，文档齐备，即使没有被甩锅，也能在 Shen ji 活下来！ 无所谓敏捷，麻麻了都！

软件开发新手认为做每件事情都必须要快。他们认为，美是不实用的。错！错！错！由于做事速度太快，他们所造成的混乱使得软件系统僵化和难以理解。美的系统是灵活的，容易理解的，构建和维护这样的系统更是一种快乐。丑的系统才是不实用的。丑，会降低你的开发速度，让你的软件昂贵而又脆弱。构建和维护美的系统所花的代价最少，交付速度也最快。

一本好书被翻译坑了，难怪读者这么少。 在阅读第6章末尾保龄球规则的那一块发现明显的翻译矛盾点，搞得我一度很懵逼，对比了纸质版郑辉翻译的后，才解开了疑惑。 还未读完估计还有其他翻译坑。。。。。汗("▔㉨▔)汗 

看了bob大叔其他三本clean系列的书，前面大部分总结的三本都提到的设计原则，指标等。 后面读起来不是太顺，要花大量时间去理解项目以及作者的想法，可能多回头看下收获会更多。

后面基本上都是设计模式，另外翻译比较一般

拙劣的软件设计的症状： 僵化性(rigidity )—设计难以改变； 脆弱性(fragility)—设计易于遭到破坏； 顽固性(immobility)—设计难以重用； 粘滞性(viscosity )—难以做正确的事情； 不必要的复杂性(needless complexity)—过分设计； 不必要的重复(needless repetition)—滥用鼠标进行复制、粘贴； 晦涩性(opacity)—混乱的表达。

设计必须保持整洁、简单，并且，由于源代码是设计最重要的表达，所以它必须保持整洁。作为软件开发人员，专业性要求我们不能容忍代码腐坏。 源码即设计。