随笔分类 - 阅读笔记
摘要：读这本书有一段时间了，这本书也大概读了一遍，有精读的部分，也有快速看过的部分，接着上次的笔记这次再写一下看完后边之后最新的一下理解与看法。 我在读这本书的中间两三个章节的时侯，思想因为书的内容变得有些混沌。可能是因为我过于追求速度，一下子读的太多但是不能快速消化吸收，亦或者是我项目做的太少而且经历也
阅读全文
摘要：上次只是看了这本书的一个皮毛，最近又好好把这本书精读了一部分，又有了新的理解和大家分享一下，如果有不同看法也欢迎大家多多交流，指出我理解不到位的地方以弥补我的不足。 当读到该书第二章“人月神话”时，我就被作者犀利的见解所折服。尤其是这个学期也亲自体验了项目开发的整个流程。所以对这种做项目要所有人员都
阅读全文
摘要：林业害虫应用与云原生的结合之缺陷管理 温******* （*******，*******区，中国，*******） 摘要: 本论文主要介绍了基于林业有害生物智能4e识别系统的项目经历介绍、缺陷管理的常见等级、缺陷管理的基本流程和实际应用过程与效果。云原生架构的提出在几年之前，随着存储技术和网络通信技
阅读全文
摘要：本篇《人月神话》的阅读笔记总结了看完序言和目录之后的感受，对这个书有了一个总体的了解。 首先人月神话，人月算是软件工程的一个计量单位吧，一个项目完成需要多少/人月。换一个说法就是，一个人一个月能有多少工作量，然后计算此项目需要多少人月。就好像最大的距离单位光年一样，光每年传播的距离。 这本书整体对于
阅读全文
摘要：1. 知识图谱的研究目标与意义 知识图谱（Knowledge Graph）以结构化的形式描述客观世界中概念、实体及其关系，将互联网的信息表达成更接近人类认知世界的形式，提供了一种更好地组织、管理和理解互联网海量信息的能力。知识图谱给互联网语义搜索带来了活力，同时也在智能问答中显示出强大威力，已经成为
阅读全文
摘要：我在阅读完成《人月神话》时想起了。在刚刚进入软件工程学习时，老师总会时不时向我们提起一些关于“软件项目开发的完成与增加人员的问题”这句话听起来通俗易懂，但实现起来却遇到了相当大的困难，现在最大的感受，我想这种问题的出现主要是就订单项目而言，因为人员的增加主要是因为客户所要求实现的东西并没有在计划的时
阅读全文
摘要：需求捕获最佳实践： 需求捕获的策略： 需求捕获应该是主动地： 需求捕获，他是一个主动动词，强调了需求分析人员在整个过程中应该充分发挥主动性。 需求捕获应该是聚焦的： 提不出需求和提出的需求太多。往往主要是在这两方面。 破解需求的冰山模型： 用户的需求是一组冰山，有很大一部分信息是埋藏在海平面之下的，
阅读全文
摘要：需求定义最佳实践; 需求定义任务概述： 需求定义的时机： 就是定义项目的业务需求，也就是明确项的目的和范围。但是在许多的项目中，通常不愿意在这方面下功夫，因为时间比较宝贵，而且这件事看起来是多么的多此一举的事情。但是这样的做法最终的结果是欲速则不达，反而浪费更多的时间。 需求定义的理念与策略: 破解
阅读全文
摘要：软件需求和软件工程： 什么是软件需求： 需求的是三个层次： 业务需求： 业务需求是反应企业组织对软件系统的高层次目标要求，换句话说就是软件系统的建设目标，常常体现在如下两个方面： 问题和机会： 问题：解决企业运作的过程中遇到的问题， 机会：抓住外部环境变化所带来的机会，以便为企业带来新的发展， 要记
阅读全文
摘要：第二章不同软件项目的需求视图 -读后总结： 信息系统的需求视图： 直到今天，信息系统在软件项目所占的比例也是做高的，因此研究信息系统的本质和分类对于需求工作的开展是尤为重要的。 信息系统的本质与分类： 信息系统是人和数据、过程和接口的组合，主要体会如下几个要素。支持企业的日常运作、支持解决问题、支持
阅读全文
摘要：最近看的是第一章：需求实践现状分析： 失败的根源： “在中国做软件太难了，客户连自己的需求都说不清楚”。这句话经常在我们耳边响起。但是正所谓：“它山之石可以攻玉”。 在做项目的时候，很多项目都是进度超期、成本超支。最主要的原因之一就是项目的重新启动， 在Standish Group总结的十大成功保证
阅读全文
摘要：任务的可移动性 要实现负载的动态均衡能力，就应该实现任务的可移动性，从一台机器移到另外一台机器上。这是系统伸缩性的要求和目标。技术要求：1. 任务是由java写成，这样物理机器上运行JVM，任务就可以运行2. 任务数据来源。任务的数据都来自数据服务。而数据服务是所有游戏实例和Darkstar栈所共享
阅读全文
摘要：混乱大都市 特点： 微观层面特点： 1. 没有统一的概念将不同的部分组织起来2. 代码风格不一致3. 控制流无法预测，即控制流的流向很复杂4. 额外的数据缓存，其目的让数据停留在更方便的地方（但是，容易造成数据的不一致性，维护或扩展不方便）5. 没有人了解整个系统，没有任何文档宏观层面特点：1. 系
阅读全文
摘要：Darkstar的架构 DarkStar是由一组服务组成。每个服务定义为一个小的编程接口。这些接口很像经典操作系统的服务，支持对服务端的访问持久存储、调度并执行任务、与游戏的客户端进行通信。这些服务的程序不会受低层实现变更的影响，因为每个服务由一个接口来描述。当接口不变时，一个服务的变更，不会影响其
阅读全文
摘要：品质需求 1. 系统的伸缩性需求。如大型在线游戏，需要满足大量用户。在线用户数量短时间内可能有很大的变化。这其中隐含的需求是：多用户并行分布式系统，系统运行在多台机器上高可扩展性（用于加入新的故事情节，意味着新的代码）高稳定性、可靠性（一个用户崩溃，不影响其他用户）数据一致性（多个用户看到同一个东西
阅读全文
摘要：功能扩展： 1. 新代码的定位一开始就有系统结构清晰的总体视图，所以，新的功能单元可以添加到正确的功能区域，而不是为了一时方便，代码随意添加。（这样，有的时候开发者的工作会需要动写脑筋，但是在系统维护和扩展时，就变得容易了）2. 系统的一致性顶层设计的良好风格和决定，为底层代理好处，代码是统一、整洁
阅读全文
摘要：1丶架构是什么 架构应该是一组结构，来源于一组设计规则，能减少复杂性。常见定义是，每种结构由各种类型的组件和关系组成，它们如何组合、相互调用、通信、同步、及其其他交互。（组件及组件之间的关系） 2丶架构目的 确保利益相关人员的关注点能够得到满足，而在构想、计划、构建和维护系统时，系统架构能够处理复杂
阅读全文
摘要：卡普尔就坚持要做现实的计划和进度。但项目平均6个月能发布一个版本，但计划是在3 、4 个月内完成一个版本。软件开发和其他领域中计划总是超出了能预见的范围。Chandler项目的软件开发者很少成组地共同开发一系列项目每次到新团队中开始做新项目时，他们大概还是会按下”重置”按钮， 根据某些首要原则设计出
阅读全文
摘要：模块化和组件化是软件人员的梦想，谁都想把几个模块插到一起就可以完美的运行并完成任务，但现实却相当残酷，可以运行的模块通常不能与自己想写的程 序配合工作，好的源代码由于商业利益也不太容易找到，程序员只能自己另起炉灶，搭建自己的模块，但结果还是一样，做出来的东西难以让他人共享，这个现象周 而复始，不断地
阅读全文
摘要：任何一个在软件领域稍有经验的技术人员看完本书，必掩卷长叹：做软件难。软件乃是人类自以为最有把握，实则最难掌控的技术。书中的许多内容确实就是我的感受，例如在做软件的过程当中，时间似乎确实时快时慢。如果一切顺利，你会沉浸在心理学家称之为“流逝”的状态中，全然忘记了时间。如果事有不谐，你又会陷入困境，四顾
阅读全文
浙公网安备 33010602011771号