程序员修炼之道

Berterand Meyer 为 Eiffel 语言发展了按合约设计的概念。这是一种简单而强大的技术，他关注的是用文档记载并约定软件模块的权力与责任，以确保程序正确性。程序的正确性就是做它声明要做的事情的程序。用文档记载这样的声明，并进行效验，是按合约设计的核心所在。 前条件：为了调控例程，必须为真条件；例程的需求。 后条件：例程保证会做的事情，例程完成时世界的状态。 类不变项：类确保从调整者的视角来看，该条件总为真。 使用 DBC 的最大好处也许是他迫使需求与保证的问题走到前台来。在设计是简单地列举输入域的范围是什么、边界条件是什么、例程允诺交付什么——或者，更重要的，它不允诺交付什么——是向着编写更好的软件的一次飞跃。 检查每一个错误是一种良好的实践。但是在实践中这可能会把我们引向相当丑陋的代码；你的程序的正常逻辑最后可能会被错误处理完全遮蔽。 只要在编程，我们都要管理资源：内务、事务、线程、文件、定时器 ——所有数量有限的事情。大多数时候，资源使用遵循一种可预测的模式：你分配资源、使用它，然后解除其分配。 类似于间谍、反政府人员、革命者以及类似的人组成的小组，在代码种也有一种类似的最小组成单位：模块。把代码组织成最小单位并限制他们之间的交互。如果随后出于折中必须替换某个模块，其他模块仍能正常工作。 再多的天才也无法胜过对细节的专注。细节会弄乱我们整洁的代码

第五章:弯曲，或折断 1.解耦与得墨忒耳法则 函数的得墨忒耳法则试图使任何给定程序中的模块之间的耦合减至最少，它设法阻止了你为了获得第三个对象的方法的访问而进入某个对象，写代码的时候要使模块间的耦合减至最低，避免了牵一发而动全身的可能性。我们应该跟多的考虑如何怎样进行设计，使系统中的事物保持逻辑上的解耦。使用该法则可以我们的代码适应性更好。可以使用委托来使服从墨忒耳法则更容易。 2.元程序设计 让我们的系统变得高度可配置。要配置，不要集成。 元数据使关于数据的数据，是对应用进行描述的数据。 要用元数据描述应用的配置选项：调谐参数，用户偏好，安装目录等。元数据不仅能用来配置简单的偏好，也要尽可能多的通过元数据配置和驱动应用。 将抽象放进代码，细节放进元数据。这句没有很理解。 这种方法有若干好处:1）它迫使你解除你的设计的耦合,从而带来更灵活、可适应性更好的程序。 2）它迫使你通过推迟细节处理,创建更健壮更抽象的设计一完全推迟到程序之外。 3）无需重新编译应用,你就可以对其进行定制你还可以利用这一层面的定制,轻松地绕开正在运行的产品系统中的重大bug。 4）与通用的编程语言的情况相比,可以通过一种大为接近问题领域的方式表示元数据。 5）你甚至还可以用相同的应用引擎—一但是用不同的元数据——实现若干不同的项目。 建议以纯文本的方式配置元数据

解耦与得墨忒耳法则 把自己的代码组织成最小组织单位（模块），并限制他们之间的交互，如果随后处于折中必须替换某个模块，其他模块仍然能够工作。 使耦合j减少 有许多不必要的依赖关系的系统难以维护，往往高度不稳定。为了使依赖关系保持最少，我们使用得墨忒耳法则设计我们的方法与函数。 函数的得墨忒耳法则 函数的得墨忒耳法则试图使任意给定的耦合减少到最少，它设法阻止你为了获得对第三个对象的方法的访问而进入某个对象 元程序设计 细节会弄乱我们整洁的代码，特别是如果他们经常变化，每当我们必须去改动代码，以适应商业逻辑，法律或者管理人员个人一时的口味的某种变化，我们都有破坏系统的危险， 时间耦合 时间是软件架构的一个常常被忽略的方面。吸引我们的时间只是进度表上的时间，发布之前剩余的时间，但这里不是我们在谈论的时间，相反，我们谈论的是作为软件自身的一种要素的时间的角色，时间有两个方面对我们很重要，并发和次序。 来源： https://www.cnblogs.com/sunhongbin/p/11947139.html

