整顿了一下《代码整洁之道 – 程序员的职业素养》中一些受益匪浅的观点。
第一章 业余主义
- 分明你想要什么
- 承担责任
- 理解你的畛域
失误率永远不能等于 0，但你有责任让它有限接近于零。
每个业余软件开发人员必须理解的技能：
- 设计模式。必须可能形容 GOF 书中的全副 24 种模式。
- 设计准则 必须理解 SOLID 准则，深刻理解组件设计准则
- 结构图 流程图 决策表 状态迁徙图表
第二章 说“不”
大多数工夫咱们都心愿可能说“是”。衰弱的团队都会致力寻找给别人必定的回答。运作良好的团队经理和开发人员，会互相协商，直到达成独特认可的口头计划。
然而有时候，获取正确决策的惟一路径，便是勇敢无畏的说“不”。这个是比说“是”更负责任，更业余，也更艰难的能力。
第三章 说“是”
- 恪守承诺
- 如果这个事件依赖别人，无奈掌控，须要采取一些具体口头来达成指标。比方坐下来讨论一下具体口头，来一步一步靠近指标，直至实现指标。
- 如果的确无奈实现，连忙去调整他人对你的预期，越快越好
第四章 编码
给别人提供帮忙并非阐明你更聪慧，而是你带来了一个新的视角，对解决问题起到了显著的催化作用。PS：事实上可能提供欠缺的解决方案，一眼看出问题出在什么中央也是一种可贵的能力和丰盛教训的累积。
辅导年老的程序员是经验丰富程序员的职责所在，向资深的导师寻求帮忙也是年老程序员的业余职责。
第五章 TDD 的三项法令
- 在编写好失败单元测试之前，不编写任何产品代码
- 只有有一个单元测试失败了就不须要再写测试代码; 无奈通过编译也是一种失败状况
- 产品代码恰好可能让以后失败的单元测试通过即可，不要多写。
TDD 能够晋升代码确定性、升高代码缺陷率，优化文档和设计的准则。
测试后行，会迫使你去思考什么是好的设计。
预先测试只是一种防守，后行编写测试则是防御。预先编写的测试曾经受制于已有代码，曾经晓得问题是如何解决的。测试后行的防守编写测试代码比起来，后写的测试在深度和捕捉谬误的灵敏度方面要逊色很多。
第六章 练习 - 本身教训的扩大
老板的职责不包含防止你的技术掉队，也不包含为你打造一份难看的简历。放弃本人的技能不掉队是本人的责任。
第七章 验收测试
做业务和写程序的人都容易陷入一个陷阱：过早进行精细化。
- 不确定性准则
货色画在纸上与真正做进去，是不一样的。业务方看到真正运行的状况就会意识到，本人想要的货色基本不是这样。
一看到曾经满足的需要，对于到底想要什么，他们就会有更好的想法——通常并不是他们过后想看到的样子。
- 预估焦虑
即使领有全面精确的信息，评估也通常会存在微小的变数。其次，因为不确定准则的存在，不可能通过反复推敲实现早起的精准性。需要 肯定会 变动的，所以过早谋求精确性是徒劳的。
身为业余开发人员，你的职责是帮助开发团队开发出最棒的软件。也就是说每个人都须要关怀谬误和忽略，并帮助改过。
验收测试和单元测试
验收测试是业务方的，是正式的需要文档，形容了业务方认为零碎应该如何运行。关怀验收测试后果的是业务方和程序员。
单元测试是程序员写给程序员的，它是正式的设计文档，形容了底层构造和代码行为，关怀单元测试后果的只是程序员。
它们的次要目标是如实形容零碎的设计、构造和行为。当然他们也能够验证设计、构造和行为是否达到了具体指标，然而它们的真正价值不是在测试上，而是在具体指标上。
第八章 测试策略
只管公司可能设有独立的 QA 小组专门负责测试软件，然而开发小组依然要把“QA 应该找不到任何谬误”作为致力的指标。
对于 QA 找到的每一个问题，开发团队都应高度重视，认真对待。应该反思为什么呈现这种谬误，并采取措施 防止今后重犯。
第九章 工夫治理
对于会议，有两条真谛
- 会议是必须的
- 会议节约了大量的工夫
在走入死胡同后能够疾速意识到，并且 有勇气 走回头路。这就是 坑法令：如果你掉进了坑里，别挖。
第十章 预估
当发现预估的工夫有余时，最重要的是致力解决这个问题，并向内部同步停顿。
预估真正的问题在于：业务方认为是承诺，开发方认为是猜想。
不要给出承诺，除非你确切晓得能够实现。
第十二章 合作
你须要了解手上正在编写的代码业务价值是什么，理解雇佣你的企业将如何从你的工作中取得回报。
对做的事件充斥激情是好的，然而，最好把注意力集中到付咱们薪水的老板所谋求的指标上。(关注业务和业务指标)