《构建之法》第4.17章读书笔记

《构建之法》第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

时间: 2024-10-12 22:18:57

《构建之法》第4.17章读书笔记的相关文章

构建之法4,17章读书笔记

一.前言 经过上一次的阅读经验,这一次再阅读起来便顺畅得多了,顾名思义,这两章就是在讲我们如何在项目开发合作过程中更加顺利,软件工程既然有着"工程"二字,那就说明它并不是一个人的事情,软件工程离不开团队合作,而团队合作的最简形态就是两人合作. 二.分析与问题 引用:               既然代码复审能发现这么多问题,有这么好的效果,如果我们每时每刻都处在代码复审的状态,那不是很好么?事实上,极限编程(Extreme Programming)正是这一思想的体现--为什么不把一些卓

《构建之法》第13-17章读书笔记

第13章: 软件测试有许多种测试方法,有单元测试.代码覆盖率测试.构建验证测试.验收测试.回归测试.伙伴测试.效能测试.等等.还要写测试设计说明书,告诉别人如何测试,测试报告说明书该怎么写呢? 第14章: 质量保障软件的开发过程有三个主要的特性“好”“快”“便宜”.通俗的软件在功能.成本.时间三方面满足利益相关的需求.理解是测试的角色要独立出来么?独立出来的测试角色怎么才能发挥作用? 第15章: 稳定和发布阶段.一个里程碑结束了,团队接下来要干什么?产品怎么才能做得更好? 第16章: IT行业的

《构建之法》第三章读书笔记

看到第三章,发现软件工程开发一直强调团队的重要性,但同时,每个人也发挥着重要的作用,在一个开发团队中,每个人都是一个环,环环相扣才能实现软件的开发.在大部分成功的软件团队模型中各个角色考虑问题的出发点是有区别的.不同意见的冲突在所难免,一个好的团队流程能把冲突的积极方面(各自尽力把自己的工作做好,说服别人)释放出来,避免消极方面(因为冲突而产生的消极.抵触情绪等). 在团队中,IC需要做到:通过交流.实验.快速原型等方法,理解问题.需求或任务:提出多种解决办法并估计工作量:与相关角色交流解决问题

《构建之法》第四章读书笔记

本章理论和知识点有:代码规范.极限编程.结对编程.两人合作的不同阶段.影响他人的技巧 一.代码规范 1.代码风格规范.主要是文字上的规定,看似表面文章,实际上非常重要. 代码风格的原则是:简明,易读,无二义性 .包括了:缩进.行宽.括号.断行与空白的{}行.分行.命名.下划线.大小写.注释. 2.代码设计规范.牵扯到程序设计.模块之间的关系.设计模式等方方面面的通用原则. 包括:函数.goto.错误处理. 二.代码复审 包括:自我复审.同伴复审.团队复审 代码复审的目的: 1.找出代码的错误.

《构建之法》第五章读书笔记

第5章 团队和流程 一.非团队和团队 团队的共同特点: 1.团队有一致的集体目标,团队要一起完成这目标.一个团队的成员不一定要同时工作,例如接力跑. 2.团队成员有各自的分工,互相依赖合作,共同完成任务. 二.软件团队的模式 软件团队的模式最初是混沌的一窝蜂的形式:一群人开始写代码,希望能写出好软件.随着团队的成熟和环境的变化,团队模式会演变成下面几种模式之一. 1.主治医师模式:这样的软件团队中有首席程序员,他负责处理主要模块的设计和编码,其他成员从各种角度支持他的工作(后备程序员.系统管理员

《构建之法》第六章读书笔记

一.敏捷的流程简介 敏捷开发的原则是: 1.尽早并持续地交付有价值的软件以满足顾客需求 2.敏捷流程欢迎需求的变化,并利用这种变化来提高用户的竞争优势 3.经常发布可用的软件,发布间隔可以从几周到几个月,能短则短 4.业务人员和开发人员在项目开发过程中应该每天共同工作 5.以有进取心的人为项目核心,充分支持信任他们 6.无论团队内外,面对面的交流始终是最有效的沟通方式 7.可用的软件是衡量项目进展的主要指标 8.敏捷流程应能保持可持续的发展.领导.团队和用户应该能按照目前的步调持续合作下去 9.

构建之法1,5,17章读后感触

看了构建之法1,5,17章的内容,我对团队有了新认识.在一个团队中,不同成员来自五湖四海,为了一个目标,走到了一起.所以,需要的是全身心的投入.但人资历,成绩,口碑有差别,这就有了好/中/差,三等待遇,所以付出的努力不同,得到的待遇自然而然也就不同. 在我们这次软工中,我们需要一个真团队,高效的团队,来互相提升帮助我们完成这些任务.在这过程中,我们需要负担起身上的责任和要对伙伴负责.这样才能让团队走向成功

《构建之法》13~17章

第十四章:问题:本章主要讲的是软件的质量和对软件质量的保障工作.而且开发过程的可见性有非常差.那么在我们接到一个项目时如果没有能力去完成它,是否放弃这个项目.但是没有挑战就没有进步,这其中如何选择?第十五章: 问题:文中(288)的例子中提到很多程序员都想在开发或是修改的时候加一些功能进去,但是这往往是不允许的,那么我们如何在这中间找平衡.即允许加进我们想加的东西? 第十六章: 问题:如今科技发达,社会进步快,相对一些科技技术更新也快.但是却很难在旧的领域有创新,而新的领域又很难开发.那么当我们

《构建之法:现代软件工程》读书笔记

第一章 软件工程就是把系统的.有序的.可量化的方法应用到软件的开发.运营和维护上的过程.包括软件需求分析.软件设计.软件构建.软件测试和软件维护几个过程.涉及计算机科学.计算机工程.管理学.数学.项目管理学.质量管理.软件人体工学.系统工程.工业设计和用户界面设计等学科.不只是软件工程,其他工程(如机械工程)也可分为需求分析.设计.构建.测试和维护这几个阶段. 对其中的软件开发的不同阶段和航空产业的比较感觉挺有趣的.从玩具阶段的纸飞机到业余爱好者阶段的气球再到探索阶段的莱特兄弟,最后成熟产业阶段