由于最近的作业任务比较重，所以这次的阅读笔记发表的比较晚。超出了老师的预计时间。 首先说一下我最近学习的感受，比之前有压力，最近老师留的任务相对于之前都是比较联系实际，更优化与课本。更加理解 了思路和框架的重要性。但是我对于这本书的后几张学到的知识非常浅薄。有必要再次进行阅读。 首先对于框架来说，我们现在接触的项目比较少，且比较小，对于框架的理解还不够透彻，需要自己课后的学习； 然后是代码的整洁性，上课老师说大部分就业单位几眼便可大体的给我们的代码一个定位，主要是三点，其一为命名，命名要规范，要有意义； 其二：代码的缩进 根据代码的缩进格式可以看出整体代码的整洁度；其三：代码的注释 这一点是必备的，在自己能力的基础上尽量采取英文。 这些是我认为在目前来，我学到最切实际的知识，所以我把他写下了，并时刻提醒自己。 来源： https://www.cnblogs.com/hhjing/p/11797727.html

16 强力编辑 知道vi好，但是只会那么几个简单的命令，而且，通常我总是在windows下面工作，所以通常用crack的UltraEdit。不少实用的功能，加速编辑。倒是IDE的快捷键记住了不少，在实际工作中，发挥了很大的作用。 书上提到仍有不少人使用windows notepad写代码，我虽然不至于此，但倒是习惯使用它来写文章，记录东西，然而就在刚才，发现手工输入的东西都会出现几个黑色的黑框，可见一定要选择足够好的编辑器才行，何况，windows notepad只能撤销一次，而且你也不会知道撤销的到底是你那次的输入。 17 源码控制 凡是工作过的程序员，没有不用源码控制工具的吧？只是选择有所不同。 18 调试 学习编程，觉得和其他人最不一样的地方在于两点，一是自己思考程序的流程，写下代码之前，知道代码将要（预期）执行的顺序逻辑，二是会调试代码，出现错误时不像一般人完全不知道该如何是好，而是去调试来寻找出错的原因。我相信，现在还是有不少工作了的程序员，不习惯去调试，他们期待的是自己的代码都是一次编写就能正确无误的执行，如果不行，那么别人大概可以帮忙解决。 一直以来，一直觉得，一个程序员的经验丰富情况很大程度依赖于他遇到的bug并解决的数量，所以一个人代码写的越多，解决的问题越多，那么他下次遇到问题时就越容易很快的定位。所以，有时候遇到问题并且成功的选择另外一个方案绕过去以后

7 重复的危害 有时候是copy paste大法带来的后果，有时候是为了省事，总之，一份功能相同的代码在多处出现，更要命的是，需要修改这部分代码！这个可以毫不客气的说就是灾难，所以在设计，在编码初期就要有良好的规划，尽可能避免重复。实际工作中，发行有时候，尽管想要刻意避免，但是还是会出现。其中一个重要原因在于程序员的偷懒，还有是在于模块的可访问性。尤其是两个模块没有任何公用模块的时候，如何避免重复，或者说人工重复才是问题的关键，即使是build脚本去让两个模块出现相同的东西，也比人为维护两个东西都要好上千万倍。 8 正交性 模块耦合，代码耦合，分层分模块，善用设计模式。正交的目标只有一个，让系统富有弹性，可以随需应变。 9 可撤销性 还是系统的可变性，是否可以快速应付其中一些改变而快速改变。通常我们用面向接口的方式来做到这些。在前人的基础上，我们有corba ，com，ejb，webservice，odbc，jdbc等等让我们快速应变的基石，但是总有一些依赖我们自己的东西，接口，接口！ 10 曳光弹 很炫的名字，可惜就是在讲poc，Prove of Concept ，的确很有用。 11 原型与便笺 原型，没别的，常用的东西。 12 领域语言 不同语言有不同的优势，关键在于扬长避短，合理运用，有时候组合起来事半功倍。 13 估算 开始前做好计划，过程中最终计划，磨刀不误砍柴工。 14

由于9月份忘记了写阅读报告，导致十月份要把之前的阅读报告补上。 《程序员修炼之道——从小工到专家》这本书的启迪点总是很有趣，以我的旧观念看，我总以为这类书会是很枯燥无味，读起来令人昏昏欲睡的。可是不然，这本书不仅干货十足，还以一些趣味故事来阐述道理。比如煮石头，煮青蛙等。程序，是程序员写出来的。是基于人的思想而产生的。所以，想要写好代码，首先得端正自己的思想。也不是端正吧，就是在一些细节出来好自己的想法以及心态。所以此书前面的部分写的都是如何规整自己， 首先，要对自己的行为负责。将来在公司工作，难免会有大大小小的事。比如说你的源码出了问题，但有可能不是你造成的。这些错误不要将责任推给其他人，你的同事和所谓的“猫”都是无辜的。错就是在你。要有责任感。而不是在学生时代你说明事物的起因经过结果就会有导员理解你放过你。步入社会，要对自己的行为负责，如果不想负责，那就提前准备好，将源码备份，文档备份什么的。准备工作做足了，就不会有担心顾虑了。 做事一定要干净利落。你的代码有暗病，不美观不规范，这不仅仅影响你自己，还会影响你的团队甚至你的公司。就像我们的建民欧巴给我们讲的，我们现在编的代码都是小case，都是在我们的温室下编的，一些小问题不足以造成什么影响，将来到公司，一个大工程几百个包几千个源码，这时候一旦有点纰漏，比如接口出了问题，整个程序都会崩溃。就像雪崩，没有一片雪花是无辜的

