本书作者：Ka Wai Cheung
花了几个小时把本书阅览了一遍，然后把个人觉得重要的一些方面做下记录。
这是一个Web程序员，设计师写的关于项目和编码方面的一些经验和建议。
本文是我自己个人根据本书提纲做的一些自我总结
1. 我们在处理代码时需要注意的一些问题
- 规划完备，再开工：
当我们拿到一个项目，或者一个只有模糊概念的想法的时候，我们第一阶段要做的不是立马开始写代码，而是弄清楚需求，再需求和项目经理或者客户确认的前提下，开始做第一次尝试（即生成一个虽然不完美，但是可以实现功能的版本）如此迭代。- 丢掉旧代码：
丢弃那些埋藏在代码中，影响你观看当前代码，可能是之前老想法的注释代码，因为这些占用了你的代码空间，而且不一定会用到。周期性对这些代码进行辨别和删除。- 鱼和熊掌可以兼得：
项目代码一般涉及好几个方面的内容，可能你只是精通一块，但是为什么你不能都精通呢？其实是可以的，根据专家理论，当你在一个领域精通的时候，你去学习其他相关领域相对会变得容易的。所以，首先，我们要在某个方面变成专家，然后，在过程中对其他的相关领域保持持续学习热情。
2.工作的动力和保持效率
- 动力驱动：
写代码是一项需要创造力的劳动，如果你没有动力，也会失去创造力和执行力。所以我们要从工作本身来获得动力。对某个项目/模块的喜欢，对某个模块攻克的成就感，等等，这些都会是我们工作的动力。但是注意，在其过程中，追求完美是好的，切记太过，毕竟产品是有时间限制的，没有完美的产品，只有不断打磨的产品。- 保持精力：
为了让工作有动力和激情，你需要保持自己的精力。休息会是补充你体力的一剂良药，一边吃饭一边写代码并不会提高你的代码效率。有技巧的休息，运动来提高和保持自己的精力才是。- 清醒时的工作次序：
我们可以在头脑比较清醒的时候做一些测试，或者说难的模块的构建。因为当我们写了一天代码的时候，容易陷入固有逻辑，而忽略一些边界等问题，所以在头脑清醒的时候测试是比较好的选择。一般是睡了一觉之后的清晨。- 第一印象未必准确：
产品给人的第一印象未必是好的，但是不能因为这个第一印象就直接进入自我否定。
不好的原因一般有两个：1.不熟悉 2.关注了次要问题。
你要坚持自己的想法，然后和客户沟通一些设计原理和用法，并让其适应几天。如果有问题，那只需对软件进行修改，但是最初的负面印象一般都会消失。
3.生产力
- 警惕没有时间线的消闲项目：
所谓消闲项目，就是你有个想法，并用代码实现，但是你并没有设定时间线，有时间就做，没时间就不做，这种项目很容易就变成烂尾。时间就是一切，你对手上项目的了解度也会随着搁置的时间长度而变生疏。解决方法：1.设定可持续的日工作量（每日间隔不能超过一天）2.完成时间也需要预设一个时间用来进行测试 3.我们的时间是“够用”。在设定的时间内，我们产出一个基本够用无需完美的软件
4.在完成了够用的软件后，我们对后期的功能增添和问题修改再设定时间线，然后如此循环。
第一步的产出够用软件时间设定很重要- 设定原则：
我们要设定各种限制因素，时间，资源等，如果没有限定，那么项目结果并不会好。
设定时间的时候，我们不需要对特别小的细节设定精确时间，只要模块或者整体交付时间即可满足要求。太细了会影响开发的发挥。- 二是个神奇的数字：
每天改进产品的两个方面，二是个神奇的数字，一太少太轻，三太多太重，二可以被我们很容易的接受和做到。- 设定免打扰时间：
整块的不被切碎的时间可以让你更有效率的思考和工作，所以设置免打扰时间段也是提高效率的一种方法。比如，每天上午，下午，晚上，分别划分一个维持2小时或者一小时的免打扰时间段。这段时间用来学习或者工作，不要被邮件，信息，电话等打断。- 代办列表清单：
什么都用脑袋记，会让我们的脑袋沉重，我们把过去，现在，未来要做的事列入清单，每天查看清单并进行调整即可。这会让你间歇性遗忘要作什么得到缓解。- 工作环境很重要：
工作环境直接影响了你的工作效率，所以，为工作环境投资是很值得的，这就像用称手的工具做事会更有效率是一个道理。- 避免我们：
我们用词很容易让人忽略责任人，当我们沟通的时候，用明确的某人，或者某某团队来比较有针对性。就像在公众场合遇到危险，寻求帮助的时候，指定某个特征的人来帮你，会比说大家帮帮忙来的好用。“我们”会把当事人变成旁观者，不要小看语言的力量，- 自治小团队：
熟悉其中人的工作方式且协调好的团队会让工作效率更高，好的团队会有好的效率，相应的，差的团队也是。
4.控制好复杂性
- 变数：
变数让复杂性不可避免存在于我们的生活中。但是记住，简单的才是最好的，人对简单的事物有着天生的亲切感。- 简单并不简单：
虽然我们总是希望事情可以简单，但是，简单呈现的背后并不简单，我们要勇于删除不必要的复杂性。但是复杂性可能是我们来判断一个事情高端与否的关键，我们往往不会认为一个简单的想法很有创意。我们要做的是复杂事情简单化，用看似简单却又是经过一系列判断和删选之后的精妙。
所有美丽的事物都是简单的，就算看起来复杂，也是简单的结构组合的。一般我们不会认为一团杂乱无章又千头万绪的线团是美丽的。
不要害怕简单，我们会畏惧简单而把事情想的复杂，可以逻辑复杂，但是要简单结构，简单呈现。记住，90%的人用的都是那10%的简单功能，要勇于砍掉不必要的资源浪费功能。- 难编意味着难用：
当一个需求来的时候，不要急于设计，首先要思考这个需求是否有非代码就能解决的简单途径，因为有些需求其实不需要代码。而是需要其他的。比如电梯内的时间，与其如何加快电梯到达的时间，不如想想如何使人觉得在电梯里的时间很快（如安装镜子，照镜子会让人觉得时间很快就过去了）。
而如果用代码来实现控制电梯的功能，这会是个复杂，而且状况很多，且难处理，难使用的功能。- 重构需谨慎：
当我们项目有个可以执行的初稿的时候，我们可能会基于个人的判断和对项目后期的把握引入设计模式了来对代码进行重构，以方便后期可能扩张的需求和更改的条件。但是，这里需要注意的是，需求可能并不一定会像你想象的方向改变，你需要谨慎对待你可能是狭隘的设计。这里就要重申，变化，是一直存在的。
有所预见，但谨慎预见。无论大的模式还是小的模式改动，进行重构的时候，都要知道你会得到什么，失去什么。
5.教学不易
- 好的程序员未必是好的老师：
当我们成为某个领域的专家时，我们会忘了，当我们对这个领域一无所知的时候需要如何快速了解这个领域的。- 想想初中老师：
小学或者初中老师给我们讲课的时候，会用浅显易懂的例子来给我们呈现。
对于有些深奥的问题，也可能会给一个不是那么对，但是可以让我们有进一步了解的认值。我们在有认值的基础上继续学习，就可以修正我们的认知了。（我印象特别深刻的是，以前有个老师，他说，然后补了一句，虽然这不完全对，但是你们先理解这个，以后你们学到就会知道的）- 为什么：
试图让学习者主动去了解学习模型的原理。从“如何”，“什么”到“为什么”。我一直都觉得，在你对一个事物没有认知的时候，你无法提出问题，只有有一定了解了，越了解，越能提出好问题。
在学生提出为什么的时候（通常是他们觉得有更好的办法），让他们分析其更好方法的优缺点。如此，这样提出的方案会越来越好。
6.客户
- 令人头大的客户：
客户通常给人的感觉是刁钻的，因为如果是非专业人士，那么他对复杂度并不了解，只关心可以看到的产出。甚至会提一些看起来简单，但是实现起来并不简单的功能。让他们对项目的复杂度了解是很重要的，同时也需要进行沟通来弄清真实想法。毕竟，通常人说话的内容，未必是真实想要的内容（这个就是语言和感觉的鸿沟了）。- 软件的价值：
在和客户打交道过程中，价值不仅仅就是你提供的软件，你在交流过程中，态度，声音，是否关心对方需求，为对方考虑，等等，这都是你的价值。所以，这不仅仅是个技术活，同时也是双方了解的过程。面谈，电话，都会比邮件，信息沟通来的管用。
7.代码书
- 拿来主义：
有很多现成的已经实现了的美妙模块了来实现你需要功能的一部分，你仅需要拿过来用就行了。
只是需要注意的是，你依旧需要良好的基本功来对模块底层的原理有所了解，并最好能修改。
如果只是黑盒使用，我们可能会错过很多美好的思想。- 体力劳动：
当你发现你需要做很多重复的事情的时候，你需要警惕，你是不是退化成了机器人，只有机器人才可以不辞辛苦的做重复的事情，而这些事情就是我们通过编程来帮我们做的。
如果你有很多重复事项，可以考虑自动化：代码生成，批量处理，脚本控制等等。来把重复事件提炼规则，让程序帮你实现。
8.形象
- 面子问题也很重要：
就像现在流行的美食节目，平淡无奇的食材，在镜头的渲染下，变得美味可口，就简单的新鲜，饱满这些词都可以让我们味蕾大开。
同样的，我们的程序无论内部代码写的再精美，设计再绝伦，如果不能通过某些方式呈现，并让人了解。人们是无法对不知名的黑盒产生欲望的，就算是好奇心，也是需要通过方法激发的。
要对自己所做的事感到自豪，在打磨技能的同时，也要注意对外的沟通。
总结：综上就是我对本书的总结，拎出来一些我喜欢且认同的观点进行阐释，有些我是深有所感，就算不是客户，有时候公司内部也会出现同样的情况，毕竟，只有写代码的人，才对内部真正了解。而不了解的，要的是看起来以为然。我学不来面子功夫，但是想着，技能积累到一定程度，总会走通的。