https://book.douban.com/subject/26919457/
本书是作者Rober C. Martin，也就是“Bob大叔”40多年编程生涯的心得体会的总结。要成为专业的工程师需要具备怎样的态度，需要遵循怎样的原则，需要采取怎样的行动。以及作者走过的一些弯路的错误示例。
专业合理的排期
专业合理的排期是规避项目延期和保证项目质量的前提。 书中将其总结成两个方面：
学会拒绝
不要惧怕对抗，要坚持合理的排期结果，妥协会给自己的团队带来极大的损失甚至是项目的延期并且要提前向上抛出风险。为什么坚持这样的排期，其中的原因往往不那么重要，提供太多的细节往往会招到更多的微观管理。
学会承诺
职场没有尝试，不要说“试试看，我尽量”，而是需要给出一个明确的时间点。并且遵守原则。尽可能做到“有求必应”，当给出肯定的承诺回答时，会使用正式的承诺，以确保各方能明白无误地理解承诺的内容。
高效率编码
需要寻找一个好的状态，避免疲劳或者心烦意乱的状态。
书中提到一个“流态区”的概念。“流态区”的意思是，进入一种意识高度专注但思维视野却会收拢到狭窄的状态，这种情况下人会感到效率极高。
Bob大叔的忠告是，避免进入流态区，这只是一种“浅层冥想”状态，这种状态下，为了追求所谓的速度，理性思考的能力会下降。----既所谓的，眼光会暂时变得“狭隘和短浅”。
有时候也可以通过一些创造性的输入给我们激发灵感和创造力（这种创造性输入是针对大脑而言的）。比如一些别的行业领域的知识。
TDD
三项法则：
1.在编好单元测试之前，不要编写任何产品代码
2.只要一个单元测试失败饿了，就不要在编写测试代码，无法通过编译也是一种情况
3.产品代码恰好能够让当前失败的单元测试成功通过即可，无需多写
-这是个非常酷炫的理想化工作模式，对与bug的态度从原来的防守状态变为主动进攻（因为你需要先编写单元测试代码再开始编写产品代码）。
-同时也能极大的缩小运行一次代码的周期，快速发现问题提高效率。
-这可以极大减轻回归测试的压力，也就是减少了重构的风险和成本，要时常优化代码（不变的代码是很危险的）。
-这会迫使你去隔离出待测试的代码，简单的函数相互直接调用不方便测试，这时候就需要对俩函数进行解耦，这可能会引导你从“面向接口编程”的角度去思考你的代码。
局限：得保证写出优秀的测试代码。
UI界面开发因为GUI变动频繁，容易导致测试代码失效，成本很高。
练习
再练习编码防手生的情况下就提倡进入“流态区”，可以选择一些小算法来频繁练习，譬如刷题。
测试策略
业务方对功能的设想，往往经不起在电脑前真枪实弹的考验，所以要避免过早的精细化。所以为什么叫做“评估”。当精细化被推迟，伴随而来的是迟来的模糊性。这种模糊性，就是开发和业务方对验收标准的分歧。书中的解决办法是-验收测试。
验收测试就是业务方与开发合作编写的测试（自动化），目的是确定需求已经完成。
验收测试和单元测试不一样。
单元测试是工程师写给工程师的，是正式的设计文档。关心单元测试结果的是工程师。
验收测试是业务方写给业务方的 ，是正式的需求文档，关心验收测试结果的是业务方和工程师。
两者虽然测试的是同一个对象，但是机制和路径不同，单元测试是深入系统内部，调用特定类的方法。验收测试则是在系统外部，通常是在API或者UI级别进行。执行的路径截然不同。
还有个根本原因，测试只是他们的附属职能。首先是文档，然后才是测试。主要目的是描述系统的设计，结构，行为。真正的价值在具体指标上。
必要的时候需接入CI
QA的职责总结下来有两个：
1.需求规约定义者（和业务人员一起创建自动化验收测试）
2.特性描述者（遵循探索式测试原则把过程细节反馈给开发）
*****人工探索式测试***
***************系统测试*************
********************集成测试*****************
************************组件测试**********************
****************************单元测试****************************
时间管理
避免低效会议（不参与，或则中途礼貌离席）
书中提到一个很有趣的时间片管理法----
番茄工作法
这个命名起源于厨房里长得像番茄一样的计时器。把时间切成30分钟的小片，每次工作25分钟（25分钟专注不可被打扰）然后休息放松5分钟，每完成4个番茄时间段时间，休息30分钟左右。每天大概能有12~14个这样的时间片。
需要补充的是：这个技法适用于“有生产率的时间段”上，你可以真正的做点事情，其他的时间属于非番茄时间。
协作问题
团队比项目更难构建，因此，组建稳健的团队，让团队在一个个项目中整体移动共同工作是较好的做法，给团队充足的时间，形成凝聚力，一直共同工作，成为不断交付项目的强大引擎。
最后总结一下，专业软件开发人员必须精通的事项
设计模式：
必须能描述GOF书中的全部24种模式，同时还有有POSA书中的多数模式的实战经验
设计原则：
必须了解SOLID原则，而且要深刻理解组件设计原则
方法
理解XP，Scrum，精益，看板，瀑布，结构化分析，结构化设计等
实践
掌握测试驱动开发，面向对象设计，结构化编程，持续集成，结对编程
工件
UML图，DFD图，结构图，Petri网络图，状态转移图表
网友评论