书中说到我们需要估算工程所需的时间，作为一名刚进入软件工程的我，还没有接触到什么大的工程，但是做了一些复杂度还行的作业，那些作业就是工程的缩影，一个工程我们需要估算出每个工程模块所需的时间，就好比我们写出某个类，或者实现一个比较复杂的算法所需短时间，我们目前的估算时为了作业不会晚交，工程上的估算时间是为了不延误了合同日期。 一个具有强大编辑能力的编辑器是一个好程序员必不可少的功能据，我们的码力和工具有着不少的联系，在具有良好的工具之上，我们还需要有一个经常调试的好习惯，不能等到自己的某个工程模块全部 “写完”再进行调试，对自己所码写的代码进行细分对某个方法组，或者某个工具类进行单独的调试。代码是不会说谎的，除了一些环境和编辑器等问题，在你确定你的编辑器和环境等外部环境没问题是，那么你就要相信是你自己的代码出了问题，要通过加一些可视化的东西找到自己的出错部分，在最短的时间内进行修改。 我们自己的执行能力很大一部分决定了我们上面所讲的估算和码力等问题，我们一定要让自己具有强大的执行能力。 在学生时期的我们有很多与书中所讲的类似的情况，现在想想我真的经历了书中的很多所讲的事情，而且还有一部分自己还是没有解决，在读了书之后可能会有不同与之前的感觉，虽然现在还没读完，但是我看目录，看到了将来模糊的自己，加油。 来源： https://www.cnblogs.com/yizhixiaozhu

在第二章中，我知道了注意时效的重要性，然后在第三章，我了解到了我们如何去运用基本工具去让我们的时效性增强 第三章开头就有一句话让我的记忆十分深刻，那就是作为注意时效的程序员，我们手中的基本材料不是木头，不是铁块，而是知识，我们搜集顾客的需求，然后将其转化为知识，随后又在我们的设计，实现，测试，以及文档中表达这些知识。 xml，sgml，html都是良好定义的结构的纯文本的例子，我们可以通过纯文本，做到某种二进制的能做的每一件事，包括这版本管理 然而纯文本也具有一定的缺点，存储空间较大，处理纯文本文件，计算需要的代价可能更大(不太明白为什么需要的代价较大，后续补充！） 但是与二进制相比，纯文本较为安全。 虽然更大和更慢，但是纯文本更为人们所接受，因为保证不过时，还能起到杠杆作用，更易于测试。 投入一些精力去研究shall命令，它可以让我们的时效性增加 来源： https://www.cnblogs.com/sunhongbin/p/11762812.html

第三章:基本工具 1.纯文本的威力 具有良好定义的结构的纯文本，用纯文本保存知识，可以获得自描述的，不依赖于创建它的应用的数据流。 缺点：与二进制相比所需的存储空间更大；处理代价高。 优点：保证不过时；杠杆作用；更易于测试。 2.shell游戏 熟悉shell使自己的生产率提高。 3.强力编辑 最好精通一种可配置、可扩展、可编程的编辑器，并将其用于所有编辑任务，适当了解其他编辑器。 4.源码控制 能够追踪到你在源码和文档中做出的每一处变动，更好的系统还能追踪编译器及OS版本，有了适当配置的源码控制系统，你就总能返回你的软件的前一版本，极大地提高了开发效率。 源码构建是可重复的，因为你总是可以按照源码将给定日期的内容进行重新构建。 5.调试 调试的目的是为了解决问题，我们要做的就是修正问题，而不是发出指责。 遇到令人吃惊的bug时，进行修正，确定之前为什么没有找出这个bug，考虑你是否要改进单元测试或其他测试，以让它们有能力找出这个故障。如果bug是一些坏数据的结果，看看这些数据经过了那些层面，是否能尽早的进行隔离。 开始查看bug前，首先要确保程序能够成功编译，把编译器警告级设定的最高，准确观察，搜集相关数据，与发现bug的人进行交谈更为直接；必须强硬的测试边界条件，面面俱到的测，还要测试现实中的使用情况。 使数据可视化，调试器通常会聚焦于现在的状态