组织代码

模块路径解析规则 源链接 我们知道的 require 函数支持的两种路径有： 以 / 或者 C: 开头的绝对路径 以 ./ 开头的相对路径。 以上路径的缺点是： 使得模块之间建立了强耦合关系，一旦某个模块文件的存放位置需要变更，使用该模块的其它模块的代码也需要跟着调整，变得牵一发动全身。 下面来了解一下 require 支持的第三种形式的路径，写法类似于 foo/bar ，按照一下规则解析，直到找到模块位置。 内置模块 遇到NodeJs的内置模块，不做解析，直接返回内置模块导出的对象。 node_modules目录 node_modules 目录是NodeJs定义的用于存放模块的。 当require('foo/bar')时，NodeJs依次尝试一下路径： /home/user/node_modules/foo/bar /home/node_modules/foo/bar /node_modules/foo/bar NODE_PATH环境变量 与PATH环境变量类似，NodeJS允许通过 NODE_PATH 环境变量来指定额外的模块搜索路径。 NODE_PATH 环境变量中包含一到多个目录路径，路径之间在Linux下使用":"分隔，在Windows下使用";"分隔。例如定义了以下 NODE_PATH 环境变量： NODE_PATH=/home/user/lib:/home/lib

DevOps面试问题 01 您能告诉我们DevOps和Agile(敏捷)之间的根本区别吗？ 答：尽管DevOps与敏捷方法（这是最流行的SDLC[Software Development Life Cycle]方法之一）有一些相似之处，但两者在软件开发方面都是根本不同的方法。以下是两者之间的各种基本差异： 敏捷方法 敏捷方法适用于敏捷中的开发同时敏捷方法适用于DevOps中的开发和操作。 实践和流程 敏捷涉及敏捷Scrum和敏捷看板等实践，而DevOps涉及CD（持续交付），CI（持续集成）和CT（持续测试）等流程。 优先级 敏捷优先考虑及时性，而DevOps优先考虑及时性和质量。 发布周期 DevOps提供较小的发布周期并提供即时反馈，而敏捷仅提供较小的发布周期而没有立即反馈。 反馈源 敏捷依赖于客户的反馈，而DevOps涉及到自身（监控工具）的反馈。 工作范围 对于敏捷，工作范围仅是敏捷，而对于DevOps，这是敏捷和对自动化的需求。 02 为什么我们需要DevOps？ 答：如今，很多组织或企业正试图通过一系列的发布小的特性传递给客户，而不是发布大的特性集。这样做有几个好处，包括更好的软件质量和快速的客户反馈，所有这些好处导致更高的客户满意度，这是任何产品开发项目的最重要目标。为此，公司需要： 增加部署频率 缩短修复时间 降低新版本的失败率 万一新版本崩溃

BOM模块常用表结构 表名: bom.bom_bill_of_materials 说明: BOM清单父项目 BILL_SEQUENCE_ID NUMBER 清单序号（关键字） ASSEMBLY_ITEM_ID NUMBER 装配件内码 ORGANIZATION_ID NUMBER 组织代码 ASSEMBLY_TYPE NUMBER 装配类别 SPECFIIC_ASSEMBLY_COMMENT VARCHAR2(240) 注释（装配件状态P、R等） COMMON_ORGANIZATION_ID NUMBER 公共组织 COMMON_BILL_SEQUENCE_ID NUMBER 公共序号 COMMON_ASSEMBLY_ITEM_ID NUMBER 公共项目内码 表名：bom.bom_inventory_components 说明：BOM清单构成项目 COMPONENT_SEQUENCE_ID NUMBER 构件序号 BILL_SEQUENCE_ID NUMBER 清单序号 OPERATION_SEQ_NUM NUMBER 操作序列号 COMPONENT_ITEM_ID NUMBER ITEM_NUM NUMBER 项目序列号 COMPONENT_QUANTITY NUMBER 构件数量 COMPONENT_YIELD_FACTOR NUMBER 产出因子 EFFECTIVITY

