人月神话阅读笔记—第三章一个由一流人才组成的小型的精干的队伍比由一群平庸的程序员组成的大型团队更有效率，但是这里面有一个重要的问题：如何在有意义的进度安排内创建大型的系统。优秀的程序员和较差的程序员之间生产效率的差距是巨大的，当一个10人的精干团队进行开发，和一个100个人的平庸程序员进行开发，前者的效率更高。但是对于效率和概念的完成性来说，最好由少数干练人员开发，而大型系统需要大量人员进行开发，但是这两者是有矛盾的，需要进行平衡。在开发过程中，可以使用一种崭新的开发方案，类似于外科医生做手术的人员安排方案：外科医生-首席程序员，定义功能和性能技术说明书，设计程序，写代码，测试以及书写技术文档；副手-外科医生的后备人员，可以完成任何一部分工作，但经验不足；管理员-项目的老板；编辑-创建各种文档；两个文秘；程序职员-维护编程产品库中所有团队的技术记录；还需要工具维护人员，测试人员，语言专家。这种开发人员方案是根本的转换了编程观念，将产品看成是团队的产物，而不是个人财产。这种方案相当于一个人完成问题分解，其他人给予所需要的支持。这种外科医生式的开发团队，保证了迫切性的需要，整个系统的代码方...

人月神话阅读笔记—序言及第一、二章初读人月神话这本书的前言和序言，觉得这本书在关于软件体系结构思想层次方面应该是很高的，而且它流传甚广，并且经过了40余年的沉淀，仍然经久不衰，可见此书的影响是相当深远的。从目录来看，此书说的不是如何进行程序代码的编写，更多的是关于软件工程中的管理问题，从很多的具体事例，和软件工程历史上发生的一些著名事件来引出章节的内容，以及通过这些具体事件，反映了一些什么样的问题和解决的办法。第一章的标题名为焦油坑，以开发过程中遇到的很多问题来比喻。介绍了编程系统产品所耗费的时间其实是很多的，接着介绍了作为程序员这个职业的乐趣所在，其实是一些简单纯粹的快乐。但是也有很多的苦恼，这本书会提供一些合适的方法。导致项目滞后或者最终不能完成的一个很重要的原因就是缺乏行之有效的进度安排。其中有很多的原因，不过一个主要的原因是人们对于整个过程过于乐观，认为一切都将正常运行。但是编程是一项思维活动，人在进行思维活动，难免会有缺陷漏洞，所以这种乐观主义本身就是不正确的。在进行开发时间估计上，对于一些可以分解并且互不干预的工作中，人越多，时间越少，但是软件开发是一项无法分解的任务，不会...

阅读笔记第十二章：用户体验在进行软件界面设计时，要考虑用户使用的第一印象，不要弄的多么纷杂，一定要一目了然，看起来简单明了。在软件的功能特别多的时候，要考虑用户的使用情况，可以大胆的减去一些不必要的功能，当然是针对某一部分用户来说。设计的过程中，一定要从用户的角度考虑问题。有一些功能，针对不同的用户，需求时不同的。而且作为一个软件的服务，始终都要记住用户的选择。在软件的长期使用过程之中，一定要让用户觉得软件是越来越好用的，这样的话，就要记住用户使用这个软件过程中的选择。在用户短期使用软件和长期使用的过程中，要让用户觉得用起来很方便，并且短期的使用和长期的使用，用户的感觉是不一样的。不要让用户犯一些简单的错误。在用户使用软件过程中，要尽量让用户使用软件不出现简单的使用错误。在用户体验和质量的关系上，如果足够高的质量影响了用户的使用体验，那么可能要试着降低一些产品质量，来取得较高的用户使用体验满意值。对于用户体验是有标准的：尽快提供反馈，系统界面符合用户的使用，用户有自由控制权，适合各种类型的用户等等。整个十二章总体来说就是，软件设计过程中，随时都要注重用户的使用体验，一切要从用户的角度考...

