这周读到了第四章，主要讲的是跟编码有关的一些知识，什么时候效率最高，什么时候不适合编码等一系列的问题
1.代码必须能够正常工作；代码必须能够帮你解决客户提出的问题；代码必须要能和现有系统结合得天衣无缝；其他程序员必须能读懂你的代码。
2.在心烦意乱的状态下工作，只会造成严重的浪费
3.疲劳的时候千万不要写代码，奉献精神和职业素养，更多意义上指要遵守纪律原则而非长时间的工作狂。
4.关于高效率状态，大家已经写了很多，这种状态通常被称为“流态”。有些程序员将之称为“流态区”、不管用什么名字，你可能都不陌生，甚至有过这种体验。这是程序员在编写代码会进入的一种意识高度专注但思维视野却会收拢到狭窄的状态。在这种状态下，他们会感到效率极高:在这种状态中，他们会感到“绝无错误”。因 此他们一直苦苦追求进入这种状东，并经常以能在那种状态下维持多久来衡量自我价值。一些曾经进入这种状态但终又从中摆脱出来的人给出了一点儿忠告: 避免进入流态区。这种意识状态并非真的极为高效，也绝非毫无错误。这其实只是一种“浅层冥想”状态，在这种状态下，为了追求所谓的速度，理性思考的能力会下降。让我说得更清楚些。在流态区，你可能可以敲出更多的代码。如果你当时正在做TDD，你会更快速地重复“红/绿重构”循环。你会收获一种愉悦感或征服感。问题在于，在流态伏态下，你其实放弃了顾及全局，因此，你很可能会做出一些后来不得不推倒重来的决策。流态区写代码可能会快些，但是后面你将不得不更多地回头重新审视这些代码。
5.创造性输出来源于创造性输入
6.由于某些原因，软件开发人员会认为调试时间并非编码时间。衡量你是否是一名专业人上的一个重要方面，便是看你是否能将调试时间尽量降到最低。绝对的零调试时间是一个理想化的目标，无法达到，但要将之作为努力方向。
7.软件开发是一场马拉松，而不是短跑冲刺。
8.你总有一天会遭遇延迟的情况。即使最优秀的程序员、最敬业的员工，也不能避免碰到延迟，管理延迟的诀窍，便是保持早期检测和保持透明。
9.如果经理极力要求你尽力赶上最后截止期限，那该怎么办呢? 如果经理坚持要求你“按期完成”该怎么办? 坚决维持你的估算!你最初的估算比你在老板在面前时做出的任何调整估算都要准确得多。告诉老板你已经考虑过所有情况(因为你确实已经这么做了)，唯一能够加快进度的方法便是缩减范围。不要经受不住诱惑言目冲制。如果可怜的开发人员在压力之下最终屈服，同意尽力赶上截止日期，结局会十分悲惨。那些开发人员会开始抄近路，会额外加班加点工作，抱着创造奇迹的渺茫希望。这是制造灾难的最佳秘决，因为这种做法给自己、给团队以及利益相关方带来了一个错误的期望。这样每个人都可以避免面对真正的问题，把做出必要的艰难决定的时机不断后处。其实快速冲刺是做不到的。你无法更快地写完代码。你无法更快地解决问题。如果试图这么做，最终只会让自己变得更慢，同时也只能制造出一堆混乱，让其他人也慢下来。因此，必须明白告诉老板、团队和利益相关方，让他们不要抱有这种期望。
10.加班确实有用，而且有时候也有必要。有时候，通过一天工作10个小时再加上周未加一两天，你确实能够达成原本不可能的进度。但这么做的风险也很高。在额外加班20%的个作时间内，其实你并无法去完成20%的额外工作。而目，如果连续两三周都要加班工作。则加班的措施必败无疑。因此，不应该采用额外加班加点工作的方案，除非以下三个条件都能满足:(1)你个人能挤出这些时间: (2) 短期加班，最多加班两周: (3) 你的老板要有后备预案，以防万一加班措 施失败了。最后一条至为关键。如果老板无法向你清楚说明加班方案失败的后备预案，那么你就不该同意接受加班方案
11.在程序员所能表现的各种不专业行为中，最糟糕的是明知道还没有完成任务却宣称已经完成。
12.如果没有什么事情是在必需完成之列，那么定义“完成”直是太容易的一件事情了。
13.如果一个团队陷入到此种误区之中，管理者听到的将是诸事顺利。所有的状态报告表每个人的工作完成得都很准时。这就像是一群盲人坐在铁轨旁边野餐: 没有人能够看见满载未完成工作的火车马上将会把他们压垮，而等他们发现时，一切都已经来不及了。
14. 编程很难，事实上，仅凭一已之力无法写出优秀的代码，即使你的技能格外高超，也肯定 能从另外一 名程序员的思考与想法中获益。
15.互相帮助是每个程序员的职责所在。作为专业人士要以能够随时帮助别人为荣。
16.如同要以乐于助人为荣一样，也要以乐于接受别人的帮助为荣。
17.程序员大多自负。固执、内向。我们不是因为喜欢和人打交道才做这一行的。大多数人之所以选择以编程为业，是因为喜欢沉浸于弄清各种细枝末节和摆弄各种各样的概念，以证明自己拥有这个星球上最发达的大脑，而厌恶陷入与他人交流的错综复杂的混乱之中
18.对于我们大多数人而言，既然协作并非我们自身的天性，那么我们就需要通过纪律原则来驱动大家良好协作。