差别

这里会显示出您选择的修订版和当前版本之间的差别。

--- 程序员修炼之道 [2020/08/14 17:59] – plough
+++ book:程序员修炼之道 [2020/09/02 17:01] (当前版本) – ↷ 页面程序员修炼之道被移动至book:程序员修炼之道 plough
@@ 行 121: / 行 121: @@
 bug 是你的过错还是别人的过错，并不是真的很有关系——它仍然是你的问题，它仍然需要修正。
-====2.====
+====25. 不要恐慌====
+Don't Panic When Debuging
-====2.====
+做一次深呼吸，思考什么可能是 bug 的原因。
-====2.====
+====26. “Select”没有问题====
+"Select" Isn't Broken
-====2.====
+在 OS 或编译器、甚或是第三方产品或库中很少发现 bug。bug 很可能在应用中。
-====2.====
+====27. 不要假定，要证明====
+Don't Assume It - Prove It
-====2.====
+在实际环境中——使用真正的数据和边界条件——证明你的假定。
-====2.====
+====28. 学习一种文本操纵语言====
+Learn a Text Manipulation Language
-====2.====
+你用每天的很大一部分时间处理文本，为什么不让计算机替你完成部分工作呢？
-====2.====
+====29. 编写能编写代码的代码====
+Write Code That Writes Code
-====2.====
+代码生成器能提高你的生产率，并有助于避免重复。
-====2.====
+====30. 你不可能写出完美的软件====
+You Can't Write Perfect Software
-====2.====
+软件不可能完美。保护你的代码和用户，使它（他）们免于能够预见的错误。
-====2.====
+====31. 通过合约进行设计====
+Design with Contracts
-====2.====
+使用合约建立文档，并检验代码所做的事情正好是它声明要做的。
-====2.====
+====32. 早崩溃====
+Crash Early
-====2.====
+死程序造成的危害通常比有问题的程序要小得多。
-====2.====
+====33. 用断言避免不可能发生的事情====
+Use Assertions to Prevent the Impossible
-====2.====
+断言验证你的各种假定。在一个不确定的世界里，用断言保护你的代码。
-====2.====
+====34. 将异常用于异常的问题====
+Use Exeptions for Exceptional Problems
-====2.====
+异常可能会遭受经典的意大利面条式代码的所有可读性和可维护性问题的折磨。将异常保留给异常的事物。
-====2.====
+====35. 要有始有终====
+Finish What You Start
-====2.====
+只要可能，分配某资源的例程或对象也应该负责解除其分配。
-====2.====
+====36. 使模块之间的耦合减至最少====
+Minimize Coupling Between Modules
-====2.====
+通过编写“羞怯的”代码并应用德墨忒尔法则来避免耦合。
-====2.====
+====37. 要配置，不要集成====
+Configure, Don't Integrate
-====2.====
+要将应用的各种技术选择实现为配置选项，而不是通过集成或工程方法实现。
-====2.====
+====38. 将抽象放进代码，细节放进元数据====
+Put Abstractions in Code, Details in Metadata
+为一般情况编程，将细节放在被编译的代码库之外。
-====2.====
+====39. 分析工作流，以改善并发性====
+Analyze Workflow to Improve Concurrency
-====2.====
+利用你的用户的工作流中的并发性。
-====2.====
+====40. 用服务进行设计====
+Design Using Services
-====2.====
+根据服务——独立的、在良好定义、一致的接口之后的并发对象——进行设计。
-====2.====
+====41. 总是为并发进行设计====
+Always Design for Concurrency
-====2.====
+容许并发，你将会设计出更整洁、具有更少假定的接口。
-====2.====
+====42. 使视图与模型分离====
+Separate Views from Models
-====2.====
+要根据模型和视图设计你的应用，从而以低廉的代码获取灵活性。
-====2.====
+====43. 用黑板协调工作流====
+Use Blackboards to Coordinate Workflow
-====2.====
+用黑板协调完全不同的事实和因素，同时又使各参与方保持独立和隔离。
-====2.====
+====44. 不要靠巧合编程====
+Don't Program by Coincidence
-====2.====
+只依靠可靠的事物。注意偶发的复杂性，不要把幸运的巧合与有目的的计划混为一谈。
-====2.====
+====45. 估算你的算法的阶====
+Estimate the Order of Your Algorithms
-====2.====
+在你编写代码之前，先大致估算事情需要多长时间。
-====2.====
+====46. 测试你的估算====
+Test Your Estimates
-====2.====
+对算法的数学分析并不会告诉你每一件事情。在你的代码的目标环境中测定它的速度。
-====2.====
+====47. 早重构，常重构====
+Refactor Early, Refactor Often
-====2.====
+就和你会在花园里除草、并重新布置一样，在需要时对代码进行重写、重做和重新架构。要铲除问题的根源。
+====48. 为测试而设计====
+Design to Test
+在你还没有编写代码时就开始思考测试问题。
+====49. 测试你的软件，否则你的用户就得测试====
+Test Your Software, or Your Users Will
+无情地测试。不要让你的用户为你查找 bug。
+====50. 不要使用你不理解的向导代码====
+Don't Use Wizard Code You Don't Understand
+向导可以生成大量代码。在你把它们合并进你的项目之前，确保你理解全部这些代码。
+====51. 不要搜集需求——挖掘它们====
+Don't Gather Requirements - Dig for Them
+需求很少存在于表面上。它们深深地埋藏在层层假定、误解和政治手段的下面。
+====52. 与用户一同工作，以像用户一样思考====
+Work with a User to Think Like a User
+要了解系统实际上将如何被使用，这是最好的方法。
+====53. 抽象比细节活得更长久====
+Abstractions Live Longer than Details
+“投资”于抽象，而不是实现。抽象能在来自不同的实现和新技术的变化的“攻击”之下存活下去。
+====54. 使用项目词汇表====
+User a Project Glossary
+创建并维护项目中使用的专用术语和词汇的单一信息源。
+====55. 不要在盒子外面思考——要找到盒子====
+Don't Think Outside the Box - Find the Box
+在遇到不可能解决的问题时，要确定真正的约束。问问你自己：“它必须以这种方式完成吗？它真的必须完成吗？”
+====56. 等你准备好再开始====
+Start When You're Ready
+你的一生都在积累经验。不要忽视反复出现的疑虑。
+====57. 对有些事情“做”胜于“描述”====
+Some Things Are Better Done than Described
+不要掉进规范的螺旋——在某个时刻，你需要开始编码。
+====58. 不要做形式方法的奴隶====
+Don't Be a Slave to Formal Methods
+如果你没有把某项技术放进你的开发实践和能力的语境中，不要盲目地采用它。
+====59. 昂贵的工具不一定能制作出更好的设计====
+Costly Tools Don't Produce Better Designs
+小心供应商的炒作，行业教条、以及价格标签的诱惑。要根据工具的价值判断它们。
+====60. 围绕功能组织团队====
+Organize Teams Around Functionality
+不要把设计师与编码员分开，也不要把测试员与数据建模员分开。按照你构建代码的方式构建团队。
+====61. 不要使用手工流程====
+Don't Use Manual Procedures
+shell 脚本或批文件会一次次地以同一顺序执行同样的指令。
+====62. 早测试，常测试，自动测试====
+Test Early. Test Often. Test Automatically
+与呆在书架上的测试计划相比，每次构建时运行的测试要有效得多。
+====63. 要到通过全部测试，编码才算完成====
+Coding Ain't Done 'Til All the Tests Run
+就是这样。
+====64. 通过“蓄意破坏”测试你的测试====
+Use Saboteurs to Test Your Testing
+在单独的软件副本上故意引入 bug，以检验测试能够抓住它们。
+====65. 测试状态覆盖，而不是代码覆盖====
+Test State Coverage, Not Code Coverage
+确定并测试重要的程序状态。只是测试代码行是不够的。
+====66. 一个 bug 只抓一次====
+Find Bugs Once
+一旦测试员找到一个 bug，这应该是测试员最后一次找到它。此后自动测试应该对其进行检查。
+====67. 英语就是一种编程语言====
+English is Just a Programming Language
+像你编写代码一样编写文档：遵守 DRY 原则、使用元数据、MVC、自动生成，等等。
+====68. 把文档建在里面，不要拴在外面====
+Build Documentation In, Don't Bolt It On
+与代码分离的文档不太可能被修正和更新。
+====69. 温和地超出用户的期望====
+Gently Exceed Your Users' Expectations
+要理解你的用户的期望，然后给他们的东西要多那么一点。
+====70. 在你的作品上签名====
+Sign Your Work
+过去时代的手艺人为能在他们的作品上签名而自豪。你也应该如此。