04 2018 档案
摘要：基于Ubuntu16.04LTS 第一步：通过脚本进行安装 或者选择国内的DaoCloud安装脚本 第二步：启动服务 第三步：用户组以及用户添加 创建docker用户组 将当前用户加入 docker 组： 第四步：添加镜像加速 编辑 ,设置 .镜像加速地址可以通过DaoCloud申请（通过Githu
阅读全文
摘要：
如果你不在乎能否开发出漂亮的软件，你又何必要耗费生命去开发软件呢？
阅读全文
如果你不在乎能否开发出漂亮的软件，你又何必要耗费生命去开发软件呢？
阅读全文
摘要：工欲善其事,必先利其器器 ——《论语·卫灵公》 一、你懂的 + Lantern + Shadow Socket 二、写代码的 1、文本编辑器 + Vim + Visual Studio Code 2、IDE + Pycharm + Python开发IDE + IDEA + Java开发IDE + E
阅读全文
摘要：《统计自然语言处理》 一些基础理论概念，涉及统计自然语言处理的基本概念、理论方法和新研究进展，内容包括形式语言与自动机及其在自然语言处理中的应用、语言模型、隐马尔可夫模型、语料库技术、汉语自动分词与词性标注、句法分析、词义消歧、篇章分析、统计机器翻译、语音翻译、文本分类、信息检索与问答系统、自动文摘
阅读全文
摘要：为一个信息流产品作数据抓取，其中数据清洗时必不可少的。其中有一个步骤就是清洗掉其中与内容无关的广告。文本通过语料库积累和NLP相关技术进行过滤，有些文字广告不过滤对产品影响也不大。有点儿麻烦的是其中的有些图片广告如果不过滤掉，在感官上会对产品造成很大的印象，为了解决这个问题，用了一些杂七杂八的方法，
阅读全文
摘要：第一部分：打好基础 + "第一章：欢迎进入软件构建的世界" + "第二章：用隐喻来更充分地理解软件开发" + "第三章：三思而后行：前期准备" + "第四章：关键的“构建”决策" 第二部分：创建高质量的代码 + "第五章：软件构建中的设计" + "第六章：可以工作的类" + "第七章：高质量的子程序
阅读全文
摘要：+ 在架构层将系统划分为多个子系统，以便让思绪在某段时间内能专注于系统的一小部分。 + 仔细定义类接口，从而可以忽略类内部的工作机理。 + 保持类接口的抽象性，从而不必记住不必要的细节。 + 避免全局变量，因为它会大大增加总是需要兼顾的代码比例。 + 避免深层次的继承，因为这样会耗费很大精力。 +
阅读全文
摘要：很多好的编程做法都能减轻你的大脑灰质细胞（指脑力）的负担。 + 将系统“分解”，是为了使之易于理解（“设计的层次”）。 + 进行审查、评审和测试正是为了减少人为失误。如果你从不犯错，就无须复审自己的软件。但要知道，人的智力是有限的，所以应和他人沟通，来提高软件质量。 + 将子程序编写得短小，以减轻大
阅读全文
摘要：核对表（自说明代码） + 你的类接口体现出某种一致的抽象吗？ + 你的类名有意义吗，能表明其中心意图吗？ + 你的类接凵对于如何使用该类显而易见吗？ + 你的类接囗能抽象到不需考虑其实现过程吗？能把类看成是黑盒吗？ 子程序 + 你的每个子程序名都能准确地指示该子程序确切干些什么吗？ + 你的各子程序
阅读全文
摘要：格式化的基本原理指出，好的布局凸现程序的逻辑结构。 对于C++，请仔细组织源文件中内容的次序为： 1. 文件的描述性注释 2. \ include文件行 3. 在多个类里使用的常量定义（如果文件里有多个类） 4. 在多个类里使用的枚举（如果文件里有多个类） 5. 宏函数定义 6. 在多个类里使用的类
阅读全文
摘要：你至少能在以下领域找到高质量的程序库 + 容器类 + 信用卡交易服务（电子商务服务） + 跨平台的开发工具，你可以让编写的代码在Windows、AppleMacintosh、XWindowSystem上都能运行一一一只需为各个环境重新编译一次源代码 + 数据压缩工具 + 数据结构与算法 + 数据库操
阅读全文
摘要：术语“集成”指的是一种软件开发行为：将一些独立的软件组件组合为一个完整系统。 核对表（集成） 集成策略 + 该策略是否指明了集成子系统、类、子程序时应该采用的最优顺序？ + 集成的顺序是否与构建顺序协调，以便在适当的时候准备好供集成的类？ + 该策略是否易于诊断缺陷？ + 该策略是否使脚手架最少？
阅读全文
摘要：核对表（配置管理） 概要 + 你的软件配S管理计划是否用于帮助程序员，并能将额外负担降至最低？ + 你的软件配S管理方法是否避免了对项目的过度控制？ + 你是否将一些变更请求聚成一组？无论采用非正式的方法（如创建一份未决更改的列表）还是更加系统的方法（如设立变更控制委员会）。 + 你系统地评估了每一
阅读全文
摘要：随着项目规模的增加，下面这些活动的工作量增长超过线性: + 交流 + 计划 + 管理 + 需求分析 + 系统功能设计 + 接口设计和规格说明 + 架构 + 集成 + 消除缺陷 + 系统测试 + 文档生成 在社交场合，活动越正式，你所穿的服装就会越不舒服（高跟鞋、领带等等）。在软件幵发领域里，项目越正
阅读全文
摘要：核对表（代码调整方法） 同时改善代码执行速度和规模 + 用査询表替换复杂逻辑。 + 合并循环 + 使用整型变量而非浮点变量。 + 在编译时初始化数据。 + 使用正确的常量类型。 + 预先计算结果。 + 删除公共子表达式。 + 将关键子程序代码转化为某种低级语言代码。 仅仅提高代码执行速度 + 在知道
阅读全文
摘要：在讨论编程的时候，没有“可能”一词的位置。——Tacey 如果对代码调整能否有助于提高某个程序的性能心存疑虑，按照以下的步 骤去做： 1. 用设计良好的代码来开发软件，从而使程序易于理解和修改。 2. 如果程序性能很差。 + a.保存代码的可运行版本，这样你才能回到“最近的已知正常状态”； + b.
阅读全文
摘要：神话：一个管理很完善的软件项目，应该首先以系统化的方法进行需求开发， 定义一份严谨的列表来描述程序的功能。设计完全遵循需求，并且完成得相当仔 细，这样就让程序员的代码编写工作能够从头至尾饩线型地工作。这也表明绝大 多数代码117欠编写后就己完美，测试通过即可被抛到脑后。如果这样的神话是真 的，那么代
阅读全文
摘要：泛调试步骤： + 通过可重复的实验搜集数据 + 根据相关数据的统计构造一个假说 + 设计一个实验来验证或者反证这个假说 + 证明或者反证假说 + 根据需要重复进行上面的步骤 寻找缺陷的有效方法： + 将错误状态稳定下来 + 确定错误的来源 1. 收集产生缺陷的相关数据 2. 分析所搜集的数据，并构造
阅读全文
摘要：自动化测试：http://robotframework.org/ HTTP接口测试： "POSTMAN" 测试： + 单元测试（unit testing） + 组件测试 （component tetsing） + 集成测试 （integration testing） + 回归测试 （regressi
阅读全文
摘要：》结对编程 》 正式检查 结对编程 成功运用结对编程的关键： + 用编码规范来支持结对编程 + 不要让结对编程编程旁观 + 不要强迫在简单的问题上使用结对编程 + 有规律的对结对人员和分配的工作任务进行轮换 + 鼓励双方跟上对方的步伐 + 确认两个人都能够看到显示器 + 不要强迫程序员与自己关系紧张
阅读全文
摘要：软件质量特性： + 外 + 正确性 + 可用性 + 效率 + 可靠性 + 完整性 + 适应性 + 精确性 + 健壮性 + 内 + 可维护性 + 灵活性 + 可移植性 + 可重用性 + 可读性 + 可测试 + 可理解性 提高生产效率和改善质量的最佳途径就是减少花在这种代码返工上的时间，无论返工的代码时
阅读全文
摘要：布尔 除了最简单、要求语句按照顺序执行的控制结构之外，所有的控制结构都依赖于布尔表达式的求值 嵌套 减少嵌套层次的技术列表： + 重复判断一部分条件 + 转换成if then else + 转换成case语句 + 把深层嵌套的代码提取城单独的子程序 + 使用对象和多态派分 + 用状态变量重写代码 +
阅读全文
摘要：表驱动法是一种编程模式（scheme）——从表里面查找信息而不使用逻辑语句（if、case）。事实上，凡是能通过逻辑语句来选择的事物，都可以通过查表来选择。在适当的情况下，采用表驱动法会比复杂的逻辑代码更简单、更容易修改，而且效率更高。 表驱动法必须要解决的两个问题： 1、如何从表中查询条目： +
阅读全文
摘要：核对表（不常见的控制结构） return + 每一个子程序都尽在有必要的时候才使用return吗？ + 使用return有助于增强可读性吗？ 递归 + 递归子程序中包含了停止递归的代码吗？ + 子程序用安全计数器来确保子程序能停下来吗？ + 递归只位于一个子程序里面吗？ + 子程序的递归深度处于程序
阅读全文
摘要：核对表（循环） 循环的选择和创建 + 在核实的情况下用while循环取代for循环了吗？ + 循环是由内到外创建的吗？ 进行入循环 + 是从循环头部进入的循环吗？ + 初始化代码是否直接位于循环前面吗？ + 循环是无限循环或者事件循环吗？它的结构是否清晰？ + 避免使用像for i=1 通9999这
阅读全文
摘要：核对表（使用条件语句） if then 语句 + 代码的正常路径清晰吗？ + if then测试对等量分支的处理方式正确吗？ + 使用了else字句并加以说明吗？ + else字句用的对吗？ + 用对了if和else子句，即没把他们用反？ + 需要执行的正常情况是位于if而不是else子句里吗？ i
阅读全文
摘要：核对表（组织直线型代码） + 代码使得语句之间的依赖关系变得明显吗？（顺序相关型） + 子程序的名字使得依赖关系变得明显吗？ + 子程序的参数使得依赖关系变得明显吗？ + 如果依赖关系不明确，你是否用注释进行了说明？ + 你用“内务管理变量”来检查代码中关键位置的顺序依赖关系了吗？ + 代码容易按照
阅读全文
摘要：只有万不得已时才使用全局数据 ！！！就近原则！！！注释紧随代码，变量紧随使用它们的地方 ——Tacey 访问器子程序的优势 + 你获得了对数据的集中控制 + 你可以确保对变量的所有引用都得到了保护 + 自动获取信息隐藏的普遍益处 + 访问器子程序可以很容易转变为抽象数据类型 如何使用访问器子程序：
阅读全文
摘要：核对表：基本数据类型 数值概论 + 代码中避免使用神秘数值 + 代码考虑了除零错误了吗？ + 类型转换很明显吗？ + 如果在一条语句中存在两个不同类型的变量，那么这条语句会想你期望的那样求值吗？ + 代码避免了混合类型比较吗？ + 程序编译时没有警告信息吗？ 整数 + 使用整数除法的表达式能按预期的
阅读全文
摘要：为变量取好的名字和高效编程同样重要 变量名要 完全 、 准确 地描述出该变量所代表的的事物 变量名的适宜长短和变量的作用域相关，越局部的变量，变量名越短（如循环变量） 常用对仗词： 核对表（变量命名） 命名的一般注意事项 + 名字完整并准确地表带了变量所代表的含义吗？ + 名字反映了显示世界的问题而
阅读全文
摘要：利用构建活动来填补需求和架构中存在的细小间隙是一种行之有效的做法;但把蓝图设计得精细到已经能完全展现出所有的细节则实在是一种低效的方法 尽量缩小变量的作用域，尽量缩短变量的生存时间 ——Tacey 基础数据类型： 核对表（使用数据的一般事项） 初始化变量 + 每一个子程序都检查其输入参数的正确性了吗
阅读全文
摘要：一个类的创建过程可以千变万化，但基本上都会以下图所示的顺序发生： 伪代码编程过程的替代方案 + 测试先行开发/测试驱动开发：在任何代码之前先要写出测试用例 + 重构：通过对代码进行一系列保持语义的变换和调整来提高代码的质量。 + 契约式设计：认为每一段程序都具有前条件和后条件，用断言来注解并验证前条
阅读全文
摘要：要点 + 最终产品代码中对错误的处理方式要比“垃圾进，垃圾出”复杂的多。 + 防御式编程技术可以让错误更容易发现、更容易修改，并减少错误对产品代码的破坏。 + 断言可以帮助人尽早发现错误，尤其是在大型系统和高可靠性的系统中，以及快速变化的代码中。 + 关于如何处理错误输入的决策是一项关键的错误处理决
阅读全文
摘要：子程序是为实现一个 特定的目的而编写的一个被调用的方法或过程 创建子程序的正当理由 + 降低复杂度 + 引入中间、易懂的抽象 + 避免代码重复 + 支持子类化 + 隐藏顺序 + 隐藏指针操作 + 提高可一致性 + 简化复杂的布尔判断 + 改善性能 除此之外，创建类的很多理由也是创建子程序的理由 +
阅读全文
摘要：抽象数据类型是指一些数据以及对这些数据所进行的操作的集合 接口/API先行 ——Tacey 只有一个实例的类是值得怀疑的 不要创建任何并非绝对必要的继承结构 继承层次尽量限制在3层之内 如果可能，应该在所有的构造函数中初始化所有的数据成员（防御式编程实践） 优先使用深拷贝 创建类的原因 + 为现实世
阅读全文
摘要：无论是以何种方式来进行设计，小型项目也能和大型项目一样从精心的设计之中获益，而如果能认识到设计是一项明确的活动，你就更会获益匪浅。 设计过程充满了不确定性，因此设计技术也趋于探索性质 软件的首要技术使命：管理复杂度 设计特征： + 最小复杂度 + 易于维护 + 松散耦合 + 可扩展性 + 可重用性
阅读全文
摘要：核对表：主要的构建实践 编码 + 你有没有确定多少设计工作将要预先进行，多少设计工作在键盘上进行（在编写代码的同事）？ + 你有没有规定诸如名称、注释、代码格式等“编码约定” （编码规范） + 你有没有规定特定的由软件架构确定的编码实践，比如如何处理错误条件，如何处理安全性事项，对于类接口有哪些约定
阅读全文
摘要：问题定义只定义了问题是什么，而不涉及任何可能的解决方案。 如果没有好的需求，你可能对问题有总体的把握，但却没有集中问题的特定方面。 需求像水。如果冻结了，就容易在上面开展建设 ——无名氏 （经常性无法预期的需求变更会伤害项目的开发者，从而毁了项目） 软件架构是软件设计的高层部分，适用于支撑更细节的设
阅读全文
摘要：隐喻的价值绝不应该被低估。隐喻的优点在于其预期的效果：能被所有的人理解。不必要的沟通和误解也因此大为降低，学习与教授更为快速。实际上，隐喻是对概念进行内在化和抽象的一种途径，它让人在更高的层面上思考问题，从而避免低层次的错误。 + 隐喻是启示而不是算法，因此他们往往有一点随意。 + 隐喻把软件开发过
阅读全文
摘要：首先要明确开发计算机软件是一个复杂的工程，并不比建设高楼大厦简单。这项活动和传统的土木工程类有相似的部分，也有迥然不同的地方。 主要有下面的几种活动（根据进程推动顺序）： + 定义问题 + 需求分析 + 规划构建 + 软件架构/高层设计 + 详细设计 + 编码与调试 + 单元测试 + 集成测试 +
阅读全文
