高效能程序员的修炼

错误调试方法

1. 分析项目的整个运行流程，梳理各个环节，找到可能出错的地方加以修改
2. 根据错误提示找到错误根源， 删一段再执行一段
3. 小黄鸭调试法：强迫自己把遇到的问题说出来，详细说出每一行代码的作用以及实现的功能，一定要说出来，对人对物都可以。

高效能程序员的修炼

• 锻炼写作能力
• 绕开绊脚石，直达目的地（重要）
• 专注于一项工作
• 学会阅读源代码
• 避免写不必要的注释：规范化类名与方法名
• 不必从头开始复习，专注于当下
• 不要写死代码

卓越程序员密码

• 早起先测试

• 别在卧室里工作：

  • 别让每周40小时的工作变成168小时的工作+睡觉+吃喝玩乐

• 写代码是不得已而为之：

  • 思考为什么要写它，有没有更好的解决办法

• 对休闲项目坚决说不

  • 开启项目前问自己几个问题：
  1. 每周花几天，每天花几个小时在这个项目上（可持续的工作量，坚持）
  2. 什么时候能把一个基本成型的产品展示给别人（可供测试的软件）
  3. 哪一天向公众发布（够用的软件）
  4. 哪一天发布第一个主要的更新版本
  • 设置一个最后期限，哪怕是随意设的

• 仿造软件：

  • 找一个你喜欢的网站或游戏，把它仿造出来。在你真正的想做一件项目前，先做完这个。这个能促使你学到前沿的编程技术，而且能让你更容易的被招聘公司选中。做3-5个这样的仿制项目后，你就能实现任意的你想要的东西了。

• 每个项目都要学到新东西：

  • 每次项目都努力使用一些听到过但从未使用过的新东西。没有使用过jquery，那下次项目中就使用它
  • 没有试过测试驱动开发，下次项目就是你的实验品

• 每天改进产品的两个方面，即便是非常小的改进

CleanCode

童子军军规：离开时要比来时更整洁。

如果每段代码都让你感到深合己意，那就是整洁代码。

整洁的代码只做好一件事

一以贯之的命名法。统一命名方式

类名名词、方法名动词

整洁代码是重构出来的，而非一开始就写出来的，没人能做到这种事情。

别给糟糕的代码加注释---重新写吧。但是由于我们并非英语国家，还是需要多写注释的，不过是代码的英文翻译。

TDD（Test-Driven Development）：测试驱动开发，就好比数据抽取的公式，一开始不知道如何下手，换个角度想想看怎么测试，先设计个简单的界面，思考需要传递什么参数，一步步测试，一步步开发。测试能帮我们想到开始开发时想不到的点，帮我们确认需求。

测试代码的简洁度反映了业务代码

TDD三大定律：

1. You must write a failing unit test before you write production code.（在编写不能通过的单元测试前，不可编写生产代码）
2. You must stop writing that unit test as soon as it fails; and not compiling is failing.（只可编写刚好无法通过的单元测试，不能编译也算不通过）
3. You must stop writing production code as soon as the currently failing test passes.（只可编写刚好足以通过当前失败测试的生产代码。）

使用但尽量少使用断言语句。（保持测试的可重用性，每个测试只测试一个功能，好比每个方法只做一件事）

整洁的测试规则：FIRST

• Fast，快速，才能频繁进行测试
• Independent，独立，多个测试之间应该相互独立，不能有任何关系
• Repeatable，可重复，测试应可在任何环境下通过
• Self-Validating，自足验证，测试应该有布尔值输出（或断言），无论通过或者失败都不应该查询控制台或者日志确认测试是否通过。
• Timely，及时，测试应该及时编写，恰好在使其通过的生产代码之前编写

单一权责原则：（Single Responsibility Principle）

• 类或模块应该有且只有一条加以修改的理由

系统应该由许多短小的类而不是少量巨大的类组成。每个小类封装一个权责，只有一个修改的原因，并与少数其他类一起协同工作达成期望的系统行为。

重构一般都需要大动代码，为了保证程序的可正常运行，最好编写一套测试用例，保证重构前后系统的正确性，在一步一步的重构时执行测试用例。

转载于:https://www.cnblogs.com/mabaoqing/p/10730414.html