《构建之法》第4.17章读书笔记
第四章
原文语句：
异常不能跨过DLL或进程的边界来传递信息，所以异常不是万能的。
提出问题：
1.什么是DLL？DLL是来解决什么问题的？
网上说法：
DLL是Dynamic Link Library的缩写，意为动态链接库。在Windows中，许多应用程序并不是一个完整的可执行文件，它们被分割成一些相对独立的动态链接库，即DLL文件，放置于系统中。当我们执行某一个程序时，相应的DLL文件就会被调用。一个应用程序可有多个DLL文件，一个DLL文件也可能被几个应用程序所共用，这样的DLL文件被称为共享DLL文件。
它允许进程共享执行特殊任务所必需的代码和其他资源.比较大的应用程序都由很多模块组成，这些模块分别完成相对独立的功能，它们彼此协作来完成整个软件系统的工作。可能存在一些模块的功能较为通用，在构造其它软件系统时仍会被使用。在构造软件系统时，如果将所有模块的代码源都静态编译到整个应用程序 EXE 文件中，会产生一些问题：一个缺点是增加了应用程序的大小，它会占用更多的磁盘空间，程序运行时也会消耗较大的内存空间，造成系统资源的浪费；另一个缺点是，在编写大的 EXE 程序时，在每次修改重建时都必须调整编译所有源代码，增加了编译过程的复杂性，也不利于阶段性的单元测试。
Windows 系统平台上提供了一种完全不同的较有效的编程和运行环境，你可以将独立的程序模块创建为较小的 DLL 文件，并可对它们单独编译和测试。在运行时，只有当 EXE 程序确实要调用这些 DLL 模块的情况下，系统才会将它们装载到内存空间中。这种方式不仅减少了 EXE 文件的大小和对内存空间的需求，而且使这些 DLL 模块可以同时被多个应用程序使用。Windows 自己就将一些主要的系统功能以 DLL 模块的形式实现。
一般来说，DLL 是一种磁盘文件，以.dll、.DRV、.FON、.SYS 和许多以 .EXE 为扩展名的系统文件都可以是 DLL。它由全局数据、服务函数和资源组成，在运行时被系统加载到调用进程的虚拟空间中，成为调用进程的一部分。如果与其它 DLL 之间没有冲突，该文件通常映射到进程虚拟空间的同一地址上。DLL 模块中包含各种导出函数，用于向外界提供服务。DLL 可以有自己的数据段，但没有自己的堆栈，使用与调用它的应用程序相同的堆栈模式；一个 DLL 在内存中只有一个实例；DLL 实现了代码封装性；DLL 的编制与具体的编程语言及编译器无关。
在 Win32 环境中，每个进程都复制了自己的读/写全局变量。如果想要与其它进程共享内存，必须使用内存映射文件或者声明一个共享数据段。DLL 模块需要的堆栈内存都是从运行进程的堆栈中分配出来的。Windows 在加载 DLL 模块时将进程函数调用与 DLL 文件的导出函数相匹配。Windows 操作系统对 DLL 的操作仅仅是把 DLL 映射到需要它的进程的虚拟地址空间里去。DLL 函数中的代码所创建的任何对象（包括变量）都归调用它的线程或进程所有。
我的理解：
DLL是存放各种程序函数等内容的一种文件，是一种相对独立地动态链接库，当我们执行程序时，就要从系统中调用多个DLL文件如果想从·其他进程https://blog.csdn.net/shenzi/article/details/4739746共享内存，必须使用内存映射文件或者声明一个共享数据段，一个DLL文件也可以被多个应用程序使用。当我们无法跨越进程地址空间的边界时，我们就需要“DLL注入”技术，将DLL注入到进程地址空间中。这些都是DLL注入的方法和例子：https://blog.csdn.net/zm_21/article/details/52654482、https://www.cnblogs.com/5iedu/p/5180828.html，在我们生活中也经常遇见DLL文件，比如exe文件等。
原文语句：
领航员：审阅驾驶员的文档；监督驾驶员对编程等开发流程的执行；考虑单元测试的覆盖率；思考是否需要和如何重构；帮助驾驶员解决具体技术问题。领航员也可以设计TDD中的测试用例。
提出问题：
什么是重构？重构的目标是什么？
网上说法：
1、 代码重构（Code refactoring）重构就是在不改变软件系统外部行为的前提下，改善它的内部结构。软件重构需要借助工具完成，重构工具能够修改代码同时修改所有引用该代码的地方。在极限编程的方法学中，重构需要单元测试来支持。
重构（），通过调整程序代码改善软件的质量、性能，使其程序的设计模式和架构更趋合理，提高软件的扩展性和维护性。 也许有人会问，为什么不在项目开始时多花些时间把设计做好，而要以后花时间来重构呢？要知道一个完美得可以预见未来任何变化的设计，或一个灵活得可以容纳任何扩展的设计是不存在的。系统设计人员对即将着手的项目往往只能从大方向予以把控，而无法知道每个细枝末节，其次永远不变的就是变化，提出需求的用户往往要在软件成型后，才开始"品头论足"，系统设计人员毕竟不是先知先觉的神仙，功能的变化导致设计的调整再所难免。所以"测试为先，持续重构"作为良好开发习惯被越来越多的人所采纳，测试和重构像黄河的护堤，成为保证软件质量的法宝。
2、通过重构可以达到以下的目标：
·持续纠偏和改进软件设计
重构和设计是相辅相成的，它和设计彼此互补。有了重构，你仍然必须做预先的设计，但是不必是最优的设计，只需要一个合理的解决方案就够了，如果没有重构、程序设计会逐渐腐败变质，愈来愈像断线的风筝，脱缰的野马无法控制。重构其实就是整理代码，让所有带着发散倾向的代码回归本位。
Martin Flower在《重构》中有一句经典的话："任何一个傻瓜都能写出计算机可以理解的程序，只有写出人类容易理解的程序才是优秀的程序员。"对此，笔者感触很深，有些程序员总是能够快速编写出可运行的代码，但代码中晦涩的命名使人晕眩得需要紧握坐椅扶手，试想一个新兵到来接手这样的代码他会不会想当逃兵呢？
软件的生命周期往往需要多批程序员来维护，我们往往忽略了这些后来人。为了使代码容易被他人理解，需要在实现软件功能时做许多额外的事件，如清晰的排版布局，简明扼要的注释，其中命名也是一个重要的方面。一个很好的办法就是采用暗喻命名，即以对象实现的功能的依据，用形象化或拟人化的手法进行命名，一个很好的态度就是将每个代码元素像新生儿一样命名，也许笔者有点命名偏执狂的倾向，如能荣此雅号，将深以此为幸。
对于那些让人充满迷茫感甚至误导性的命名，需要果决地、大刀阔斧地整容，永远不要手下留情！
·帮助发现隐藏的代码缺陷
孔子说过：温故而知新。重构代码时逼迫你加深理解原先所写的代码。笔者常有写下程序后，却发生对自己的程序逻辑不甚理解的情景，曾为此惊悚过，后来发现这种症状居然是许多程序员常患的"感冒"。当你也发生这样的情形时，通过重构代码可以加深对原设计的理解，发现其中的问题和隐患，构建出更好的代码。
· 从长远来看，有助于提高编程效率
当你发现解决一个问题变得异常复杂时，往往不是问题本身造成的，而是你用错了方法，拙劣的设计往往导致臃肿的编码。改善设计、提高可读性、减少缺陷都是为了稳住阵脚。良好的设计是成功的一半，停下来通过重构改进设计，或许会在当前减缓速度，但它带来的后发优势却是不可低估的。
我的理解：
1、代码重构就是在你的代码中出现过大的类或者过长的方法、牵一毛而需要动全身的修改、类之间需要过多的通讯、过度耦合的信息链等问题时，在不改变软件系统外部行为的条件下，改变它的内部结构，从而达到改善软件的质量、性能，使其程序的设计模式和架构更趋合理，提高软件的扩展性和维护性作用。"测试为先，持续重构"，测试和重构成为保证软件质量的法宝。
2、重构的目标有：持续纠偏和改进软件设计、帮助发现隐藏的代码缺陷、有利于提高编程的效率、改善软件的质量，提高代码的可读性，使代码更加的符合人们的需求，促进软件的可持续发展，也为软件的质量提供也保障。
第十七章
原文语句：
人员（People）:参照RASCI模型，说清楚谁负责什么，谁不负责什么（说清楚谁不负责有利于大家放手工作）。
提出问题：
什么是RASCI模型？
网上说法：
无论一个科研项目计划本身多么完备细致，具体实施人员及负责分配方面的误解与疏漏总会客观存在，并引发一系列严重问题。
RACI模式旨在帮助大家落实项目定位、分配具体责任，并改善项目成果。据管理学家研究，大多数机构都未能有效处理或高度重视其中最为关键的一大决定性成功因素。所谓决定性成功因素，是指项目实施过程中参与者以及关键负责人的角色定位与责任细则。无论项目规划本身多么详尽完善，参与者与关键负责人在角色定位与责任细则方面的模糊及混乱几乎已经成为一种常态。在每一次着手对陷入困境的项目加以补救时，首先都应将这一因素当作需要优先处理的内容。
RACI模式是目前最简便、最高效的项目角色定位及责任分配方案，将RACI模式与机构的项目运作周期相结合，能够为整体工作带来最大化的效果提升及产出改善。
一、RACI模式中的四大角色定位RACI模式通过严谨的结构与细致的表述，帮助关键性项目负责人找到自己在工作中的准确定位。这套模式的主旨在于明确每个岗位的责任分工，并确保项目中的一切细节都与相应的“执行者”关联起来。在实施RACI模式时，我们首先要对项目中的每项任务、阶段性成果及关键决策进行收集整理，并明确哪些人对特定内容负责、哪些 人需要为特定内容提供咨询及指导意见。所谓RACI模式，四个缩写字母代表的是项目中普遍存在的四种主要管理角色：
负责人（R = Responsible）他们是工作中的“执行者，一切具体执行内容都由他们来掌控。他们的任务是完成目标、处理对象或者做出决策，而且在大多数项目中负责人角色彼此独立。
管理者（A = Accountable）: 扮演这类角色的工作人员可以说是任务的“拥有者”，一项任务、具体工作或者责任内容是否完成需要由他们来签字确认。管理者的职能是确保各项任务按预期分配给对应负责人。要让项目取得成功，必须确立惟一一位管理者，这样才能保证出现问题时问责机制能够立即发挥作用。
顾问（C = Consulted）: 这类角色需要在工作正式开展之前提出建议，并对讨论结果进行签字确认。他们始终处于讨论、审议实施效果、讨论的工作循环之中，并以参与者的角度全程监控。
指导员（I = Informed）: 这类角色需要时刻关注“发展蓝图”，他们的责任是在项目过程及决策环节提供指导意见，但并不会直接以顾问身份出现。而且他们的看法也不会直接影响任务或议程的结果，指导意见”或者说“参考意见”是他们对于管理者们的主要贡献。
除了RACI以外，RASCI和RASIC也都是用来描述变革过程中的角色、任务的。其中支持者（S= Support）是对任务提供支持, 辅助任务的完成的角色。以下主要介绍RACI模式的应用。
二、RACI模式的实际应用RACI模式的实际应用并不复杂，只需以下六个简单步骤，我们
1. 确定项目实施过程中涉及的所有具体任务，并在图表左侧按照优先级顺序将内容一一列出。对于项目而言，这样做能够最大程度地保证项目周期与交付成果之间的平衡。
2. 列出项目中所有相关负责人，并将他们在图表上方一一列出。
3. 将模式中的每个工作单元划分出来，并确定哪些人在其中扮演负责人或者管理者的角色。接下来考量工作人员的职业技能与知识背景，并为每项具体任务分配合适的顾问及指导员。
4. 确保每项任务都拥有至少一位主要负责人。
5. 每项任务最多只能分配一位主要管理者。这样做是为了避免同一项特定任务由于决策者过多而导致冲突或意见分歧。
6. 将RACI模式与团队中的主要负责人分享，确保大家都能够在讨论之后认同这种执行方案。在项目启动之初做好这些准备工作，能够防止未来可能出现的意见分歧或者沟通障碍等负面影响。下图所示的就是一套简化版的RACI模式，我们可以从中看到项目如何按特定流程转化为方案内容：
我的理解：
RASCI模型当中R是指负责人，A是指管理者，S是指支持者，C是指顾问，I是指指导者。RACI、RASCI和RASIC也都是用来描述变革过程中的角色、任务的，都是一种科学合理的具体实施人员及负责分配方面的模型，旨在帮助大家落实项目定位、分配具体责任，并改善项目成果。其中RACI模型是运用最简单、最快捷的模型。RACI模型是在专案管理或组织改造时常用的工具。任何一项流程改造或专案的活动，都不会自动发生，除非“人”让它发生，RACI就是协助你找到那个“人”及其他必要资源的有效分工计划工具。
原文地址：https://www.cnblogs.com/xieyy127/p/8684512.html