读书笔记week1——涂涵越

     这次读书笔记主要是就《程序员修炼之道》这本书的前半部分做一些总结以及发表一些自己的看法。

本书前面的一部分主要是一些程序员应该在工作中时刻注意的事情，一些关键的信息如下：

    1、处理问题的态度与责任。

    这是在本书序言中就提到的，可见其重要性。处理问题的正确态度以及对自己的行为负责是无论什么职业的人都应该注意的，而对于程序员来说，又有其特定的指向。首先，作为程序员，不能害怕暴露弱点，要敢于先呈现出不完美的代码，然后再去寻求改进。其次，负责还要求不要把问题归咎于他人。对于可能遇到的问题，都要有预先的计划。 “猫吃了我的源码”之类的说辞还是不要出现的号。。

    2、软件的熵理论

    熵就是事物的无序程度。这就像就像“破窗户理论”，我们要对破窗户零容忍。如果此时对软件代码或者决策上的一个小问题容忍，很可能导致非常严重的结局，或者书中所说的“软件腐烂”。

    3、灭火理论

    灭火理论就是一个情形，消防员为了不弄脏地毯，在灭火前先在地毯上铺上垫子。这个理论我还是第一次听说，这在现实生活中不能理解。但在软件编写中很重要，不能因为deadline，就放低自己代码的标准。

    4、石头汤

    有时候换一种方式，也许就能获得自己想要的东西。通过“要是增加……可能就会更好”这一方式，可能会比直接去要求某一样功能会更好。

    5、温水煮青蛙

    这个就很常见了，就是告诉我们要观察周围的事情。特别是对于程序员来说，周围的一切永远在时刻变化。

    接下来是一些更具体的内容。

    1、让用户参与权衡

    毕竟你的成品是要给用户使用的。

    2、使质量成为需求问题

    我很喜欢这个说法，编程就像绘画。先是勾勒全景，然后画背景，在描细节。然后对自己的画进行批判，如果不满意的画接着可能得重来。但编程的话，书里告诉我们要学会止步，因为代码不可能完美。先把不完美的代码呈现给用户，让用户的需求来改进它的质量。

    4、知识投资

    一是要定期投资，并且要多元化，不要全放在一个篮子里。因为你并不知道哪些知识在未来是最有用的。

    5、交流

    首先要知道自己想说什么，然后了解听众，把握时机，并且调整自己的风格，使之适应听众。以及还一个美观问题，也需要让听众参与。当然对于程序员来说，听众就是用户。

    6、DRY-“Don’t repeat yourself”

    减少重复。一是强行的重复。如注释问题，应该低级知识呈现在代码里，高级说明呈现在注释中。再就是一些无意的设计上的重复，比如结构的定义上，可以减少一些变量。还有就是无耐性的重复，比如拷贝代码。这一点我也很有体会，有时以为功能相似便去拷贝一份代码，结果改代码的时候出现了各种问题，最后还得反复调试，其实还不如重新写一份。

    7、正交性

    这个概念也是很新颖。运用了数学里的概念。正交即说明二者互相独立，可以独立地去修改其中的一部分。比如界面、数据库独立，我们可以单独修改一方。实现正交性就要无关事务的影响，这可以让代码更健壮。这一概念在团队合作上也很有用，将工作分区，一定程度上隔离，可以提高工作效率。这在代码上，具体也有避免相似的函数等措施。正交不仅便于测试，而且使代码具有可撤销性，即你可以通过很小的改动去撤销或修改某个功能。

    8、曳光代码与原型制作

    这一部分开始，书里的内容开始不是那么好理解。根据我的理解，曳光代码也可以看成是一个简单的、不完美的代码。很多时候，用户也不清楚自己真的需求。如果让他们及早看到未完成的产品，他们会因为能看到产品的进展而欣喜。就像晚上用曳光弹射击，我们可以知道距离目标还有多远，若总是停留在理论上的计算，很可能反而不能更快达到预期。

    它与原型制作的区别在于，原型制作是用过就扔的，而曳光代码仍然是最终系统的一部分。比如我们用轻木、胶带做了一个新车模型，这可以看成是原型制作。原型制作可以帮助我们分析风险、学习经验。而如果以车来打比方，曳光代码至少是能开上路的车，虽然它和真正的产品差距有很大。曳光代码允许一定程度忽略正确性、完整性、健壮性以及风格。

转载于:https://www.cnblogs.com/USTC-CC/p/8528407.html