成为更好的程序员– Pete Goodliffe在2014年为关心代码的人编写了手册 。 如果您还没有阅读过，则应该认真考虑从leanpub，亚马逊或您当地的图书馆中获取并阅读。
内容非常详尽且结构合理，我敢打赌，您会在每一章的结尾欣赏10,000只Monkeys漫画，非常有趣。
如果您已经编程了几年，那么我相信您甚至可以从目录中获得很多建议。
我的计划是在本书的每一章中分享关键点的摘要。
本书分为四个部分，共38章和337页。 您可以在一周内完成。
第1章关心代码
关键：要编写好的代码，您必须在意它。 要成为更好的程序员，您必须投入时间和精力。
重点：对代码的情感反应没有错。 为您的出色工作感到自豪或对错误的代码感到厌恶是健康的。
第一部分。you.write（code）;
第2章。保持外观
重点：停止争夺代码布局。 在代码演示中采用健康的装束。
重点：良好的代码演示可以揭示您的代码意图。 这不是艺术上的努力。
重点：我们需要良好的表达方式，以免造成代码错误。 并非如此，我们可以创建漂亮的ASCII艺术。
重点：记住要为谁编写代码的人：其他人。 （来自我的评论：确实非常正确，否则可能是 3个月后 的 future you ）
重点：切勿同时更改演示和行为。 使它们分别受版本控制。 （来自我的评论：非常有用的提示，希望您已经这样做了！）
第3章。编写更少的代码！
重点：更少的代码可能意味着更多的软件。
关键：清晰，简洁地表达代码。 避免不必要的冗长的陈述。
关键：不要复制代码段。 将它们分解为共同的功能。 使用参数表示任何差异。
关键：如果发现重复，请将其删除。
关键：确保每个注释都为代码增加价值。 该代码本身说明了什么以及如何进行 。 评论应说明原因 -但前提是尚不清楚。
关键：请勿通过注释删除代码。 它使读者感到困惑，并妨碍了工作。
关键：每天，让您的代码比以前更好。 找到冗余和重复项后将其删除。
第4章通过删除代码来改进代码
关键：您可以通过添加新代码来改进系统。 您也可以通过删除代码来改善系统。
密钥：尽可能删除无效代码。 它会妨碍您的速度。 （来自我的评论：有了IDE的一些工具支持，例如重新共享工具，这样做实在太容易了）
关键：删除将来可能需要的代码是安全的。 您始终可以从版本控制中将其取回。
关键：代码清除应始终在对功能更改的单独提交中进行。 （来自我的评论：这是作者在第2章中提出的关键点，他有时确实重复了自己的观点，尽管不是一个笨手笨脚的问题）
第5章过去代码库的幽灵
重点：回顾旧的代码将使您了解编码技能的改进（或其他方面）。
第6章导航路线
重点：编写代码的最佳途径是由已经了解地形的人领导。 不要害怕寻求帮助！
关键：运行状况良好的项目只需执行一次检出即可获取整个代码库，并且可以将代码放置在构建计算机上的任何目录中。 不要依赖多个结帐步骤，也不要在硬编码的位置编码。
关键：健康的构建可以一步完成，在构建过程中无需人工干预。
重点：通常，系统的实际架构与理想设计有所不同。 始终信任代码，而不是文档。
重点：学习代码的最佳方法是对其进行修改。 然后从错误中学习。
第7章。
重点：准备好遇到错误的代码。 用锋利的工具填充您的工具箱以进行处理。
重点：当遇到“不良”代码时，可以使人感到沮丧。 相反，寻找切实改善它的方法。
重点：挑起战斗。 请仔细考虑是否应该花费时间和精力来“整理”不良代码。 现在不理会它可能是实用的。
关键：遵守童子军规则。 每当您触摸某些代码时，都比发现的要好 。
关键：缓慢，谨慎地更改代码。 一次进行一次更改。
重点： “坏”代码无需分摊责任。
第8章。不要忽略该错误！
关键：不要忽略代码中可能的错误。 不要推迟处理错误，直到“稍后”（您将无法解决它）。
重点：纪律严明地使用例外。 了解有效使用例外情况的语言习惯用法和要求。
第9章。期待意外
重点： 在编写代码时，请考虑所有潜在的代码路径。 不要打算以后再处理“异常”的情况：您会忘记的，并且您的代码会出错。
第10章漏洞搜寻
我喜欢本章的引文：如果调试是消除软件错误的过程，则编程必须是放入它们的过程。
— Edsger Dijkstra
重点：避免采用合理的工程实践在代码中注入错误。 不要期望快速破解的代码是高质量的。
关键：断言和日志记录（甚至是不起眼的printf ）都是有效的调试工具。 经常使用它们。
关键：二进制剁碎问题空间以更快地获得结果。
关键：未经测试的代码是产生错误的温床。 测试是您的漂白剂。
重点：了解如何正确使用调试器。 然后在正确的时间使用它。
关键：尽快修复错误。 在您陷入代码漏洞之前，不要让它们堆积。
第11章测试时间
重点：要改善软件开发，我们需要快速的反馈，以便尽快发现问题。 好的测试策略可以缩短反馈循环。
重点：我们需要在软件堆栈和开发过程的所有级别进行测试。 但是，程序员特别需要在尽可能小的范围内进行测试，以减少反馈回路并帮助尽快，轻松地开发高质量的软件。
关键：在编写被测代码时编写测试。 不要推迟测试写作，否则您的测试将不会有效。
重点：鼓励测试尽早并经常进行。 将它们烘烤到您的构建过程中。
重点：良好的开发测试不能替代全面的QA测试。
关键：不良测试可能是一种责任。 它们会阻碍有效的发展。
重点：维护您的测试套件，并在与您交谈时聆听。
关键：全局变量和单例对象是可靠测试的恶果。 您无法轻松地测试具有隐藏依赖性的单元。
重点：将代码分解为“可测试的”代码可导致更好的代码设计。
第十二章应对复杂性
朴素是一种伟大的美德，但要做到这一点需要付出艰苦的努力，需要对其进行欣赏的教育。 更糟糕的是：复杂性卖得更好。
— Edsger Dijkstra
本章没有重点，但有些句子写得很好：“我的观察是，软件复杂性源于三个主要来源。 斑点。 和线。 当您将它们组合在一起时，您会得到什么： 人 。”
第十三章两个系统的故事
关键：糟糕的软件体系结构将反映出公司结构不良和开发流程不健全。
关键：保持软件设计的质量。 错误的设计会导致进一步的错误设计。
关键：开发团队中工作关系的健康状况将直接影响到软件设计中。 不健康的关系和自负的自我膨胀导致软件不健康。
关键：好的设计应考虑连接机制以及组件间连接的数量（和性质）。 系统的各个部分应该能够独立存在。 紧密耦合会导致无法测试的代码。
关键：松散和模糊的体系结构导致单独的代码组件编写不正确，并且无法很好地融合在一起。 这也会导致代码和工作重复。
关键：不良体系结构的后果不受代码限制。 它们溢出到外部，影响人员，团队，流程和时间表。
关键：清晰的体系结构设计会导致系统一致。 所有决定都应在建筑设计的背景下进行。
关键：清晰的体系结构有助于减少功能重复。
关键：软件架构不是一成不变的。 如果需要，请更改它。 要改变，架构必须保持简单。 抵制损害简单性的更改。
重点：推迟设计决定，直到您必须做出决定为止。 当您还不知道需求时，不要做出架构决定。 不要猜
重点：必须保持设计质量。 只有当开发人员被赋予责任并认真对待时，这种情况才会发生。
重点：对系统进行一系列良好的自动化测试可以使您以最小的风险进行基本的体系结构更改。 它为您提供了工作空间。
关键：对代码进行单元测试可导致更好的软件设计，因此设计可测性。
关键：良好的项目计划可以带来出色的设计。 分配足够的时间来创建建筑杰作-它们不会立即出现。
重点：团队的组织对其代码产生不可避免的影响。 随着时间的流逝，体系结构还会影响团队的协作水平。 当团队分开时，代码会笨拙地交互。 当他们一起工作时，该架构可以很好地集成。
第二部分实践变得完美
明天继续……goToSleep（me）;