转载自：https://blog.csdn.net/u012635648/article/details/72779050 原文：https://sijinjoseph.com/programmer-competency-matrix/ 注意:每个层次的知识都是渐增的，位于层次n，也蕴涵了你需了解所有低于层次n的知识。 计算机科学 Computer Science 2 n 2^n 2 n (level 0) n 2 n^2 n 2 (level 1) n n n (level S2) l o g ( n ) log(n) l o g ( n ) (level 3) 备注 数据结构 不知道数组和链表的差异 能够解释和使用数组，链表，字典等，并且能够用于实际的编程任务。 了解基本数据结构时间和空间的这种，比如数组vs链表，能够解释如何实现哈希表和处理冲突，了解优先队列及其实现 高等的数据结构的知识，比如B-树、二顶堆、斐波那契堆、AVL树、红黑树、伸展树、跳跃表以及前缀树等。 算法 不能够找出一个数组各数的平均值（这令人难以置信，但是我的确在应聘者中遇到过） 基本的排序，搜索和数据的遍历和检索算法 树、图、简单的贪婪算法和分而治之算法，能够适度了解矩阵该层的含义 能够辨识和编写动态规划方案，良好的图算法知识，良好的数值估算的知识，能够辨别NP问题等 与优秀的程序员一起工作是一件快事

Inline Temp 内联临时变量 动机:临时变量影响了其他构造方法 当程序有一个临时变量只被赋值一次，而且影响到了其他的重构，那么我将这个变量去除，用赋值给他的表达式来替换临时变量； 确认等式右边的表达式无副作用 然后尝试将临时变量声明为final，确定只赋值一次 替换临时变量 Replace Temp with Query 当临时变量保存一个运算结果或者查询结果，将表达式提取到一个独立函数，然后用函数替代； 优点：这样去除了临时变量不能被其他函数引用导致的多余代码问题 找出临时变量，如果只是一次赋值的变量则可直接提取替代，如果是收集的是循环里面的结果则将整个循环提点。注意：当你的提取代码有副作用时候，记得要用Separate Query from Modifler来切割查询和副作用。（副作用:即会影响数据库的修改类操作或者非当前查询的参数被修改的情况） Introduce Explaining Variale 当你的表达式复杂难懂时，将其提取出来用自定义命名的临时变量替换 优缺点：让代码变动容易理解，被局限于单个函数内 适合场景： 1.当用函数提取工作量比较大的时候就用引入解释性变量 2.当提取函数代码十分复杂，我们可以先引入解释性变量帮助理解，然后再提取 Remove Addignments to Paramters 移除对参数赋值，当代码对参数赋值时候吗

2016年11月30日13:22:26【转】 CTO、技术总监、首席架构师的区别 提升自已的能力,比如专业技术,行业发展趋势,技术发展趋势,协调能力,组织能力,管理能力等【技术总监】 需要从技术总监和研发Leader身上剥离职责。让技术总监和研发Leader偏项目管理（管理族），把各个模块之间的架构设计工作，独立出一个岗位，就是架构师，来负责。【首席架构师】 真正的CTO，是软件产品和技术是统一管理的。商业、产品、技术、管理、团队相平衡的综合统管【首席技术官CTO】 一、高级程序员 如果你是一个刚刚创业的公司，公司没有专职产品经理和项目经理，你就是公司的产品经理，你如果对你现在的开发员能力不满，那么你只需要的是一个高级程序员。 你定义功能、你做计划推进和管理，他可以带1-2个副手把你规划的功能实现了，他是主力干活者，有技术难题也是他来亲自攻克解决。 所以，一个高级程序员，他的职责很清晰： 1、负责核心复杂功能的实现方案设计、编码实现 2、负责疑难BUG分析诊断、攻关解决 二、研发Leader 公司再长大些。如果你就有一个研发团队（含产品/开发/ 测试 ），你就一套主产品，而且你的研发团队小于15人，那么你需要的就是一个研发Leader。 因为你已经有了1-2个高级程序员，核心难题攻克和核心功能研发进度与质量保证，已经可以靠他们自身能力解决掉了。那么你需要研发Leader干什么。