阅读笔记第十一章：软件设计与实现在第十一章的软件设计与实现方面，介绍了一些关于典型的开发流程和开发阶段的一些管理方法。在拿到设计文档之后，还需要做一些其他事情，比如估计任务所需要的时间，写一些原型代码，看看效果；做代码的自我复审，进行重构；写单元测试等等。最后还要把修改集集成到代码库中。开发人员有一个标准的工作流程：进行功能需求分析，复审设计文档，详细设计，实现设计来编写代码，同伴复审，源代码的合并、构建等等，其中的每一步都有可能出现bug，要随时发现并且修改bug，最后是测试完成，发布阶段。开发阶段的日常管理中，在开发阶段，要知道对其他一些不重要的事情拒绝，专心做开发的事情。另外开发过程中，碰到了软件缺陷，也不用着急修复，可以等到会诊之后进行修复。开发阶段的主要任务是完成既定的功能要求。在开发过程中，每日构建是很重要的，不管多忙，都要做。在进行构建的过程中，可以采取一些方法来让大家进行必要的每日构建。开发的测试阶段，软件会暴露出很多bug，这时需要集中修复软件的缺陷问题。...

阅读笔记第十章：典型用户和场景对于同一个工具，不同的用户使用的场景是不一样的。在定义典型用户的时候，需要分析不同用户之间的需求相同点和不同点。按照年龄，收入，使用软件的场景，和用户本人的生活情况进行分类。当然并不是给用户分类之后，就算完成了，还需要将用户置于这种用户的典型场景中，而不是泛泛的说用户如何使用这个工具。将场景用文字详细的描述出来，用户是如何使用这个工具的，并且在使用的过程中有没有遇到什么问题，都要详细的描述。这个时候就要把这些任务和场景联系起来，并且需要有人专门负责整体的结构。同时开发过程中，需要写一些规格说明书，功能说明书，技术说明书等等。在写功能的过程中，需要有一些步骤，比如先构造总体模型，然后是构造功能列表，下一步是制定开发计划，然后是就到了功能的设计阶段，最后是要实现具体的功能了。典型用户和场景主要是还是从用户的角度考虑并且出发的，从用户的角度考虑软件的设计架构和功能的使用过程。过去的看法：在做软件开发时，根本没想过用户会如何来使用这个软件，并且再什么情况下使用这个软件，会不会遇到什么问题。这样为什么不好：如果不考虑用户的使用场景的话，那么设计出来的软件可能用户使用...

阅读笔记第八章：需求分析第八章的需求分析介绍了软件需求的类型、利益相关者，获取用户需求的常用方法和步骤，竞争性需求分析的框架NABCD以及项目计划和估计的技术。在软件需求方面，可以从利益相关者那里，引导他们表达需求，从而获取。从用户那里获取了需求之后，需要分析和定义需求，也就是对需求进行规整，来定义一下需求的内容。下一步就要像用户去验证这些规整好的需求，看看是否满足用户的需要。另外在软件开发过程中也会对需求进行调整，来适应新的变化。在对软件的需求方面，可以分为对产品功能性的需求，也就是要求超频产品实现某些功能。也可以对产品开发过程的需求，要求开发流程满足某些约束条件。也有一些非功能性需求，还有综合需求。上面提到的一些软件产品的利益相关者，可以是直接使用软件系统的用户，也可以不一定是直接用户，但是他们的利益和软件直接相关，还有一些市场分析师，监管机构和软件工程师。接着介绍了用户调研的方法，可以是下面几种：一种是焦点小组。最常用的一种方法，大家一群人围在一起来讨论对一个软件的看法，但是这种方式也会有一些弱点。还有一种方式是和用户深入的面谈，可以深入了解用户需求，但是费时费力。这种方法可以用...

阅读笔记第六章：敏捷流程第六章敏捷流程主要介绍了什么是敏捷流程及其原则，还有什么时候可以选择敏捷的开发方法，什么时候选择其他方法。敏捷的流程是指一系列价值观和方法论的集合。介绍了一些敏捷开发原则，比如，经常发布可用的软件，业务人员和开发人员在项目开发过程中应该每天共同工作，面对面的交流始终是最有效的沟通方式，不断关注技术和设计，保持简明，团队要学会自我管理，时时总结如何提高团队效率，并付诸行动。敏捷流程的方法论---Scrum方法论。首先第一步需要找出完成产品需要做的事情，然后决定当前的冲刺需要解决的事情，第三步就会开始进行冲刺，冲刺期间每天要开一个每日例会，大家依次报告昨天做了什么，今天要做什么，碰到了什么问题。同时还有做图表，可以是燃尽图，也可以是看版图，未开始，进行中，已完成三个板块。最后会得到软件的一个增量版本，进行发布。当然开发过程中也会碰到一些问题，比如任务之间是有依赖关系的，怎么在计划中体现依赖关系？团队成员领取任务时，会出现问题；每日会议可能会流于形式。这就需要定义好任务究竟是什么。当开发人员说项目完成的时候，只是说该写的代码写完了，但是还有剩下的最重要的20%的测试过...

