《Practices of an Agile Developer》笔记00 && 用计划任务约束自己

　　今晚阅读了《Practices of an Agile Developer》的第六章 Aglie Coding。

　　以下是我的读书笔记（黑体是笔记，楷体是我的注释）：

• 不要陷入快速的debug fix和仓促的编程中。要清晰的知道代码的作用和可能引发的所有结果。那样效率才是最高的。总之，理解了程序的意图才能高效编程，高效的debug。

　　　　目前编程有时还会追求速度而在没有完全深入理解代码的时候就开始debug或者编程，最后带来的后果就是原本预算10分钟的debug花了30分钟甚至更多

• 不要长时间（数十分钟）的坐下来一直编码，然后再进行构建。要不断的进行增量式循环式的编程。即保持 编码 – 构建 – 测试 – 思考的循环流程来进行编程的活动。那样思维更清晰，而且在大方向上不容易走错。

　　　　最重要的是不断的测试和停下来思考，因为一直埋着头走路是很危险的，很有可能就掉入了一个陷阱。但是自己还是要把握时间片，不能让中断来的太频繁。

• 优雅（elegant）代码的定义：简单，短小，不能再删除任何东西，但却逻辑完备、功能强大、易于阅读和维护。编写代码的时候牢牢记住要编写简洁、可读性强的代码。

优雅的代码没有人不喜欢。没有人喜欢充斥了冗余，复杂逻辑，深度嵌套的if-else...的代码。另外对数据结构和算法的应用也十分有助于编写出优雅的代码，看着代码行数的减少，然而代码的可读性和健壮性却增加真是件振奋人心的事情

• 当性能已经可以满足需求时，不要过分的去追求优化，要知道世上没有十全十美的东西，这时要去考虑其它问题（性能，便捷性，费用等等）。另外knuth说过“不要过早的进行代码优化”，过早优化很可能没有作用或带来副作用。

　　　　我的一点想法是，何为过早有一个区分的标准。但是编码过程中，不要把大量精力用到追求优化上，而是在平时就编写出“优雅的代码”。

• 坚持一个包，一个类只做一些相同或相似的事情，不要试图处理很多不相关的事情，否则维护起来很麻烦。另外在编写类的子程序时，要学会区分两种子程序，一种是命令（command），一种是查询（query）。命令是用来唯一改变实例或类的状态，顺便可以返回一些状态；但是查询仅仅是用来对外提供查询实例状态的接口，对于暴露的查询接口的编写要慎重，不是必须的最好不要写。

　　　　典型的oo思想。

　　另外，可用windows自带的计划任务来约束自己。在特定的时段新建任务，任务可以是打开窗口，脚本或显示消息等。

　　为了约束自己，时刻提醒自己不能浪费时间在无聊的QQ和人人上，我在晚间设定了多个计划任务。分别在不同时段来提示自己应该做的事情。

　　比如：20:30 - 21:20 是我的第一个阅读时段区间，这时计划任务就会在20:30点触发，提示我开始读书。

　　或者我经常由于不自觉的原因不关机晚睡，计划任务可以定时关机，定时关机触发后是不可逆的，所以可以有效的杜绝我继续使用电脑，而达到逼迫我睡眠的好处。