最近看完了Bob大叔的“代码整洁之道-程序员的职业素养”一书，对于我认为比较重要的内容做下记录。
专业主义
- 将软件给QA测试前，自己要先做一遍测试工作，尽量让QA找不出任何问题。
- 好的软件结构应该是易于修改的，不要为了赶项目进度而破坏这种结构。
- 证明软件是易于修改的方式就是随时修改，一旦发现某些部分设计不合理，就应该尽快修改，使后续修改变的简单。
- 害怕修改代码的一个原因之一是因为没有做过完善的测试，对自己的代码没有信心，这个时候你需要一个能覆盖百分之九十以上代码且快速执行的自动化测试工具。
- 证明你不怕修改代码的方式就是一直改代码。
- 如果你每天抽出3个小时，那么你每周有21个小时用于自我学习和提升。
- 熟练掌握设计模式，设计原则，设计方法。
- 熟练掌握UML图，DFD图，结构图，Petri网络图，状态迁移图，流程图和决策表。
- 坚持学习新技术，技多不压身。
- 了解你开发的解决方案所对应的业务领域。
- 别人犯错的时候不要嘲讽别人，下一个犯错的有可能就是你。
- 多站在客户角度想问题，确保开发的功能真正满足客户。
说不
- 能就是能，不能就是不能，尽量不要说试试看，要坚守原则。
- 在无法按照对方的安排完成某项任务时，努力尝试找到双方都能接受的目标。
说是
- 承诺包括口头上说，心里认真对待承诺，真正付诸行动。
- 不要使用一些推卸责任的语句，例如希望我明天能完成任务，让我们抓紧完成这个项目，而是对你将要做的事做清晰的事实陈述，例如，我将在周二以前完成这项任务。
- 如果你无法兑现你的承诺，那么要尽早向你承诺的对象发出预警，越快越好。
编码
- 不要在疲劳时写代码，疲劳时容易写出错误的代码，导致后面浪费更多时间。
- 不要在焦虑时写代码，焦虑时工作效率低下，尽量调整好心情后再写代码。
- 心流态是进入一种意识高度专注但思维视野却会收拢到狭窄的状态，当进入心流态时，为了追求所谓的速度或者愉快感，理性思考的能力会下降，这个时候需要做一些其他事情换换脑筋，例如看电影，开车，吃饭等。
- 听歌会占用脑力资源，也更容易使人进入心流态，所以尽量不要在写代码时听歌，复制粘贴以及测试的时候除外。
- 写代码过程时中断无法避免，也许下次你请求帮助的时候也会打断别人，因此对于他人的中断应该表现出乐于助人的态度；测试驱动开发可以减少中断的影响。
- 写代码过程中也会遇到阻塞，死活不知道怎么写，这个时候需要找一些其他事情干，比如洗澡，看书，散步。阻塞的原因包括睡眠不足，焦虑，恐惧，沮丧。
- 创造力可以激发创造力，所以闲暇时可以接触一些计算机以外的资料来激发创造力，例如小说，电影，音乐，展览等。
- 三人行必有我师，即使你的技术再高超，也肯定能从另外一名程序员的思考与想法中获益。
- 互相帮助是程序员的职责所在，帮助别人的过程中你也会学到不少东西。
测试驱动开发
- 在写好单元测试之前，不要写任何产品代码。
- 只要有一个单元测试失败了，就不要再写测试代码。
- 产品代码恰好能让当前失败的单元测试通过即可，不要多写。
- 先写测试代码的好处是，你为了编写测试代码，需要将函数与函数间解耦，换言之，先写测试代码会迫使你去考虑什么是好的设计。
- 事后写的测试只是一种防守，先行编写的测试则是进攻。
需求沟通
- 项目刚开始评估需求时，不要贪求需求的精确性，因为需求一定是会变化的，要推迟精细化，例如用什么数据库，用什么网络库，用什么界面库。
- 消除需求中不确定因素的一个办法是进行验收测试，其目的在于确认需求已经完成。
- 验收测试应当自动化进行，理想情况下，验收测试程序由业务方和QA协助编写，程序员来检查测试之间是否有冲突或者矛盾；如果只能由开发人员编写测试，应当确保写验收测试的和写项目的不是同一人。
- 实现某项功能的代码，应该在对应的验收测试写好后开始，开发人员运行这些验收测试，观察失败的原因，然后实现需要的功能，让测试通过。
- 单元测试时程序员写给程序员的，验收测试时业务方(程序员)写给业务方的。单元测试是深入系统内部进行，调用特定类的方法，验收测试是在系统外部，通常是系统API或者UI级别进行。
- GUI是易变的，GUI和业务一定要解耦。
关心你的时间
- 受到邀请的会议没必要全部参加，邀请你参加会议的人不负责管理你的时间，为时间负责的只有你，所以如果你觉得没有参加会议的必要，应当礼貌的拒绝。
- 如果你觉得参加会议是浪费时间，应当想个礼貌的办法退出来。
- 每天至少睡眠7个小时。
- 适当的咖啡因可以有效提高注意力，例如咖啡或者无糖可乐。
- 当没办法控制注意力时，尽量换下脑子，做一些其它事情恢复注意力，例如散步，聊天等。
- 肌肉注意力有助于改善心智注意力，例如搏击，瑜伽，羽毛球，骑车，定期训练肌肉注意力可以提升心智注意力上限。
- 有时候我们会为了逃避真正的工作，说服自己另外一个任务更重要，提高某个任务的优先级。专业开发人员应该排除个人的喜好和需要，来评估每个任务的优先级，按照真实的紧急程度来执行任务。
- 当遇到死胡同时，比如走不通的技术道路，应当迅速意识到并有足够的勇气回头。专业的开发人员应该保持开放的头脑来听取其他人的意见。
- 当某个项目不断扩展，越来越复杂，现有设计越来越跟不上脚步时，而你意识到一开始就做出了错误的设计时，应该立即回头，否则会陷入泥潭，永远不得脱身。
软件大师的定义
- 十年以上从业经验。
- 曾领导过多个重要软件项目的开发。
- 曾在多个不同类型的系统，语言，操作系统上工作过。
- 懂的如何领导和协调多个团队。
- 他们是熟练的设计师和架构师以及程序员。