阅读笔记第五章：团队和流程团队有一些共同的特点：有一致的集体目标，成员之间有各自的分工，合作完成任务。团队一开始可能是"一窝蜂模式"，都想写出好的软件，但是没有各自的分工，一般不会这种模式不会存活太久。慢慢会演化成其他模式，比如"主治医师模式"，本来是不错的模式，但是在学生身上退化为了一个学生干活，其余打酱油的情况。还有比如明星模式，社区模式，业余剧团模式等，当然其中不乏一些好的模式，秘密团队，交响乐团模式，功能团队模式等。学校里面的软件工程专业的学生可能是"写了再改模式"，因为作业是这么要求，但是这种开发方法的缺点特别大。软件行业一开始也会使用"瀑布模型"，即分析-设计-实现-销售-维护的模式，但是对于软件工程来说，需要做很多次的回溯。但是慢慢发现回溯很困难等等的其他问题，需要在生产出产品之后才能知道产品的实用性，这是很头疼的问题。后来根据"瀑布模型"提出了生鱼片模型，但是问题是：不知道上一个阶段什么时候结束。后来引入了子瀑布模型，但是难度相当大，用户只有到了最后才能看到结果，也不实用。后来提出了Rational统一流程，即后面的统一建模，用精确的语言把用户的活动描述出来。流程为：业...

阅读笔记4.5相对于一个人自己写程序，有时候可能不如结对编程，即极限编程。它可以把一些很有成效的编程方法使用起来，并且一直使用。结对编程时，要起到对应的角色作用，可能一开始觉得不适应，但是方法得当以后会发现，结对编程比一个人效率要高，并且后期错误会比较少。当然也有一些不适合结对编程的情况，那么就需要量力而行。4.6在一个团队当中，合作的过程需要一定的时间，会出现不同的阶段。正确处理不同阶段遇到的矛盾，才能为接下来的事情做好准备，要不然最后的结局只能是散伙。两个人的合作中，肯定会相互影响。影响没有正确或者错误之分，只有合适与不合适。在给予对方反馈的时候，分为三个层次。最好是在最外层，当前的行为和后果方面进行反馈，一旦深入到习惯、动机。尤其是本质或者固有属性的时候，后果肯定不会太美好。要先强调双方的共同点，然后提出想说的建设性意见，最后再鼓励一下对方，这样双方都能受益。 过去的看法：在结对编程过程中，只要能指出对方的问题，不管用什么方法都可以。这样为什么不好：如果不经过考虑的任意指出对方的问题，而忽略对方的感受，很可能导致当场散伙，更别提什么以后长期合作的事了。解决办法：在发现对...

阅读笔记3.3如果说自己精通某个方面，就不要出现低级错误，或者出现低层次问题。一个人的技能的高低要看技能的反面，即解决问题的能力。要先通过不断的练习来解决低层次问题，使之不再出现，才有时间来解决高层次问题。再解决问题的时候，首先要知其然，知其所以然，接着就是进行创新。4.1&4.3代码规范问题：一个人的代码不光是自己要看，团队合作的时候，其他人也需要看，自己写的代码也得让别人能够看懂，不能是一大片，一点结构都没有。代码风格规范体现在最起码要有缩进（Tab），括号，换行，面试的时候，还要注重的一点就是变量，方法和函数的命名，普遍使用"匈牙利命名法"。还有一些下划线，大小写，最重要的还有注释。一个程序中一般都需要写注释，注释是为了解释程序做什么，为什么这样做。这里搜索了两篇C++程序的命名规范，请参考：http://www.360doc.com/content/12/0314/12/3767901_194244058.shtmlhttp://blog.sina.com.cn/s/blog_567842410100nf09.html代码规范还体现在代码设计规范上。代码设计不能只为了自...

阅读笔记2。1程序要进行单元测试来保证程序的健壮性。还要进行回归测试，就是在原版本上运行的测试用例通过的话，在下一版本上再运行时，却没有通过，这就是软件"退化"，所以需要进行回归测试。在新版本上运行所有已经通过的测试用例，来验证后面的版本没有出现软件"退化"的情况。但是如果是模块功能发生了变化，那么测试用例也需要修改来测试新的模块。2。2程序还要进行效能分析，这个是以前从来没有了解过的。就是找出程序运行时，哪个函数或方法消耗的时间多，就是程序运行的瓶颈所在，进行效能分析，从而对相应模块的代码进行优化。进行效能分析的方法有抽样和代码注入，各有优缺点。不过普遍用的是先用抽样方法找到瓶颈所在，然后对特定模块的代码用代码注入的方法进行详细分析。还要注意避免没有做分析就过早进行"效能提高"。2。3   对程序员或者工程师是有能力成熟度模型的。工程师在需求分析和测试上花的时间更多，而在具体编码中比大学生花的时间少一半多，从学生到职业程序员，以后在写代码的时间会少很多，更多是用在分析上。    过去的看法：  ...

