我必须补充一点，如果我在出版时阅读了它，无疑会减轻我的痛苦，但是即使这样，重申自己的一些好习惯，并控制好坏习惯总是好事。 它涵盖了46个部分，并提供70个不同的技巧，这些技巧通常对任何程序员都有用。 Jeff Atwood –编码恐惧列出了所有70个技巧 。
与大多数事情一样，一些技巧比其他技巧“更平等”，那些真正突出并且可能无法足够强调的技巧是：
关心您的手艺
除非您关心软件开发，否则为什么要花费一生来开发软件？
认为！ 关于你的工作 关闭自动驾驶仪并控制。 不断批评和评估您的工作。 不要与破碎的Windows一起生活 看到错误的设计，错误的决定和错误的代码后，请进行修复。 定期投资您的知识组合 使学习成为一种习惯。 干–不要重复自己 每条知识都必须在系统中具有单一，明确，权威的表示形式。 易于重用 如果易于重用，人们会。 创建一个支持重用的环境。 学习原型 原型制作是一种学习体验。 它的价值不在于您编写的代码，而在于您学习的课程。 调试时不要惊慌 深吸一口气，想一想！ 关于可能导致该错误的原因。 “选择”没有中断。 在OS或编译器甚至是第三方产品或库中都很少发现错误。 该错误最有可能在应用程序中。 合同设计 使用合同来记录和验证代码没有超出其要求的范围。 早期崩溃 失效的程序通常比损坏的程序少得多的损害。 最小化模块之间的耦合 通过编写“害羞的”代码并应用Demeter定律来避免耦合。 不要巧合编程 仅依靠可靠的东西。 当心意外的复杂性，不要将愉快的巧合与有目的的计划混淆。 尽早重构，经常重构 就像您可能会除草并重新布置花园一样，在需要时重写，重新加工和重新构造代码。 解决问题的根源。 设计测试 在编写一行代码之前，请先考虑进行测试。 有些事情比描述的要好 不要陷入规范螺旋之中—在某些时候您需要开始编码。 不要拘泥于形式方法。 不要盲目采用任何技术，除非将其纳入您的开发实践和功能的范围内。 不要使用手动程序 Shell脚本或批处理文件将一次又一次地以相同顺序执行相同的指令。 尽早测试。 经常测试。 自动测试 与构建在架子上的测试计划相比，与每个版本一起运行的测试要有效得多。 完成所有测试后，编码才算完成 纳夫说。 测试状态范围，而非代码范围 识别并测试重要的程序状态。 仅测试代码行是不够的。 一次发现错误 一旦测试人员发现错误，那应该是测试人员最后一次发现该错误。 从那时起，自动测试应进行检查。
参考： 实用程序员–回顾/总结笔记，来自我们Zen的 JCG合作伙伴 Brian Du Preez， 涉及IT博客艺术 。
相关文章 ：
翻译自: https://www.javacodegeeks.com/2011/12/pragmatic-programmer-review-summary.html
扫一扫
164
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