### 学习到的能力的预期 - 可以把书上的理论知识运用到实践当中， 增强自己的实践能力，动手能力。所以上课就要认真，积极完成老师布置的学习任务，定期更新自己的博客，多敲代码，增强个人的编程能力，学会 如何从单纯的编程走向软件开发。 ###　对项目课程的期望 - 第一次接触博客园，很新奇，原来学习的工具也可以那么多样化，希望以后在完成老师布置的任务过程中，能熟悉并掌握计算机领域的学习工具，提高自己的组织语言能力. - 能够深刻并且详细的了解一个软件形成的基本过程，从开始的需求分析到最后的发布并且供用户使用. ### 对项目的愿景规划 - 方便人们生活，让大家能更好的享受计算机物联网带给大家的便利。 来源： https://www.cnblogs.com/yaq233/p/6474129.html

原文: Team Collaboration With GitHub GitHub 已经成为的一切开放源码软件的基石。开发人员喜欢它，基于它进行协作，并不断通过它开发令人惊叹的项目。除了​​代码托管， GitHub 的主要吸引力是使用它作为一个协作开发工具。在本教程中，让我们来看看一些最有用的GitHub的功能，特别是使团队工作更有效率，更高生产力，非常重要的，好玩的那些功能！ GitHub和软件合作 有一件事我觉得非常有用的是，可以将GitHub的维基集成到项目的源代码主线上。 本教程假定您已经熟悉 Git – 开放源码的分布式版本控制系统，由Linux的创世人 Linus Torvalds 在2005年创造的。如果您需要修改或查找有关 Git ，请访问我们以前的 截屏教程 ，和一些 文章 。此外，你应该已经有一个 Github 上的帐户，并做了一些基本的功能，如创建一个存储库，并推送到 GitHub 上。如果没有，可以参照更多以前的 教程 。 在这个世界上的软件项目，不可避免的是，我们必须和一个团队一起工作来交付软件。在本教程中，我们将探索一些软件开发团队最常用的工具。这些工具包括： 添加团队成员 – 组织和合作者 Pull请求 – 发送代码变更和合并 问题跟踪 – Github上的错误记录 分析 – 图形与网络 项目管理 – Trello 与 Pivotal Tracker

现在先从设置许可证服务以使用Redis开始。幸运的是，Spring Data已经简化了将Redis引入许可证服务中的工作。要在许可证服务中使用Redis，需要做以下4件事情。 （1）配置许可证服务以包含Spring Data Redis依赖项。 （2）构造一个到Redis服务器的数据库连接。 （3）定义Spring Data Redis存储库，代码将使用它与一个Redis散列进行交互。 （4）使用Redis和许可证服务来存储和读取组织数据。 1．配置许可证服务以包含Spring Data Redis依赖项 需要做的第一件事就是将spring-data-redis、jedis以及common-pools2依赖项包含在许可证服务的pom.xml文件中。代码清单8-7展示了要包含的依赖项。 代码清单8-7　添加Spring Redis依赖项 <dependency> <groupId>org.springframework.data</groupId> <artifactId>spring-data-redis</artifactId> <version>1.7.4.RELEASE</version> </dependency> <dependency> <groupId>redis.clients</groupId> <artifactId>jedis</artifactId>

第二章 风险分析 风险管理 评估：确定并评估系统中存在的风险 分析：分析风险对系统产生的潜在影响 响应：规划如何响应风险的策略 缓解： 缓解风险对未来安全造成的不良影响 风险分析流程 资产确定 漏洞确定 威胁评估 可能性量化 影响分析 应对措施确认 风险分类： 自然 人为 系统 风险计算 ：ALE（年度损失预期， annual loss expectancy） = SLE（单一损失预期，single loss expectancy）* ARO（年发生率，annual rate of occurrence） Single Loss Expectancy (SLE) = AV(asset value) x EF(exposure factor) 风险响应的技巧 接受 ：承认并接受该风险及其带来的损失 转移：第三方，比如保险公司 避免：消除风险的来源 缓解： IDS等 风险缓解和控制类型: 技术控制：防火墙 管理控制： 用流程监控组织安全策略的服从情况 操作控制： 保护日常业务操作 损失控制： 灭火器、洒水系统 变更管理（change Management）：批准并执行变更的系统性方法，以确保信息技术服务达到最佳的安全性，稳定性，可用性。 分析： 变更的需求 变更的类型 组织文化 计划： 变更的角色 变更的职责 解决阻力 实施： 管理过渡阶段 确定采用变更 执行项目之后的审核