其实学习每一种语言，都可以找到很快乐的学习方法。有兴趣，有乐趣，才会一直想学。知道print()、input()、if/else就可以做一个简陋的游戏了。print()#打印函数，将信息打印出来input()#将信息打印，并且要求输入一段话，并且把这段话。if1+1==2:print('我是真，如果1+1等于2，就会打印我！！！')else:print('我是假，如果1+1不等于2，就会打印我~~~')#条件判断语句 然后我们可以通过上面学习的3个BIF函数，就可以开始做游戏啦：print('-----------WordGame-----------')number=int(input("猜一下系统给的数字是多少："))ifnumber==8:print("哇塞，猜中了！！")else:print("猜错啦，系统给的数字是8！")我们可以将函数拆解来分析打印函数，我们通过print打印一个游戏标题print('-----------WordGame-----------') input函数，这个函数会将字符串显示在IDLE上，并且让用户输入信息，将这段信息保存至n...

Python是什么类型的语言Python是脚本语言Python下载地址：https://www.python.org/downloads/Python版本：Python3.4.2-64bit       脚本语言(Scriptinglanguage)是电脑编程语言，因此也能让开发者藉以编写出让电脑听命行事的程序。以简单的方式快速完成某些复杂的事情通常是创造脚本语言的重要原则，基于这项原则，使得脚本语言通常比C语言、C++语言或Java之类的系统编程语言要简单容易。也让脚本语言另有一些属于脚本语言的特性：语法和结构通常比较简单学习和使用通常比较简单通常以容易修改程序的“解释”作为运行方式，而不需要“编译”程序的开发产能优于运行性能       一个脚本可以使得本来要用键盘进行的相互式操作自动化。一个Shell脚本主要由原本需要在命令行输入的命令组成，或在一个文本编辑器中，用户可以使用脚本来把一些常用的操作组合成一组串行。主要用来书写这种脚本的语言叫做...

  协议就是计算机与计算机之间通过网络实现通信事先达成的一种“约定”。这种“约定”使那些由不同厂商的设备、不同的CPU以及不同的操作系统组成的计算机之间，只要遵循相同的协议就能够实现通信。反之，如果使用的协议不同，就无法通信。  分组交换是将大数据分割为一个个叫做包（Packet）的较小单位进行传输的方法。这里所说的包，就如同我们平常在邮局里见到的邮包。分组交换就是将大数据分装为一个个这样的邮包交给对方。  （1）协议分层就如同计算机软件中的模块化开发，OSI参考模型的建议是比较理想化的。OSI是OpenSystemInterconnection的缩写，意为开放式系统互联。国际标准化组织（ISO）制定了OSI模型，该模型定义了不同计算机互联的标准，是设计和描述计算机网络通信的基本框架。OSI模型把网络通信的工作分为7层，分别是物理层、数据链路层、网络层、传输层、会话层、表示层和应用层。  （2）OSI参考模型中每个层的作用：  （3）7层通信实例：假设主机A的用户A要给主机B的用户B发送...

出处http://www.cnblogs.com/xiaoxi/p/7065328.html一、概述     Redis的强大性能很大程度上都是因为所有数据都是存储在内存中的，然而当Redis重启后，所有存储在内存中的数据将会丢失，在很多情况下是无法容忍这样的事情的。所以，我们需要将内存中的数据持久化！典型的需要持久化数据的场景如下：将Redis作为数据库使用；将Redis作为缓存服务器使用，但是缓存miss后会对性能造成很大影响，所有缓存同时失效时会造成服务雪崩，无法响应。本文介绍Redis所支持的两种数据持久化方式。二、Redis数据持久化      Redis支持两种数据持久化方式：RDB方式和AOF方式。前者会根据配置的规则定时将内存中的数据持久化到硬盘上，后者则是在每次执行写命令之后将命令记录下来。两种持久化方式可以单独使用，但是通常会将两者结合使用。1、RDB方式     RDB方式的持久化是通过快照的方式完成的。当...